Lisp, too, is mainstream | LispCast
The article questions whether Greenspuns Tenth rule is still in effect. The article states that many of the features that made Lisp great are starting to find their way, or have already found their way into other languages. Of course not everything has been copied, macros come to mind as probably about the last feature that doesn't exist somewhere else. But, the author makes the point that there are features that other languages have that Lisp lacks. Namely things like huge standard libraries (java), large user bases, standards support, etc. These are not inconsequential when attempting to build a new product. The time saved by choosing Lisp, may be swallowed up in having to write code libraries for specific tasks. For example, if Lisp didn't have an SMTP library, would it make more sense to write a quick tool in python and use it's smtp library, rather then do it in lisp and have to build your own library? This is a dangerous line of reasoning for the lisper because you tend to then start thinking that language becomes less important. The quality and scope of the standard libraries becomes the bigger issue. Should we all be using PHP and Java?
In the comments, a discussion item was brought up about the fact that most other languages have a single canonical implementation that everyone uses. Whereas lisp has many implementations. So, not only must a developer decide on whether they want to use lisp or lisp like languages at all, but they must also decide on a dialect. Some push the expensive commercial lisps, others push for SBCL or PLT Scheme, open source implementations. Either way, when trying to incorporate a set of code into the lisp you've decided to use, you will probably have to do some porting of the package unless it is specifically written for the lisp you've decided to use.
As I have discussed before in previous postings, I believe this is one of the huge issues when trying to decide to use lisp for a particular project. The other for me right now is multi-processing. This is an area where no one has built a compelling, general purpose, set of functionality for lisp that takes advantage of multiple core processors and grids of computers. I hope someone does. Ironically, Google has shown that you can do grid processing even in a language like C++. So, perhaps this is not as big a deal as one thinks. Python too, appears that it will forever have a single threaded core. Yet, you can find grid computing tools for python, an arguably horrible language for parallel programming. Yet, it's ease of development and large set of libraries make it an attractive tool in some scenarios.
So, can Lisp overcome the problems of many different implementations and a standard library that seems to trail languages like Java, C# and Python? Can it effectively compete against languages that are exploring massively parallel programmaing like erlang, scala and haskel? Hopefully it can.
The article questions whether Greenspuns Tenth rule is still in effect. The article states that many of the features that made Lisp great are starting to find their way, or have already found their way into other languages. Of course not everything has been copied, macros come to mind as probably about the last feature that doesn't exist somewhere else. But, the author makes the point that there are features that other languages have that Lisp lacks. Namely things like huge standard libraries (java), large user bases, standards support, etc. These are not inconsequential when attempting to build a new product. The time saved by choosing Lisp, may be swallowed up in having to write code libraries for specific tasks. For example, if Lisp didn't have an SMTP library, would it make more sense to write a quick tool in python and use it's smtp library, rather then do it in lisp and have to build your own library? This is a dangerous line of reasoning for the lisper because you tend to then start thinking that language becomes less important. The quality and scope of the standard libraries becomes the bigger issue. Should we all be using PHP and Java?
In the comments, a discussion item was brought up about the fact that most other languages have a single canonical implementation that everyone uses. Whereas lisp has many implementations. So, not only must a developer decide on whether they want to use lisp or lisp like languages at all, but they must also decide on a dialect. Some push the expensive commercial lisps, others push for SBCL or PLT Scheme, open source implementations. Either way, when trying to incorporate a set of code into the lisp you've decided to use, you will probably have to do some porting of the package unless it is specifically written for the lisp you've decided to use.
As I have discussed before in previous postings, I believe this is one of the huge issues when trying to decide to use lisp for a particular project. The other for me right now is multi-processing. This is an area where no one has built a compelling, general purpose, set of functionality for lisp that takes advantage of multiple core processors and grids of computers. I hope someone does. Ironically, Google has shown that you can do grid processing even in a language like C++. So, perhaps this is not as big a deal as one thinks. Python too, appears that it will forever have a single threaded core. Yet, you can find grid computing tools for python, an arguably horrible language for parallel programming. Yet, it's ease of development and large set of libraries make it an attractive tool in some scenarios.
So, can Lisp overcome the problems of many different implementations and a standard library that seems to trail languages like Java, C# and Python? Can it effectively compete against languages that are exploring massively parallel programmaing like erlang, scala and haskel? Hopefully it can.
0 comments:
Post a Comment