9 ms·
Building a community around lisp is tricky. While there are many criticisms to this article [1], there are some elements of the "Lisp Curse" which is true - eac
by hatmatrix 10y ago
Building a community around lisp is tricky. While there are many criticisms to this article [1], there are some elements of the "Lisp Curse" which is true - each programmer tends to rewrite his/her own libraries and so a collaborative framework seldom emerges even while many programmers may work in the same domain. This can be a disadvantage in a domain like the natural sciences where deep collaborations are necessary.
Furthermore, the disconnect with traditional mathematical syntax has also turned off many users. There was a predecessor to R called Lisp-Stat [2] which never achieved the acceptance that S/R did, and the Lisp-based syntax of Lisp-Stat was cited as one of the reasons.
Following the example of a high-profile Lisp supporter like Peter Norvig who accepted Python as a "Lispy" alternative early on, I think there are a lot of us who have come to accept Python as a necessary compromise. While Python is not homoiconic, functional programming is encouraged through its libraries rather than its core language definition, and the power of macros are missing, the inherent popularity and all the benefits that come with it is tough to beat.
[1] http://winestockwebdesign.com/Essays/Lisp_Curse.html http://winestockwebdesign.com/Essays/Lisp_Curse.html
[2] http://homepage.divms.uiowa.edu/~luke/xls/xlsinfo/xlsinfo.html http://homepage.divms.uiowa.edu/~luke/xls/xlsinfo/xlsinfo.ht...
- throwanem 10y ago> each programmer tends to rewrite his/her own libraries and so a collaborative framework seldom emerges even while many programmers may work in the same domain So, exactly like bioinformatics, then. Trivial tasks are supported by packages of libraries like BioPerl, but all the original research is sui generis, with the attitude in general being that each problem is unique and only results get published, so who cares if the code is a write-only mess as long as it does the one job after which no one will care about it anyway. In such an environment, the "Lisp Curse" already exists anyway, so why not get the benefit of a more powerful and expressive language when you're already paying its cost? (Granted, Lisp for bioinformatics is never going to become a generally accepted thing. But if you're not releasing code anyway, no one cares what language you write it in...)
- hatmatrix 10y agoWhat about Bioconductor and Openbabel/Pybel?
- throwanem 10y agoR and especially Python didn't see a lot of use where I was; the former was regarded mainly as a chart generator, while the latter had one diehard fan (an engineer like me, not an investigator) and no further uptake. It has been a few years since I was there, though, and I haven't kept closely in touch, so perhaps things have changed in the interim.
- GFK_of_xmaspast 10y ago> who cares if the code is a write-only mess as long as it does the one job after which no one will care about it anyway This is exactly the kind of attitude that projects like 'Software Carpentry' (https://software-carpentry.org https://software-carpentry.org) are pushing back against.
- torrent-of-ions 10y ago> and the Lisp-based syntax of Lisp-Stat was cited as one of the reasons. The syntax referred to is S-expressions. They are a simple and elegant way of writing trees. Lisp was originally supposed to have M-expressions which would be more like mathematical notation, but it was found that Lips users actually liked S-expressions. The reason becomes obvious after some amount of Lisp exposure. S-expressions are so simple that before long one does not even see them any more. The parentheses give way and one can just look straight at the Lisp code itself. For this reason many Lisp programmers do not even edit the S-expressions. They instead use something like paredit to edit the underlying tree directly. It's similar to how readers don't really "see" the letters that make up a word in many natural languages. And, further, they don't see the words that make up certain expressions. We have this fantastic ability to internalise language but so many are choosing not to use it when it comes to programming.
- cicero 10y agoUntil children are taught S-expressions in elementary school math, infix math notation will always be more familiar to the general population, and there will always be a learning barrier that must be overcome to gain similar skill with S-expressions, no matter how superior they might be.
- JaumeGreen 10y agoBut we are all using S-expressions without noticing. What do you say "Add 3 and 4" or "Take 3 and add 4"? That is the same with most things, we say the verb before the object(s).
- abrax3141 10y agoYes, that right. And moreover, much math isn't infix: Factorial is postfix. Sum, Product, and Integral are prefix. Infix is actually the exception, and is not semantically uniquely without parens anyway (languages have different orders of operation!), so folks should just get over the mindless prefix hate.
- 10y ago
- DonaldFisk 10y agoLisp-Stat (or XLispStat) didn't just use Lisp syntax, it was a Lisp. I've used XLispStat, S-PLUS (a commercial version or R), and SAS. SAS had the most comprehensive statistical libraries, but I never liked the language. I liked xlispstat but the statistical libraries weren't as good as those of SAS or S-PLUS. For data mining, I settled for S-PLUS, which was sufficiently lispy, and had a REPL. So it wasn't just the syntax (or lack of it). Beyond being dynamically typed and having a REPL, Python isn't particularly Lispy: it's less functional, and it has no (linked) lists or symbols. It's quicker to develop in than most of the non-Lisp alternatives, though.