Future Lisp
This is a translation of the article by Stephen Degutis .
Future lisp
Recently, I often began to think about existing Lisp dialects and the direction in which we are moving. In particular, I considered the possibility of writing another Lisp dialect, and those areas in which it would be useful.
If you are not familiar with it, Lisp is a wonderful language family; its extremely minimalistic syntax allows us to think almost at the level of algorithms, without bothering about the non-obvious syntax or any language framework.
')
Traditionally, there is Scheme, which is useful except for teaching at universities due to the scarcity of supported libraries, there is also Common Lisp, which is a terrible, terrible confusion (imagine C ++, but with a whole sea of ​​brackets).
Clojure is undoubtedly the most popular dialect today. Some people would even argue that this is the only Lisp that has practical value at the moment. It appeared syntactic sugar for a large number of data types, successful integration with the JVM, disappeared all the clumsy parts characteristic of traditional Lisp-languages.
However, there are others, such as Nu, which is a panacea if you create something for iOS or Mac, but do not like pointers. (Hey, this one looks like a MacRuby!)
But why Nu failed to fly up? And why did CL and Scheme die? Why is only one Clojure gaining momentum? Can another Lisp dialect expect the same success?
Undoubtedly, there is no getting away from syntax. S-expressions make Lisp extremely simple and allow you to use a cool feature, which we call macros, but all these brackets are just disgusting, and no one person can handle them unless it works on Emacs + pardeit. The biggest virtue of Lisp is probably its biggest weakness.
But we also should not forget about portability. No one will write an application completely on Scheme, since there are no standard libraries for it. Clojure shifted to JVM, which is not only cross-platform, but also replete with built-in useful classes and third-party libraries. Thanks to Java, the JVM is a holistic and stable platform.
But what do we care about the platform?
Nu is a very interesting dialect. It was created to make the development process for IOS / Mac easier and more fun. It provides a set of Lisp macros, as well as a whole bunch of useful tools to help you get started developing.
But Cocoa is an SDK, not a platform. Anyone who tells you otherwise is trying to sell you something (probably Xcode). In Mac / IOS applications, the entire feature in the graphical interface, and every component that you need at any stage of development, is already provided for you (you need to add, they are closely related to each other) within the framework of the platform. All you need is a little imagination.
So what's wrong with that?
When writing applications in Cocoa, you get models, controllers, views, and must “glue” them together with a minimum amount of Objective-C code. Thus, you lose the ability to apply all Lisp features. Almost every line of Nu code (about 95% offhand) is what will cause Objective-C code, which makes using Lisp just ridiculous.
In addition, most Apple libraries simply have no meaning outside the context of this type of development. So practically nothing can be done to effectively use the functional programming paradigm, and besides, you have to avoid the low-level C functionality of Apple in order to simply maintain Lisp compatibility.
It turns out that it is simply 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 the problem of any SDK - not only Cocoa, but Android, and others.
JVM provides freedom. The architecture is completely in your hands. You form the model yourself. The presentation level is selected depending on the type of application (server, GUI, command line utilities, etc.). You have complete freedom from the very beginning to the end.
Finding the right platform
But this is not a unique feature of the JVM. The same thing happens with C, and C ++, Python and Ruby, isn't it? 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 just for the sake of macros, and besides, such a system will also be slow.
And of course, there simply cannot be normal compatibility of such an algorithmic language as Lisp with such a low-level language like C, or such a spaghetti-generating language like C ++. Someone frees the memory, why, when, and in general, where is my chicken? All this is too confusing.
Other potential niches
For a moment, such an idea can be popped up: follow the path of Ruby and Python by writing an interpretable Lisp dialect with its own set of standard libraries. In the end, these two languages ​​became quite successful, didn't they?
But we quickly descend to earth, with the knowledge that these languages, each of which has its own programming environment (no Emacs) that anyone can quickly learn to become an expert in the language in a matter of weeks. Lisp-specific S-expressions simply won't allow it.
Or a new Lisp dialect could go the Go path and become a static language with incredibly fast compilation and execution times. But I do not think this is the most important. Compilation time cannot be less than 0 - and this is approximately where Ruby and Python are located. And the execution time theoretically can not be much less than the jvm execution time, unless under certain circumstances (the planets line up, and you jump on one leg 3 times).
The truth is, no other platform right now can provide standard libraries, third-party support, extensibility, broad functionality, community, and portability at the level at which the JVM does. Clojure is currently the best incarnation of Lisp, and will remain so in the foreseeable future.
Future lisp
Recently, I often began to think about existing Lisp dialects and the direction in which we are moving. In particular, I considered the possibility of writing another Lisp dialect, and those areas in which it would be useful.
If you are not familiar with it, Lisp is a wonderful language family; its extremely minimalistic syntax allows us to think almost at the level of algorithms, without bothering about the non-obvious syntax or any language framework.
')
Market position
Traditionally, there is Scheme, which is useful except for teaching at universities due to the scarcity of supported libraries, there is also Common Lisp, which is a terrible, terrible confusion (imagine C ++, but with a whole sea of ​​brackets).
Clojure is undoubtedly the most popular dialect today. Some people would even argue that this is the only Lisp that has practical value at the moment. It appeared syntactic sugar for a large number of data types, successful integration with the JVM, disappeared all the clumsy parts characteristic of traditional Lisp-languages.
However, there are others, such as Nu, which is a panacea if you create something for iOS or Mac, but do not like pointers. (Hey, this one looks like a MacRuby!)
But why Nu failed to fly up? And why did CL and Scheme die? Why is only one Clojure gaining momentum? Can another Lisp dialect expect the same success?
Curse ... and blessing
Undoubtedly, there is no getting away from syntax. S-expressions make Lisp extremely simple and allow you to use a cool feature, which we call macros, but all these brackets are just disgusting, and no one person can handle them unless it works on Emacs + pardeit. The biggest virtue of Lisp is probably its biggest weakness.
But we also should not forget about portability. No one will write an application completely on Scheme, since there are no standard libraries for it. Clojure shifted to JVM, which is not only cross-platform, but also replete with built-in useful classes and third-party libraries. Thanks to Java, the JVM is a holistic and stable platform.
But what do we care about the platform?
Nu is a very interesting dialect. It was created to make the development process for IOS / Mac easier and more fun. It provides a set of Lisp macros, as well as a whole bunch of useful tools to help you get started developing.
But Cocoa is an SDK, not a platform. Anyone who tells you otherwise is trying to sell you something (probably Xcode). In Mac / IOS applications, the entire feature in the graphical interface, and every component that you need at any stage of development, is already provided for you (you need to add, they are closely related to each other) within the framework of the platform. All you need is a little imagination.
So what's wrong with that?
When writing applications in Cocoa, you get models, controllers, views, and must “glue” them together with a minimum amount of Objective-C code. Thus, you lose the ability to apply all Lisp features. Almost every line of Nu code (about 95% offhand) is what will cause Objective-C code, which makes using Lisp just ridiculous.
In addition, most Apple libraries simply have no meaning outside the context of this type of development. So practically nothing can be done to effectively use the functional programming paradigm, and besides, you have to avoid the low-level C functionality of Apple in order to simply maintain Lisp compatibility.
It turns out that it is simply 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 the problem of any SDK - not only Cocoa, but Android, and others.
JVM provides freedom. The architecture is completely in your hands. You form the model yourself. The presentation level is selected depending on the type of application (server, GUI, command line utilities, etc.). You have complete freedom from the very beginning to the end.
Finding the right platform
But this is not a unique feature of the JVM. The same thing happens with C, and C ++, Python and Ruby, isn't it? 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 just for the sake of macros, and besides, such a system will also be slow.
And of course, there simply cannot be normal compatibility of such an algorithmic language as Lisp with such a low-level language like C, or such a spaghetti-generating language like C ++. Someone frees the memory, why, when, and in general, where is my chicken? All this is too confusing.
Other potential niches
For a moment, such an idea can be popped up: follow the path of Ruby and Python by writing an interpretable Lisp dialect with its own set of standard libraries. In the end, these two languages ​​became quite successful, didn't they?
But we quickly descend to earth, with the knowledge that these languages, each of which has its own programming environment (no Emacs) that anyone can quickly learn to become an expert in the language in a matter of weeks. Lisp-specific S-expressions simply won't allow it.
Or a new Lisp dialect could go the Go path and become a static language with incredibly fast compilation and execution times. But I do not think this is the most important. Compilation time cannot be less than 0 - and this is approximately where Ruby and Python are located. And the execution time theoretically can not be much less than the jvm execution time, unless under certain circumstances (the planets line up, and you jump on one leg 3 times).
Ahead in the foreseeable future!
The truth is, no other platform right now can provide standard libraries, third-party support, extensibility, broad functionality, community, and portability at the level at which the JVM does. Clojure is currently the best incarnation of Lisp, and will remain so in the foreseeable future.
Source: https://habr.com/ru/post/126543/
All Articles