The future of Lisp

Original author: Steven Degutis
  • Transfer
This is a translation of an article by Stephen Degoutis .

The future of Lisp


Recently, I often began to think about the existing dialects of Lisp and about which direction 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 already familiar with it, Lisp is a great family of languages; its extremely minimal syntax allows us to think almost at the level of algorithms, without bothering about non-obvious syntax or any kind of language framework.

Market position


Traditionally, there is a Scheme, which is only useful for teaching at universities because of the scarcity of supported libraries, there is also Common Lisp, which is a terrible, terrible mess (imagine C ++, but with a whole sea of ​​brackets).

Clojure is undoubtedly the most popular dialect to date. Some people would argue that this is the only Lisp that has practical value at the moment. It introduced syntactic sugar for a large number of data types, successful integration with the JVM, all the awkward parts characteristic of traditional Lisp languages ​​disappeared.

However, there are others, such as Nu, which is a panacea if you are creating something for iOS or Mac, but don’t like pointers. (Hey, it looks like MacRuby!)

But why didn’t Nu take off? 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, the syntax is not going anywhere. S-expressions make Lisp extremely simple and allow you to use a cool feature that we call macros, but all of these brackets are disgusting and no one can handle them unless it works on Emacs + pardeit. Lisp's biggest virtue is probably his greatest weakness.

But we also must not forget about portability. No one will write an application entirely on Scheme, since there are no standard libraries for it. Clojure has reoriented itself to the 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 iOS / Mac development process easier and more fun. It provides a set of Lisp macros, as well as a host 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 whole thing is 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 connected with 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 you have to “glue” them together with a minimal amount of Objective-C code. Thus, you lose the opportunity to apply all the features of Lisp. Almost every line of Nu code (offhand - about 95%) will only be able to call Objective-C code, which makes using Lisp just ridiculous.

In addition, most Apple libraries simply do not have any 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 functional of Apple, just to maintain compatibility with Lisp.

It turns out that it is simply pointless not to use the 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 also Android, and others.

JVM provides freedom. Architecture is completely at your fingertips. 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, right? Let's face it, Lisp, built into Ruby or Python, is redundant: these languages ​​allow you to implement 90% of the desired functionality, so why come up with something just for the sake of macros, moreover, such a system will also be slow.

And of course, there simply cannot be normal compatibility between an algorithmic language such as Lisp and a low-level language such as C, or a spaghetti-generating language like C ++. Someone frees up memory, why, when, and in general, where is my chicken? All this is too confusing.

Other potential niches

For a second, such an idea may flash: go along the path of Ruby and Python, writing an interpreted Lisp dialect with its own set of standard libraries. In the end, these two languages ​​became quite successful, right?

But we quickly descend to earth, with the realization that these languages, each of which has its own programming environment (no Emacs), which anyone can quickly master in order to become an expert in the language in a matter of weeks. S-expressions specific to Lisp simply will not allow this.

Or the new Lisp dialect could go the Go way 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 - which is roughly where Ruby and Python are. And theoretically, the runtime cannot be much less than the jvm runtime, except under certain circumstances (the planets line up and you jump on one leg 3 times).

Ahead, for the foreseeable future!


The truth is, no other platform right now can provide standard libraries, third-party support, extensibility, wide functionality, community, and portability at the level at which the JVM does it. Clojure is currently the best incarnation of Lisp, and will remain so for the foreseeable future.

Also popular now: