The Future Of Lisp
This is a translation of an article by Steven Degutis.
the Future of Lisp
Lately I often began to reflect on the existing dialects of Lisp and about in what direction we are moving. In particular, I considered the possibility of writing another Lisp dialect, and the areas in which it is useful.
If you are not familiar with it, Lisp is a wonderful family of languages; its extremely minimal syntax lets us think almost at the level of algorithms, not bothered about non-obvious syntax or any language framework.
Traditionally, there is a Scheme that is useful only for teaching in universities because of the paucity of support libraries, there are also Common Lisp, which is a terrible, terrible mess (think C++, but with a sea of parentheses).
Clojure is undoubtedly the most popular dialect to date. Some people would argue that it is the only Lisp that has practical value at the present time. It appeared syntactic sugar for large number of data types, successful integration with the JVM, gone are all the clunky parts, characteristic of traditional Lisp languages.
However, there are others, such as Nu, which is the panacea, if you create something for IOS or Mac, but don't like pointers. (Hey, but it's something like MacRuby!)
But why Nu failed to take off? And why CL and Scheme died? Why is only one Clojure is gaining momentum? Could another dialect of Lisp to expect the same success?
Undoubtedly, the syntax is not going anywhere. S-expressions do in Lisp is extremely simple and you can use a cool feature, which we call macros, but all these brackets are just disgusting, and no one could cope with them if only it doesn't work on Emacs+pardeit. The biggest advantage of Lisp is probably its biggest weakness.
But we should also not forget about portability. No one will write the app entirely in Scheme, since it has no standard libraries. Clojure switched to the JVM, which is not only crossplatforming, but also rich in useful built-in classes and third party libraries. Thanks to Java, the JVM is an integrated and stable platform.
But what we care about platform?
Nu is a very interesting dialect. It was created to make the development process under IOS / Mac easier and more fun. It provides a set of Lisp macros and a whole bunch of useful tools that will help you to begin to develop.
But Cocoa — SDK, not the platform. Anyone who tells you otherwise is trying to sell something (probably Xcode). In Mac/IOS applications all feature a graphical user interface, and each component which you will need at any stage of development, is already provided for you (you need to add, they are closely related to each other) within the platform. You only need a little imagination.
So what's wrong with that?
When writing applications in Cocoa, you get the models, controllers, views, and needs "glue" them together the minimum amount of code in Objective-C. Thus, you lose the ability to use all features of Lisp. Almost every line of code on Nu (offhand — about 95%) and that will be what to call code in Objective-C that makes use of Lisp just kind of silly.
In addition, most libraries Apple just have no meaning outside the context of this type of development. So almost nothing can be done to effectively use the functional programming paradigm, and besides, it is necessary to avoid low-level functionality With the Apple just to maintain compatibility with Lisp.
It turns out that just pointless not to use Apple's "superglue"(talking about Objective-C) in favor of our "homegrown" glue(Nu), it's just not worth it. This is essentially a problem of any SDK is not only Cocoa, but also Android and others.
The JVM provides the freedom. The architecture is completely in your hands. You can form the model. The presentation layer is selected depending on the type of application(server, GUI, command-line utilities, etc.). You have complete freedom from the beginning to the end.
searching for the right platform
But this is not a unique feature of the JVM. The same thing happens with C, C++, Python, and Ruby, right? Let's face it, Lisp embedded in Ruby or Python, is redundant: these languages allow you to implement 90% of the desired functionality, so why invent something only for the sake of macros, moreover, such a system will be even and slow.
And of course just can't be normal about the compatibility of such algorithmic language like Lisp with such low-level language like C, or in spaghetti-generating language like C++. Someone deallocates memory, why, when, and anyway, where's my chicken? All this is too confusing.
Other potential niches
For a second can zip this: to go the way of Ruby and Python, having written an interpreted dialect of Lisp with its own set of standard libraries. In the end, these two languages have become quite successful, isn't it?
But we quickly come down to earth with the realization that these languages, each of which has its own programming environment(no Emacs), which anyone can quickly learn to become expert in the language in a matter of weeks. An S-expression, characteristic of Lisp, simply will not allow this.
Or a new dialect of Lisp could go the way Go and become a static language with an incredibly-fast compile time and runtime. But I don't think this is the most important. Compile time can not be less than 0 — which is about where we are Ruby and Python. And the run time theoretically can be much smaller than the execution time of the jvm, except in certain circumstances (the planets lined up in a row and you proprygat on one foot 3 times).
The truth is, no other platform right now can provide the standard libraries, third-party support, extensibility, features, community, and portability at that level. it makes the JVM. Clojure is currently the best incarnation of Lisp, and will remain so in the foreseeable future.
Article based on information from habrahabr.ru
the Future of Lisp
Lately I often began to reflect on the existing dialects of Lisp and about in what direction we are moving. In particular, I considered the possibility of writing another Lisp dialect, and the areas in which it is useful.
If you are not familiar with it, Lisp is a wonderful family of languages; its extremely minimal syntax lets us think almost at the level of algorithms, not bothered about non-obvious syntax or any language framework.
market Position
Traditionally, there is a Scheme that is useful only for teaching in universities because of the paucity of support libraries, there are also Common Lisp, which is a terrible, terrible mess (think C++, but with a sea of parentheses).
Clojure is undoubtedly the most popular dialect to date. Some people would argue that it is the only Lisp that has practical value at the present time. It appeared syntactic sugar for large number of data types, successful integration with the JVM, gone are all the clunky parts, characteristic of traditional Lisp languages.
However, there are others, such as Nu, which is the panacea, if you create something for IOS or Mac, but don't like pointers. (Hey, but it's something like MacRuby!)
But why Nu failed to take off? And why CL and Scheme died? Why is only one Clojure is gaining momentum? Could another dialect of Lisp to expect the same success?
the Curse... and a blessing
Undoubtedly, the syntax is not going anywhere. S-expressions do in Lisp is extremely simple and you can use a cool feature, which we call macros, but all these brackets are just disgusting, and no one could cope with them if only it doesn't work on Emacs+pardeit. The biggest advantage of Lisp is probably its biggest weakness.
But we should also not forget about portability. No one will write the app entirely in Scheme, since it has no standard libraries. Clojure switched to the JVM, which is not only crossplatforming, but also rich in useful built-in classes and third party libraries. Thanks to Java, the JVM is an integrated and stable platform.
But what we care about platform?
Nu is a very interesting dialect. It was created to make the development process under IOS / Mac easier and more fun. It provides a set of Lisp macros and a whole bunch of useful tools that will help you to begin to develop.
But Cocoa — SDK, not the platform. Anyone who tells you otherwise is trying to sell something (probably Xcode). In Mac/IOS applications all feature a graphical user interface, and each component which you will need at any stage of development, is already provided for you (you need to add, they are closely related to each other) within the platform. You only need a little imagination.
So what's wrong with that?
When writing applications in Cocoa, you get the models, controllers, views, and needs "glue" them together the minimum amount of code in Objective-C. Thus, you lose the ability to use all features of Lisp. Almost every line of code on Nu (offhand — about 95%) and that will be what to call code in Objective-C that makes use of Lisp just kind of silly.
In addition, most libraries Apple just have no meaning outside the context of this type of development. So almost nothing can be done to effectively use the functional programming paradigm, and besides, it is necessary to avoid low-level functionality With the Apple just to maintain compatibility with Lisp.
It turns out that just pointless not to use Apple's "superglue"(talking about Objective-C) in favor of our "homegrown" glue(Nu), it's just not worth it. This is essentially a problem of any SDK is not only Cocoa, but also Android and others.
The JVM provides the freedom. The architecture is completely in your hands. You can form the model. The presentation layer is selected depending on the type of application(server, GUI, command-line utilities, etc.). You have complete freedom from the beginning to the end.
searching for the right platform
But this is not a unique feature of the JVM. The same thing happens with C, C++, Python, and Ruby, right? Let's face it, Lisp embedded in Ruby or Python, is redundant: these languages allow you to implement 90% of the desired functionality, so why invent something only for the sake of macros, moreover, such a system will be even and slow.
And of course just can't be normal about the compatibility of such algorithmic language like Lisp with such low-level language like C, or in spaghetti-generating language like C++. Someone deallocates memory, why, when, and anyway, where's my chicken? All this is too confusing.
Other potential niches
For a second can zip this: to go the way of Ruby and Python, having written an interpreted dialect of Lisp with its own set of standard libraries. In the end, these two languages have become quite successful, isn't it?
But we quickly come down to earth with the realization that these languages, each of which has its own programming environment(no Emacs), which anyone can quickly learn to become expert in the language in a matter of weeks. An S-expression, characteristic of Lisp, simply will not allow this.
Or a new dialect of Lisp could go the way Go and become a static language with an incredibly-fast compile time and runtime. But I don't think this is the most important. Compile time can not be less than 0 — which is about where we are Ruby and Python. And the run time theoretically can be much smaller than the execution time of the jvm, except in certain circumstances (the planets lined up in a row and you proprygat on one foot 3 times).
Ahead, in the foreseeable future!
The truth is, no other platform right now can provide the standard libraries, third-party support, extensibility, features, community, and portability at that level. it makes the JVM. Clojure is currently the best incarnation of Lisp, and will remain so in the foreseeable future.
Comments
Post a Comment