> Just to put this paper in an appropriate historical context, I wrote it back when I was trying to convince NASA that flying Lisp on a spacecraft would not be a completely insane thing to do. The Powers That Be had already mostly accepted that it would be OK to fly Java, but they thought Lisp was too big and slow. This study and paper were designed specifically to address those concerns.
Thanks dang - i appreciate when you post these, particularly on perennial topics: it's interesting to look back and see how the crowd's wisdom has(n't) changed.
> the directions said to code as you would professionally, and that means I should comment my work.
Were this a "professional" component/service, in perhaps the majority of situations today, he'd probably separate his docs into two kinds of documentation: the committed interface/API what, and the internal maintenance how.
The docstring for `print-translations`, for example, conflate these two kinds.
Incidentally, by 2000, Java had emphasized reuse API documentation for a few years, with how it presented Javadoc for both the core Java API and layered development, from the start.
By contrast, Lisp environments that exposed docstrings in IDE hypertext, like Emacs did, did some doc things better than Java for decades before, and are still really well-suited to army-of-one genetically-enhanced supersoldier Lisp hackers.
Enterprise development, SaaSes, microservices, large systems with multiple teams, etc., were arguably better off heading in the more software engineering direction that Java was going.
(Which is not to say that Lisps can't do the what&how docs separation. I've done a few embedded API docs things for Scheme and Racket that initially were inspired by Javadoc, Perl, and some of the less-commonly-used embedded docs setups for other languages. And have worked on a couple large Lisp systems that arguably wouldn't have been possible in a language without some of the Lisp family's other still-unusual strengths, nor without the highly-skilled developers that Lisps seem to attract disproportionately.)
Hunchentoot attempts to do the "what&how docs separation", but when I last used it, I had to look at the implementation to understand what my code was expected to do. At least Emacs and SLIME made it easy to pull up the source code.
Lisp is a wonderful language (Common Lisp in particular, but I am dabbling in Scheme now too), and absolutely fantastic for web development - seriously people should give it a chance in that space, I would totally develop any SPA in Lisp[1].
QuickLisp is simply a joy to use, and the language is very portable with a fantastic specification and many top notch compilers.
IMO, what holds it back is a lack of a top notch IDE. It took me a year of love & hate with Emacs, I can now make pretty good use of the amazing software that is Emacs (where everything can be changed), but honestly at times I want a simple point & click free IDE which is polished and does most things well and out of the box. Portacle is a step in the right direction, but the Emacs dependency IMO does make the language a bit more niche and lose out to other languages for beginners. If some big corporation can mix sublime with slime with paredit with some of the customize ability of Emacs, then Common Lisp could explode in popularity.
Don’t get me wrong - I LOVE Emacs and everything about Emacs & CL combined, but it took me a year to get to this point.
The emacs bias is even part of Lisp advocates mental models, so it's no surprise that a lot of would-be Lispers give up at the thought of having to use it. But there are alternatives, and it might be fruitful for advocates to routinely point them out. vim (my preference) has two slime plugins that work really well, Atom has https://atom.io/packages/slima and as you point out there's lots of Emacs-variants. There's also lem and Second-Climacs might one day be good. And of course there's the two proprietary IDEs with LispWorks and Allegro that both provide trial versions to see if you like them before shelling out money.
Apart from editors, more editor-independent tools would be nice. McCLIM's Clouseau is a pretty cool graphical inspector/variable watcher.
IMO what holds it back is lack of a big company using and promoting it along with tooling (which might be in the form of alternate IDEs or good plugins for popular editors like VS Code or IntelliJ). Clojure has shown what's possible without such, most use emacs but there are popular alternatives too, and for a time it was even as popular as Go, but Go has BigCo backing, and we can see how much further that brought it despite its many shortcomings.
BTW, there's a small small-world coincidence, between a desire for an Emacs-based super IDE, and the original article...
The desire for an Emacs-based out-of-box power-user IDE was how we got Lucid Emacs, aka XEmacs (which was one of the two big forks of GNU Emacs with GUI innovations that GNU took a while to catch up with)...
...from JWZ, et al.'s work on the Lucid Energize IDE for C++...
...and JWZ worked for Norvig early on...
...and Norvig was at Harlequin...
...and Harlequin acquired at least some of Lucid's IP.
> IMO, what holds it back is a lack of a top notch IDE
I hear good things about Lispworks[1][2], but personally I'm put off by non-free development tools. Especially ones with a 3-4 digit price tag. However, their business model evidently works for them.
He wrote this around the same time that he kindly reviewed and gave me comments on the first edition of my Java AI book. A year later we had lunch: I was using Common Lisp and Java for my work and I think that Peter was mostly using Python by then.
Which programming language you choose really doesn't matter very much. Since 1982 Common Lisp has been my favorite language, but I have recently learned to also love Swift.
The year after he wrote this, Norvig joined Google and decided that Python was a good enough alternative. He posted a web page about it, but I can't find it rn. However, here's a comment of his on HN about it:
The philosophy of Lisp encourages writing your own libraries because it's so easy to do. You're expected to know how to program if you use Lisp; not to depend on tiny prewritten functions in the npm universe that may or may not solve your problem, that may or may not be written in a secure or efficient fashion, and that possibly pull in a million transitive dependencies you don't need.
That said, Common Lisp itself includes many of the more useful but difficult-to-write features like hash tables, sort/merge, bignums, complex numbers, etc.
The most-used stuff that's not in Common Lisp itself like multithreading and sockets are well-covered by external libraries. The lesser-needed stuff is also quite well covered by the quicklisp library infrastructure [0] as well.
So the statement "libraries...do not exist in the Lisp ecosystem" is plainly false and it marks the speaker as someone not very familiar with Lisp.
So true, but this class of comment always amuses me as in the 1980s one of the (many) criticisms leveled at Common Lisp was that its library support was too big.
Lisp isn't very popular because, at least in my opinion, it requires a relatively high level of maturity and experience to be used effectively on nontrivial projects.
Every single project in Lisp (Common Lisp, Clojure) that I have observed ended in a disaster mostly because developers could not figure out what the strengths of Lisp are to realize the benefits and then killed themselves with too much freedom.
Absent large enough number of success stories companies will default on Java because it is good enough language to be able to effectively realize typical enterprise application and dumb enough to be used by a beginner dev, even at the cost of boilerplate.
At least that's the official story. It is really difficult to explain to business that you could do whatever they want with 1/5th or 1/50th of the amount of code if you just used a good language for it.
There was an article in the 2000s from a dude looking at a graph library, java had 3 major players, non of them did what he needed (generics issues or similar). He ended up rolling his own.
I think the whole issue of having a great programming language is a mute point in the current software industry, because average programmers don't know how to use it. That's why the winners have always be languages that appeal to the minimum common denominator, just the bare enough for people to write programers in the simple way they know. Lisp provide a lot of flexibility and power, but if programmers don't know how to use it, it is instead viewed as a liability.
Tiny niggle about a well-known phrase and a word that is not particularly well-known outside of the phrase anymore: the word is moot. (A moot used to be a meeting or assembly of people who would discuss and decide things, often Very Important Things™. Nowadays, moot is mostly an adjective referring to things that might be debatable, but the only benefit to debating them would be the debate itself.)
Where did this crazy list come from? Has the guy never looked at an actual telephone?
The following mapping from letters to digits is given:
E | J N Q | R W X | D S Y | F T | A M | C I V | B K U | L O P | G H Z
e | j n q | r w x | d s y | f t | a m | c i v | b k u | l o p | g h z
0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8
|9
We want to use this mapping for encoding telephone numbers by words, so
that it becomes easier to remember the numbers.
[+] [-] dang|4 years ago|reply
Lisp as an alternative to Java (2000) - https://news.ycombinator.com/item?id=26720403 - April 2021 (94 comments)
Lisp as an Alternative to Java – Faster, More Productive - https://news.ycombinator.com/item?id=21899854 - Dec 2019 (1 comment)
Lisp as an Alternative to Java (1999) - https://news.ycombinator.com/item?id=12197131 - July 2016 (103 comments)
Lisp as an Alternative to Java (2000) [pdf] - https://news.ycombinator.com/item?id=9045574 - Feb 2015 (21 comments)
Lisp as an alternative to Java (2000) [pdf] - https://news.ycombinator.com/item?id=8446368 - Oct 2014 (55 comments)
Lisp as an Alternative to Java - https://news.ycombinator.com/item?id=3447101 - Jan 2012 (37 comments)
Lisp as an Alternative to Java [PDF] - https://news.ycombinator.com/item?id=61320 - Sept 2007 (9 comments)
[+] [-] felideon|4 years ago|reply
> Just to put this paper in an appropriate historical context, I wrote it back when I was trying to convince NASA that flying Lisp on a spacecraft would not be a completely insane thing to do. The Powers That Be had already mostly accepted that it would be OK to fly Java, but they thought Lisp was too big and slow. This study and paper were designed specifically to address those concerns.
https://news.ycombinator.com/item?id=8446685
[+] [-] sophacles|4 years ago|reply
[+] [-] neilv|4 years ago|reply
Were this a "professional" component/service, in perhaps the majority of situations today, he'd probably separate his docs into two kinds of documentation: the committed interface/API what, and the internal maintenance how.
The docstring for `print-translations`, for example, conflate these two kinds.
Incidentally, by 2000, Java had emphasized reuse API documentation for a few years, with how it presented Javadoc for both the core Java API and layered development, from the start.
By contrast, Lisp environments that exposed docstrings in IDE hypertext, like Emacs did, did some doc things better than Java for decades before, and are still really well-suited to army-of-one genetically-enhanced supersoldier Lisp hackers.
Enterprise development, SaaSes, microservices, large systems with multiple teams, etc., were arguably better off heading in the more software engineering direction that Java was going.
(Which is not to say that Lisps can't do the what&how docs separation. I've done a few embedded API docs things for Scheme and Racket that initially were inspired by Javadoc, Perl, and some of the less-commonly-used embedded docs setups for other languages. And have worked on a couple large Lisp systems that arguably wouldn't have been possible in a language without some of the Lisp family's other still-unusual strengths, nor without the highly-skilled developers that Lisps seem to attract disproportionately.)
[+] [-] oalae5niMiel7qu|4 years ago|reply
[+] [-] abhinav22|4 years ago|reply
QuickLisp is simply a joy to use, and the language is very portable with a fantastic specification and many top notch compilers.
IMO, what holds it back is a lack of a top notch IDE. It took me a year of love & hate with Emacs, I can now make pretty good use of the amazing software that is Emacs (where everything can be changed), but honestly at times I want a simple point & click free IDE which is polished and does most things well and out of the box. Portacle is a step in the right direction, but the Emacs dependency IMO does make the language a bit more niche and lose out to other languages for beginners. If some big corporation can mix sublime with slime with paredit with some of the customize ability of Emacs, then Common Lisp could explode in popularity.
Don’t get me wrong - I LOVE Emacs and everything about Emacs & CL combined, but it took me a year to get to this point.
[1] For those interested, I wrote this article covering the basics: https://ashok-khanna.medium.com/lisp-the-web-4c00c88d11f9
[+] [-] Jach|4 years ago|reply
Apart from editors, more editor-independent tools would be nice. McCLIM's Clouseau is a pretty cool graphical inspector/variable watcher.
IMO what holds it back is lack of a big company using and promoting it along with tooling (which might be in the form of alternate IDEs or good plugins for popular editors like VS Code or IntelliJ). Clojure has shown what's possible without such, most use emacs but there are popular alternatives too, and for a time it was even as popular as Go, but Go has BigCo backing, and we can see how much further that brought it despite its many shortcomings.
[+] [-] neilv|4 years ago|reply
The desire for an Emacs-based out-of-box power-user IDE was how we got Lucid Emacs, aka XEmacs (which was one of the two big forks of GNU Emacs with GUI innovations that GNU took a while to catch up with)...
...from JWZ, et al.'s work on the Lucid Energize IDE for C++...
...and JWZ worked for Norvig early on...
...and Norvig was at Harlequin...
...and Harlequin acquired at least some of Lucid's IP.
[+] [-] User23|4 years ago|reply
I hear good things about Lispworks[1][2], but personally I'm put off by non-free development tools. Especially ones with a 3-4 digit price tag. However, their business model evidently works for them.
[1] http://www.lispworks.com/products/lispworks.html
[2] https://lisp-journey.gitlab.io/blog/discovering-the-lispwork...
[+] [-] vindarel|4 years ago|reply
[+] [-] mark_l_watson|4 years ago|reply
Which programming language you choose really doesn't matter very much. Since 1982 Common Lisp has been my favorite language, but I have recently learned to also love Swift.
[+] [-] eric4smith|4 years ago|reply
All the libraries - both open source and commercial that do a million things - do not exist in the Lisp ecosystem.
Even in 2000
[+] [-] antonvs|4 years ago|reply
https://news.ycombinator.com/item?id=1803815
[+] [-] dimitar|4 years ago|reply
[+] [-] eatonphil|4 years ago|reply
https://abcl.org/trac/
[+] [-] lisper|4 years ago|reply
[+] [-] dreamcompiler|4 years ago|reply
That said, Common Lisp itself includes many of the more useful but difficult-to-write features like hash tables, sort/merge, bignums, complex numbers, etc.
The most-used stuff that's not in Common Lisp itself like multithreading and sockets are well-covered by external libraries. The lesser-needed stuff is also quite well covered by the quicklisp library infrastructure [0] as well.
So the statement "libraries...do not exist in the Lisp ecosystem" is plainly false and it marks the speaker as someone not very familiar with Lisp.
[0] https://www.quicklisp.org/beta/releases.html
[+] [-] gumby|4 years ago|reply
[+] [-] lmilcin|4 years ago|reply
Lisp isn't very popular because, at least in my opinion, it requires a relatively high level of maturity and experience to be used effectively on nontrivial projects.
Every single project in Lisp (Common Lisp, Clojure) that I have observed ended in a disaster mostly because developers could not figure out what the strengths of Lisp are to realize the benefits and then killed themselves with too much freedom.
Absent large enough number of success stories companies will default on Java because it is good enough language to be able to effectively realize typical enterprise application and dumb enough to be used by a beginner dev, even at the cost of boilerplate.
At least that's the official story. It is really difficult to explain to business that you could do whatever they want with 1/5th or 1/50th of the amount of code if you just used a good language for it.
[+] [-] agumonkey|4 years ago|reply
Things are not so simple
[+] [-] vindarel|4 years ago|reply
[+] [-] coliveira|4 years ago|reply
[+] [-] stan_rogers|4 years ago|reply
[+] [-] brundolf|4 years ago|reply
[+] [-] vindarel|4 years ago|reply
[1] talking about speed
[+] [-] 37ef_ced3|4 years ago|reply
"Go as an Alternative to C"
[+] [-] dfboyd|4 years ago|reply