5 ms·

Now that the dominant languages seem to be dynamic languages like Python, Ruby & JavaScript, I wonder if Lisp's edge in development speed is as pronounced; OTOH

by wtbob 12y ago

Now that the dominant languages seem to be dynamic languages like Python, Ruby & JavaScript, I wonder if Lisp's edge in development speed is as pronounced; OTOH, I wonder if it has an increased edge in stability and/or security.

agumonkey 12y ago
It seems that python development speed means well rounded libraries. And IIRC lisp is still not on par with that (quicklisp users feel free to correct me). Other than that I still think that linguistically, lisps still have an edge (and a sharp one).
- mackwic 12y ago
  But Ruby is an acceptable Lisp[0], and has also a lot of libraries. ;) So, how will Lisp compete ? Maybe if we look at it pragmatically, the solution is not in the performance nor in the time to develop, but in the ease of maintaining the software in the long term. A field where Lisp is not particularly brilliant. [0]: http://www.randomhacks.net/2005/12/03/why-ruby-is-an-acceptable-lisp/ http://www.randomhacks.net/2005/12/03/why-ruby-is-an-accepta...
  - agumonkey 12y ago
    I forgot to mention that the main lisp implementations (SBCL) are fast. Compared to languages like these it's a done deal. Good point about long term maintenance. Ruby and Python aren't that great either, people say static typing is the way to go. Lisps are weird because they allow to hot swap most of the things which makes changing a system easy, but at the same time it leads to spaghetti images.
    - _delirium 12y ago
      My experience is that long-term image-based development isn't really that common in Lisp, maybe outside of some specialized use-cases. You can develop by mutating/saving/reloading an image over an extended period of time, but in practice people mostly develop the "usual" way, with source code that's loaded into a fresh image periodically. The use of image-oriented development then gets limited to prototyping and debugging. Being able to redefine functions/etc. on the fly (even during restarts and the like) is useful while experimenting and debugging. But then the "real" code gets written into a source file, which is reloaded into a fresh image to make sure it works. For modern muti-developer Lisp this is pretty much the only way things are done, since the expectation is that you check Lisp source into svn or git, not images.
      - adwf 12y ago
        That's pretty much exactly how I develop. I rarely type anything directly into the REPL, instead typing into the source file in emacs and then C-c C-c it over to the REPL for me. The advantage is that I get a canonical copy of the entire source code, whilst still having the ability to inspect and hotfix things through the REPL. If I then need to reboot the image or deploy to a new server, the entire source base should be completely stable and consistent. I often connect to production servers using Slime and fix little things like typos this way - then check the source into Github and have it permanently saved. It removes a lot of the stress of doing a full deployment each time you need to patch something!
      - philippeback 12y ago
        Same story with Pharo Smalltalk where we run CI jobs loading things into fresh images. Code lives in Git as well via GitFileTree.
  - Curmudgel 12y ago
    > But Ruby is an acceptable Lisp[0] Yes, (as tptacek said), just like Esperanto is an acceptable English. https://news.ycombinator.com/item?id=416589 https://news.ycombinator.com/item?id=416589
  - PuercoPop 12y ago
    Ruby is far from an 'acceptable' lisp. The article's first premise of what are lisp's virtues is dead wrong. First Lisp is NOT a functional language. A functional language is one that maintains referential transparency. i.e. where I can replace the reference/variable with its value its semantics are unchanged. Common Lisp is a multi-paradigm language and pervasively uses the the concept of places to setf state. And in a more general lisp sense, macros are opaque to the run-time and directly opposes referential transparency. His second statement, Ruby gives you 80% of what you need of macros, implies that we know what macros are for. Macros are not a solved problem, you can see Racket is actively researching macros. For example, how does one do meaningful error reporting in macros? And given that macros, generally, are programming at compile time the statement is as analogous to saying we know what we are programming for, a statement I couldn't disagree more with. The quid of Lisp I would argue is not specifically macros, but its 'meta-circular semantics', that is to say, the capacity of lisp to speak of itself in a meaningful way[0][1]. For example, in C++ we can speak of C++ but not in C++ but in its template language, that is to say a meta language. Lisp is its own meta language. We could also speak of Python in Python, for example express Python's for loop in python[2], except there is now way to replace python's definition of for with my own. BTW, that doesn't mean Ruby isn't a good language. Lisp is not an idyllic standard from which to measure how good all other languages are. For example, Smalltalk is far from being a Lisp, that doesn't mean it is not good. [0]: http://home.pipeline.com/~hbaker1/MetaCircular.html http://home.pipeline.com/~hbaker1/MetaCircular.html [2]: https://gist.github.com/PuercoPop/9d192f94f88074d06625 https://gist.github.com/PuercoPop/9d192f94f88074d06625 [1]: "Informal "design patterns" are only for inexpressive languages. In Lisp, you can always express the "design pattern" formally, through a function or a macro. (...) No half-assed informal descriptions of repetitive patterns needed; if you can actually identify and express a redundancy using English language, you can also code a formal function or macro to get rid of it" — Fare in http://fare.tunes.org/files/fun/fibonacci.lisp http://fare.tunes.org/files/fun/fibonacci.lisp
- eudox 12y ago
  >quicklisp users feel free to correct me Common Lisp certainly doesn't have as many libraries as Python or Ruby, but let's not exaggerate. The ecosystem is broad and deep enough for the average programmer -- me, here -- to be perfectly productive.
mackwic 12y ago
There is always the last bias: lisp programmers, by their strong academical background, tend to be more educated CS-wise than JS, Ruby, or Python programmers, which enable them to a better understanding of a CS problem. It's almost tautological. You can't just take 20 programmers and give them a problem to solve, that's not how surveys works.
alkonaut 12y ago
The dominant languages are still c-family strictly typed imperative languages (see e.g Tiobe). The up & coming langs are those with even more powerful type systems such as F#.
- vorg 12y ago
  The Tiobe Index front page used to run a monthly historical comparison of statically typed languages against dynamic ones, but removed it about 6 months ago. There was a clear reversal in the trend away from dynamically typed languages 5 to 10 years back. I see dynamic languages as the 2000's version of the 1990's visual programming fad. Only one or two of those visual programming products (Visual Basic and maybe Delphi) survived, and the same will probably happen with dynamic languages: I'm picking Python and Javascript will be the only ones around in another decade.
  - bunderbunder 12y ago
    I don't think the RAD languages really died, their most useful features just become so standard that they stopped being notable. Visual Basic .NET and C# have more-or-less exactly the same tooling for developing UIs, for example, and on the Apple side of things there's still Interface Builder. I could see something similar happening with dynamic languages. Over the past decade, the things that once irritated me about working in static languages have largely been addressed as features like generics, type inference, and interface polymorphism became more common. But I can't imagine dynamic languages will ever go away, if anything because they're still so successful in the scripting domain.
  - philippeback 12y ago
    Doing Pharo Smalltalk here. A couple of decades of existence (Smalltalk-80, Squeak), a couple more ahead. But well, not on Tiobe top slot.
RichardFord 12y ago
Python and Ruby aren't dominant against C#, Java, and C++. JavaScript is in its own category since you kind of have to use it.
Thaxll 12y ago
I would say that people are moving away from Python / Ruby and going back to Java, JVM is very powerful nowdays.
pjmlp 12y ago
> dominant languages seem to be dynamic languages like Python, Ruby & JavaScript Where?!? JavaScript is king for those that need to target the browser, that is for sure. Now outside the browser? There are lot of languages to choose from. Python and Ruby are surely not the first to reach if one needs performance.
abecedarius 12y ago
I was a Scheme participant in this study, and nowadays I default to Python.
eudox 12y ago
My experience with Common Lisp, Python and JavaScript, is that Common Lisp (More through intrinsic properties, rather than a specific choice of tools), provides a better development environment.
vorg 12y ago
For the first time this month the top 5 languages on Tiobe add up to over 50% -- last month it was just under 50%. And those top five are the 5 "C+ languages", i.e... C (plus is implied) C++ Java (3rd to rise, with syntax based off C++) C# (4 pluses joined together to make a sharp sign) Objective C (5th to rise, tho around for longer) Whereas all the "dynamic" languages in the top 20 (i.e. Basic, PHP, Python, Perl, JavaScript, VB.NET, VB, Ruby) make up only 18% in total.
- scarmig 12y ago
  VB.NET is no more dynamic than either Java or C#. (Less so than C#, if anything: it doesn't support dynamic variables.)
  - bunderbunder 12y ago
    VB is more so than C#. Instead of having the "dynamic" type, which lets you enable late binding for specific references, it has "Option Strict Off". That one enables late binding for every single reference of type Object in the file in which it appears. And it's had that behavior for much longer than C# has; I think since the very first version of the language. Though I suspect that the implementation of late binding has become more efficient since the DLR came along.
  - theflubba 12y ago
    .NET supports awesome meta-programming. CLR allows for some very dynamic types and programs.
zak_mc_kracken 12y ago
> Now that the dominant languages seem to be dynamic languages like Python, Ruby & JavaScript, That's incorrect. Regardless of the metric (TIOBE, job boards, StackOverflow, ...), you will see that the top five languages are 90% statically typed (usually Java, C, C++, C#).

by wtbob 12y ago

agumonkey 12y ago

It seems that python development speed means well rounded libraries. And IIRC lisp is still not on par with that (quicklisp users feel free to correct me). Other than that I still think that linguistically, lisps still have an edge (and a sharp one).

mackwic 12y ago
But Ruby is an acceptable Lisp[0], and has also a lot of libraries. ;) So, how will Lisp compete ? Maybe if we look at it pragmatically, the solution is not in the performance nor in the time to develop, but in the ease of maintaining the software in the long term. A field where Lisp is not particularly brilliant. [0]: http://www.randomhacks.net/2005/12/03/why-ruby-is-an-acceptable-lisp/ http://www.randomhacks.net/2005/12/03/why-ruby-is-an-accepta...
- agumonkey 12y ago
  I forgot to mention that the main lisp implementations (SBCL) are fast. Compared to languages like these it's a done deal. Good point about long term maintenance. Ruby and Python aren't that great either, people say static typing is the way to go. Lisps are weird because they allow to hot swap most of the things which makes changing a system easy, but at the same time it leads to spaghetti images.
  - _delirium 12y ago
    My experience is that long-term image-based development isn't really that common in Lisp, maybe outside of some specialized use-cases. You can develop by mutating/saving/reloading an image over an extended period of time, but in practice people mostly develop the "usual" way, with source code that's loaded into a fresh image periodically. The use of image-oriented development then gets limited to prototyping and debugging. Being able to redefine functions/etc. on the fly (even during restarts and the like) is useful while experimenting and debugging. But then the "real" code gets written into a source file, which is reloaded into a fresh image to make sure it works. For modern muti-developer Lisp this is pretty much the only way things are done, since the expectation is that you check Lisp source into svn or git, not images.
    - adwf 12y ago
      That's pretty much exactly how I develop. I rarely type anything directly into the REPL, instead typing into the source file in emacs and then C-c C-c it over to the REPL for me. The advantage is that I get a canonical copy of the entire source code, whilst still having the ability to inspect and hotfix things through the REPL. If I then need to reboot the image or deploy to a new server, the entire source base should be completely stable and consistent. I often connect to production servers using Slime and fix little things like typos this way - then check the source into Github and have it permanently saved. It removes a lot of the stress of doing a full deployment each time you need to patch something!
    - philippeback 12y ago
      Same story with Pharo Smalltalk where we run CI jobs loading things into fresh images. Code lives in Git as well via GitFileTree.
- Curmudgel 12y ago
  > But Ruby is an acceptable Lisp[0] Yes, (as tptacek said), just like Esperanto is an acceptable English. https://news.ycombinator.com/item?id=416589 https://news.ycombinator.com/item?id=416589
- PuercoPop 12y ago
  Ruby is far from an 'acceptable' lisp. The article's first premise of what are lisp's virtues is dead wrong. First Lisp is NOT a functional language. A functional language is one that maintains referential transparency. i.e. where I can replace the reference/variable with its value its semantics are unchanged. Common Lisp is a multi-paradigm language and pervasively uses the the concept of places to setf state. And in a more general lisp sense, macros are opaque to the run-time and directly opposes referential transparency. His second statement, Ruby gives you 80% of what you need of macros, implies that we know what macros are for. Macros are not a solved problem, you can see Racket is actively researching macros. For example, how does one do meaningful error reporting in macros? And given that macros, generally, are programming at compile time the statement is as analogous to saying we know what we are programming for, a statement I couldn't disagree more with. The quid of Lisp I would argue is not specifically macros, but its 'meta-circular semantics', that is to say, the capacity of lisp to speak of itself in a meaningful way[0][1]. For example, in C++ we can speak of C++ but not in C++ but in its template language, that is to say a meta language. Lisp is its own meta language. We could also speak of Python in Python, for example express Python's for loop in python[2], except there is now way to replace python's definition of for with my own. BTW, that doesn't mean Ruby isn't a good language. Lisp is not an idyllic standard from which to measure how good all other languages are. For example, Smalltalk is far from being a Lisp, that doesn't mean it is not good. [0]: http://home.pipeline.com/~hbaker1/MetaCircular.html http://home.pipeline.com/~hbaker1/MetaCircular.html [2]: https://gist.github.com/PuercoPop/9d192f94f88074d06625 https://gist.github.com/PuercoPop/9d192f94f88074d06625 [1]: "Informal "design patterns" are only for inexpressive languages. In Lisp, you can always express the "design pattern" formally, through a function or a macro. (...) No half-assed informal descriptions of repetitive patterns needed; if you can actually identify and express a redundancy using English language, you can also code a formal function or macro to get rid of it" — Fare in http://fare.tunes.org/files/fun/fibonacci.lisp http://fare.tunes.org/files/fun/fibonacci.lisp
eudox 12y ago
>quicklisp users feel free to correct me Common Lisp certainly doesn't have as many libraries as Python or Ruby, but let's not exaggerate. The ecosystem is broad and deep enough for the average programmer -- me, here -- to be perfectly productive.

mackwic 12y ago

There is always the last bias: lisp programmers, by their strong academical background, tend to be more educated CS-wise than JS, Ruby, or Python programmers, which enable them to a better understanding of a CS problem. It's almost tautological. You can't just take 20 programmers and give them a problem to solve, that's not how surveys works.

alkonaut 12y ago

The dominant languages are still c-family strictly typed imperative languages (see e.g Tiobe). The up & coming langs are those with even more powerful type systems such as F#.

vorg 12y ago
The Tiobe Index front page used to run a monthly historical comparison of statically typed languages against dynamic ones, but removed it about 6 months ago. There was a clear reversal in the trend away from dynamically typed languages 5 to 10 years back. I see dynamic languages as the 2000's version of the 1990's visual programming fad. Only one or two of those visual programming products (Visual Basic and maybe Delphi) survived, and the same will probably happen with dynamic languages: I'm picking Python and Javascript will be the only ones around in another decade.
- bunderbunder 12y ago
  I don't think the RAD languages really died, their most useful features just become so standard that they stopped being notable. Visual Basic .NET and C# have more-or-less exactly the same tooling for developing UIs, for example, and on the Apple side of things there's still Interface Builder. I could see something similar happening with dynamic languages. Over the past decade, the things that once irritated me about working in static languages have largely been addressed as features like generics, type inference, and interface polymorphism became more common. But I can't imagine dynamic languages will ever go away, if anything because they're still so successful in the scripting domain.
- philippeback 12y ago
  Doing Pharo Smalltalk here. A couple of decades of existence (Smalltalk-80, Squeak), a couple more ahead. But well, not on Tiobe top slot.

RichardFord 12y ago

Python and Ruby aren't dominant against C#, Java, and C++. JavaScript is in its own category since you kind of have to use it.

Thaxll 12y ago

I would say that people are moving away from Python / Ruby and going back to Java, JVM is very powerful nowdays.

pjmlp 12y ago

> dominant languages seem to be dynamic languages like Python, Ruby & JavaScript Where?!? JavaScript is king for those that need to target the browser, that is for sure. Now outside the browser? There are lot of languages to choose from. Python and Ruby are surely not the first to reach if one needs performance.

abecedarius 12y ago

I was a Scheme participant in this study, and nowadays I default to Python.

eudox 12y ago

My experience with Common Lisp, Python and JavaScript, is that Common Lisp (More through intrinsic properties, rather than a specific choice of tools), provides a better development environment.

vorg 12y ago

For the first time this month the top 5 languages on Tiobe add up to over 50% -- last month it was just under 50%. And those top five are the 5 "C+ languages", i.e... C (plus is implied) C++ Java (3rd to rise, with syntax based off C++) C# (4 pluses joined together to make a sharp sign) Objective C (5th to rise, tho around for longer) Whereas all the "dynamic" languages in the top 20 (i.e. Basic, PHP, Python, Perl, JavaScript, VB.NET, VB, Ruby) make up only 18% in total.

scarmig 12y ago
VB.NET is no more dynamic than either Java or C#. (Less so than C#, if anything: it doesn't support dynamic variables.)
- bunderbunder 12y ago
  VB is more so than C#. Instead of having the "dynamic" type, which lets you enable late binding for specific references, it has "Option Strict Off". That one enables late binding for every single reference of type Object in the file in which it appears. And it's had that behavior for much longer than C# has; I think since the very first version of the language. Though I suspect that the implementation of late binding has become more efficient since the DLR came along.
- theflubba 12y ago
  .NET supports awesome meta-programming. CLR allows for some very dynamic types and programs.

zak_mc_kracken 12y ago

> Now that the dominant languages seem to be dynamic languages like Python, Ruby & JavaScript, That's incorrect. Regardless of the metric (TIOBE, job boards, StackOverflow, ...), you will see that the top five languages are 90% statically typed (usually Java, C, C++, C#).