But compared to a language like Ruby or Python, Lisp is an anachronism. No standardization. No standard Unicode, threads. No XML or RSS libs, no web server, no web framework, no GUI tools, just a bunch of incompatible implementations.
This is a very common wish, but there's a fallacy in the first sentence. The implied comparison is between language implementations (Ruby, Python) and a language specification (Common Lisp, Scheme) or a metalanguage idealisation (Lisp). There are plenty of implementations of Lisp and Scheme which have available for them all of the elements on the wishlist: but they are not standard across all implementations of a specification, or all instantiations of the metalanguage.
There is indeed a need for better distribution integration for the various Free lisps out there (of which there are many) for the newcomers not to feel so intimidated by the need to assemble their systems themselves: but the inherently misleading comparison between specification and implementation should not frame the discussion, because those who need the bits and pieces can assemble them.
Then again, in what other industry do those struggling to pay for college or to get through unemployment amuse themselves by giving away the very craft that they think they're going to sell if they're ever employed later?
Let's see... from personal experience, the music industry and the scientific research industry; anecdotally, the acting industry, the journalistic industry, the DJ industry, and no doubt many more. The common factor? Things that people seem to enjoy doing for their own sake.
You can't give away huge quantities of something that has intrinsic value and expect it not to have an effect on market pricing.
Nor can you usefully argue against people doing something that for them has positive utility, even if that decreases your net utility. (If it decreases yours by more than theirs increases, though, you can offer to pay people not to develop Free Software and come out better off. Feel free to contact me to discuss terms).
In LISP data and code are stored the same way, as lists. This is the ultimate closure.
This is mostly true, though I feel it's probably necessary to make the point that these days Lisp code tends to be compiled to machine code, so in that sense data and code are not at all stored in the same way. Where this statement is true is that during the act of compilation the parse tree is effectively exposed to the programmer, who can manipulate it easily using built-in list operations.
It's possibly also worth noting that not all closures are necessarily seen as a good thing; for instance, while the concept of generic functions exists in Common Lisp, most of the built in functions cannot have methods written for them; in other words, they're not generic. Why not? For practical, efficiency reasons; you don't want to have a call of the form
(+ x y)
to go through a type test, as it would have to were the function "+" available for redefinition.
I am not only an amateur programmer but also an amateur musician (I'm a physicist by trade); I know about RSI, as it's very common in the musical world (and I've suffered from it myself).
I've been having Alexander Technique lessons for the last three months, and I attribute the disappearance of my back pain to those lessons. I realise that this is only anecdotal evidence, but many professional musicians and actors swear by the Technique as a way of avoiding posture problems and the associated performance problems.
Slashdot Mirror
This is a very common wish, but there's a fallacy in the first sentence. The implied comparison is between language implementations (Ruby, Python) and a language specification (Common Lisp, Scheme) or a metalanguage idealisation (Lisp). There are plenty of implementations of Lisp and Scheme which have available for them all of the elements on the wishlist: but they are not standard across all implementations of a specification, or all instantiations of the metalanguage.
There is indeed a need for better distribution integration for the various Free lisps out there (of which there are many) for the newcomers not to feel so intimidated by the need to assemble their systems themselves: but the inherently misleading comparison between specification and implementation should not frame the discussion, because those who need the bits and pieces can assemble them.
Let's see... from personal experience, the music industry and the scientific research industry; anecdotally, the acting industry, the journalistic industry, the DJ industry, and no doubt many more. The common factor? Things that people seem to enjoy doing for their own sake.
Nor can you usefully argue against people doing something that for them has positive utility, even if that decreases your net utility. (If it decreases yours by more than theirs increases, though, you can offer to pay people not to develop Free Software and come out better off. Feel free to contact me to discuss terms).
It's possibly also worth noting that not all closures are necessarily seen as a good thing; for instance, while the concept of generic functions exists in Common Lisp, most of the built in functions cannot have methods written for them; in other words, they're not generic. Why not? For practical, efficiency reasons; you don't want to have a call of the form to go through a type test, as it would have to were the function "+" available for redefinition.
I am not only an amateur programmer but also an amateur musician (I'm a physicist by trade); I know about RSI, as it's very common in the musical world (and I've suffered from it myself).
I've been having Alexander Technique lessons for the last three months, and I attribute the disappearance of my back pain to those lessons. I realise that this is only anecdotal evidence, but many professional musicians and actors swear by the Technique as a way of avoiding posture problems and the associated performance problems.
Cheers,
Christophe