5 ms·

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 i

by 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

by mackwic 12y ago

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