There is a saying about the band Velvet Underground - that not many people bought their records, but everyone who bought one went out and started their own band. I think Lisp is kind of similar - its influence is much larger than its fame, but ever language designer is inspired by it to some extent.<p>I do think Lisp kind of missed the boat when a wave of dynamic languages (Perl, Python, Ruby) went mainstream. Today the most exciting developments in language design seem to be around static type systems, type inference etc.
It's been so sad to see that while the AI winter ended, the Lisp winter that started around the same time never did. Maybe it's coming back after consolidation on the languages end: SBCL and Clojure are coming ahead as clear winners, and are quite powerful.<p>I'm sure I'm not the only guy who started learning Lisp after reading Paul Graham's essays, and I'm going to keep using Lisp for several reasons, but the momentum just isn't there.
I find the Lisp variants to be lovely right up until I want to package and ship an actual application to a normal human being. Then they are quite clumsy. I find the same to be true of a number of other more recently popular high level languages. I've always assumed it was because graduate students never got to the point where they ship anything.
LISP always makes me sad. It's a language from which all modern languages could learn so much (and currently a lot of features of LISP get cloned). LISP Machines pioneered basically 90% of what modern computers and the internet do today.<p>Yet, it's a very niche language, an almost forgotten artifact of time.
I'm disappointed by this paper. The general review of the language is of the sort that you can find a dime a dozen on LISP enthusiast sites--so this paper does little to effectively recruit existing programmers to the cause. On the other hand, the references to current bioinformatics projects using LISP is helpful as an index, but provide few details to convince a biologist that they're worth checking out--so I'm not convinced on that side either. The "key point" of a forthcoming BioLisp is embarrassingly glossed over.<p>I think the paper would be much stronger if it focused on that BioLisp aspect, talking about:<p>* What is BioLisp? A mere web portal pointing to various resources across various languages? An attempt to create a curated installation of version-compatible libraries for a specific LFL? An attempt to develop a fully-integrated framework for that LFL??<p>(I think Sage for Python might be a useful model here, but if you were trying to build that, you'd have to start by picking your LFL, which the authors at present seem unwilling to advocate. That in itself demonstrates one of the main liabilities at present in adopting LISP--the community is fractured between Racket, Scheme, Clojure, and various implementations of Common LISP--often to the extent that they argue over whether their respective opponent languages even _deserve_ to be called LISPs. And, of course, in this forum we even have Arc fanatics to add to the lot. ;-) )<p>* What challenges face biologists attempting to use LISP in their work? How does BioLisp help to address those? ("Your language lacks macros" is not an argument at a sufficiently detailed level, I'm afraid. Rather, actually show them a DSL built in LISP that they will desperately want!)<p>* For that matter, what challenges face biologists attempting to use R/Python/Julia/etc for their work? How does BioLisp help to address those?<p>* What promising pieces could BioLisp be built upon? What pieces are missing? What pieces need modernization?<p>By all means, I encourage scientists and LISP enthusiasts to make the case that biologists should/could be using LISP--but make sure you actually make the case!
Great writeup on specific advantages of Lisp languages! I have used Lisp on two long term medical and bio information consulting projects (one also used semantic web/linked data tech) and I could not agree more that building Lisp up to be a new language for applications, repl based development, and the expressiveness of Lisp languages are all huge wins in building knowledge intensive systems.<p>EDIT: I will add that although I enjoy using Lisp languages, and have written a few Lisp books, that I don’t like to talk anyone into using any particular programming language or technology stack. There is a difference in enjoying our own choices to telling other people what choices they should make.
> "Lists, which are a generalization of graphs, are extraordinarily well supported by Lisp."<p>I always thought of linked lists as a special kind of graph, where each node except the head and tail had exactly one incoming edge and one outgoing edge. What's a better way to think of this in terms of LISP?
All these comments about how Lisp missed the boat, and you're all wrong. <i>We</i> missed the boat. Lisp has been going strong among it's own the whole time. It's not their fault we're all so stubborn, punishing ourselves over and over again like some sick masochists.<p>I got <i>mad</i> when I finally learned Lisp and realized how much time and effort has been wasted over the years because we're too lazy, ignorant, or foolish to use it.<p>(As a tangent, it's simply incredible how deliberately ignorant programmers can be. I've worked with guys getting paid to write software who didn't know who Alan Kay is, or had never heard of Prolog. What's worse is they're not ashamed of their ignorance. Can you imagine a physicist who had never heard of Newton?)<p>I don't use Lisp, but I have the grace to admit that that's a <i>personal failing</i>. (I joke that Python's only major problem is that it ruins you for other languages... I just can't quit that sweet syntax. Although Python 3 is a train wreck IMHO. Don't get me started.)<p>I <i>would</i> switch to Lisp, but I found something even better, which brings me to my actual, non-ranty, point:<p><i>There's a language even better than Lisp.</i><p>It's called Joy and it combines all the best parts of Lisp with the best parts of Forth to make an enormously simple system for describing software. It's a purely functional, stack-based, "concatinative" language that turns out to be good for "Categorical" programming: programs in Joy can be "instantiated" over different categories to generate different kinds of computations. I only have one good reference for "Categorical" programming right now: a paper and talk by Conal Elliott "Compiling to Categories" February 2017 <a href="http://conal.net/papers/compiling-to-categories/" rel="nofollow">http://conal.net/papers/compiling-to-categories/</a> He's working in Haskell, not Joy, but he's describing the idea: from one piece of code you can get calculations, dataflow diagrams, circuit descriptions, type signatures (inference), derivatives, etc., by implementations of the categories for each kind.
As elegant as lisp is, I think the flexibility just kills its usability on teams, while more rigid languages like Java, Go or C see massive adoption. Language expressiveness is rarely a real bottleneck, compared to debugging and understanding program flow and getting new contributors up to speed.<p>Separately I think each lisp has an individual fundamental flaw that makes it unusable for production, eg clojure having terrible error handling, common lisp being case insensitive, scheme having a minimal standard library, racket being fairly slow, etc.
The paper itself doesn't focus on Machine Learning / AI or anything too specific for that matter (it reads like a review / praise of LISPs), but I am currently researching Symbolic Artificial Intelligence as well as let's say the history of "Good Old-Fashioned Artificial Intelligence" and the role LISP took in all of that.<p>Any books / papers / articles that one should definitely read on these topics?
What are the pros and cons of Lisp (or any other language for that matter)?<p>In my undergraduate days (oh so many decades ago), I was introduced to Lisp. For some of the problems we were solving, it was the perfect tool. For others, a different language could be used.<p>The pros of Lisp (in all its varieties) are in many ways the cons of Lisp.<p>The macro system is both beneficial and antagonistic to the development of sane programs. Used judiciously, macros may life writing code much easier. However, it is not uncommon for Lisp programmers to write macros without consideration for those who come after them. This is, of course, true for any language.<p>There are some major systems out there that are written in Lisp and when trying to change them (in a maintenance way), it is just as painful as in pretty much any other language.<p>The competent and talented Lisp programmers is imbued with the same arrogance that C++ competent and talented programmers have. Tricky programming is fine if it is fully documented and the reasoning for the tricks is fully explained.<p>Lisp and its variations have much to offer the programming community. But the way programs are written quickly diminishes the effectiveness of the language for the larger community.<p>Each language has features that can be of use to each of us. they are tools we can use to solve the problems we are facing. No one language is suitable for all problems. If you have that attitude then you only see hammers and nails.
We have reached the point where saying "pick the right tool..." usually means completely opposite. PHP for web servers, python for large applications, go or anything c like for business logic
Lisp is part of the family of languages that J. Backus referred to as 'transformational languages'. Its ability to self-modify creates programs that are almost impossible for people other than the author to understand. This is why after 50 years it is still a niche language, and will remain so. There is little demand for programming languages that are hard to maintain. A working program lasts decades, and passes through many hands, and LISP is dead-end technology that will forever keep being brought up as its temptations are irresistible to some.
The guys that wrote this piece have drunk the kool aid of Lisp.<p>To say that library support for bioinformatics is on the early stages is quite a misunderstanding. Lisp was one if not the first language to be used in everything, including bioinformatics. If it is not used anymore is because people have abandoned it.<p>People have abandoned it once its flaws became evident. The main flaw of Lisp is using linear data for everything. It is obsolete, it was designed for linear memory like tapes or punched cards, not random access to memory like we have today.<p>Languages like Clojure has not this limitation but they have others, like forcing you to use the java virtual machine, good if optional, terrible if mandatory.<p>In current systems with huge amount of RAM, when you could have 128GBs on a developer system having to use a system that shoehorns everything to Lists is going backwards.<p>It also maximizes verbosity as everything uses the same thing, pattern differentiation is hard for actual humans to read and understand. This was a serious flaw that even Lisp creators quickly identified and tried to solve, remember Lisp was considered a temporary solution while the good solution was(never) found.<p>Not to talk about the absence of privileged instructions, everybody on the team changing whatever it wants, even basic instructions.<p>Don't get me wrong, I love Lisp, it is one of the more interesting languages in the world. I am actually working on porting some of the features it has(introspection) to other languages.<p>But from my point of view it is not that good for production for most projects. I have drunk the kool Aid myself before and have the scar tissue from that.