Lisp as an Alternative to Java (2000)(norvig.com)
norvig.com
Lisp as an Alternative to Java (2000)
http://www.norvig.com/java-lisp.html
107 comments
From the 2014 incarnation:
> 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
> 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
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.
[deleted]
> 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.)
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.
[1] For those interested, I wrote this article covering the basics: https://ashok-khanna.medium.com/lisp-the-web-4c00c88d11f9
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
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.
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.
Do any non-emacses have anything like paredit?
Slimv comes with a Paredit Mode: https://github.com/kovisoft/slimv Personally I leave it off, though, never been a fan of anything trying to 'help' me automatically while I'm typing apart from indentation. I do appreciate vim-sexp occasionally with these mappings: https://github.com/tpope/vim-sexp-mappings-for-regular-peopl...
https://susam.in/blog/lisp-in-vim-with-slimv-or-vlime/ is a good overview of the differences between slimv and vlime (the two vim plugins) and how to use them.
https://susam.in/blog/lisp-in-vim-with-slimv-or-vlime/ is a good overview of the differences between slimv and vlime (the two vim plugins) and how to use them.
You write lisp without auto-inserting the closing paren when you open a paren? I honestly don't think that's a good idea. It's also something that's contributed to lack of lisp adoption -- people trying to write it without sensible editor support.
Yup, as I type ( and { and [ and " and manually close them in every other language and inevitably turn that stuff off if the IDE has it enabled. vim default has enough support -- when I type ) et al., it highlights the matching opening. Typing '%' in command mode jumps to the corresponding open/close bracket. Occasionally if I know I'm done with a function, and have a bunch of closing parens to insert, I'll use slimv's ctrl+x+0 to close them all for me. I'm a fan of rainbow parens which makes things nicer to look at too, but really, this Lisp meme becomes true after not very long: https://www.thejach.com/imgs/lisp_parens.png Or at least one tunes them out, just like one does with the syntactic noise in other languages. Editing them is natural.
Speaking of noise, here's some out of context JS code from the first random file I opened in a really old project:
For Lisp, "sensible editor support" to me means something like slime support that enables REPL development. Lacking that in editors besides emacs (or not knowing about the support for alternate editors) has probably hurt adoption, sure, but I don't think the presence or absence of other editing tools that most every editor has (like keyword highlighting and other colors, auto-indentation, auto-completion, auto-bracket insert, intelli-sense stuff...) is a factor.
Speaking of noise, here's some out of context JS code from the first random file I opened in a really old project:
}
});
}
).on('error', function(e) { console.log('Error: ' + e); response.json({error: 'data_fetch_error'}, {}, 400); }).end();
}).then(function(next, urlstr) {
For Lisp, "sensible editor support" to me means something like slime support that enables REPL development. Lacking that in editors besides emacs (or not knowing about the support for alternate editors) has probably hurt adoption, sure, but I don't think the presence or absence of other editing tools that most every editor has (like keyword highlighting and other colors, auto-indentation, auto-completion, auto-bracket insert, intelli-sense stuff...) is a factor.
This is what is holding me back from the other IDEs for Emacs. Also slime is great
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.
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.
XEmacs was the only thing that made lack of IDE culture on UNIX tolerable to me back in the 1990's.
> 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.
[1] http://www.lispworks.com/products/lispworks.html
[2] https://lisp-journey.gitlab.io/blog/discovering-the-lispwork...
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...
As mentioned, SLIMA for Atom is pretty good, nearly as good as Slime. More options: https://lispcookbook.github.io/cl-cookbook/editor-support.ht... (VSCode, Jupyter notebooks, a simple Eclipse plugin, an overview of LispWorks etc)
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.
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.
No way. The ecosystem is just not there.
All the libraries - both open source and commercial that do a million things - do not exist in the Lisp ecosystem.
Even in 2000
All the libraries - both open source and commercial that do a million things - do not exist in the Lisp ecosystem.
Even in 2000
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:
https://news.ycombinator.com/item?id=1803815
https://news.ycombinator.com/item?id=1803815
https://norvig.com/python-lisp.html
This essay starts with the context of his choosing Python to express what was formerly pseudocode.
This essay starts with the context of his choosing Python to express what was formerly pseudocode.
Also see this, in the same topic but not in the same thread:
https://news.ycombinator.com/item?id=1803627
https://news.ycombinator.com/item?id=1803627
but Python doesn't resemble Lisp at all: https://lisp-journey.gitlab.io/pythonvslisp/ (overview of the workflows and ecosystems)
Now you have Clojure which runs on the JVM and interops nicely
And ClojureScript to interop with JS ecosystem.
ABCL and Kawa have that advantage as well, without the strange "Lisp is nice, but..." design philosophy of Clojure.
I wouldn't call it "nicely", there is lot of stuff that makes it really tedious.
The bigger issue though is wasting time wrapping Java libraries and most comments I see about Clojure interop talk as if there is no cost to it.
Clojure has good foundations but the ecosystem never really developed.
The bigger issue though is wasting time wrapping Java libraries and most comments I see about Clojure interop talk as if there is no cost to it.
Clojure has good foundations but the ecosystem never really developed.
> The bigger issue though is wasting time wrapping Java libraries and most comments I see about Clojure interop talk as if there is no cost to it.
You are not forced to "waste time" wrapping Java libraries. As a matter of fact, thanks to the interop features that are well thought out, using Java libraries directly via the interop is encouraged and preferred to wrappers (Java Time API is a good example.) You may _choose_ to write wrappers for Java libraries if they make consuming these libraries in your code a bit nicer.
> Clojure has good foundations but the ecosystem never really developed.
There's no separate ecosystem for Clojure(Script). The established ecosystems such as JVM, .NET, and JavaScript _are_ the Clojure ecosystem. The creator of Clojure(Script) realized that it would be practically impossible to build an ecosystem from scratch without significant investment (Sun spent billions of marketing dollars alone in Java) and thus deliberately chose to make Clojure(Script) a language hosted on well-developed platforms such as JVM, .NET, and JavaScript. Also because of this focus on being a hosted language, he went to great lengths to ensure the interop with its hosting platforms is as seamless as possible. If you need an example for awkward interop with Java, try Scala.
You are not forced to "waste time" wrapping Java libraries. As a matter of fact, thanks to the interop features that are well thought out, using Java libraries directly via the interop is encouraged and preferred to wrappers (Java Time API is a good example.) You may _choose_ to write wrappers for Java libraries if they make consuming these libraries in your code a bit nicer.
> Clojure has good foundations but the ecosystem never really developed.
There's no separate ecosystem for Clojure(Script). The established ecosystems such as JVM, .NET, and JavaScript _are_ the Clojure ecosystem. The creator of Clojure(Script) realized that it would be practically impossible to build an ecosystem from scratch without significant investment (Sun spent billions of marketing dollars alone in Java) and thus deliberately chose to make Clojure(Script) a language hosted on well-developed platforms such as JVM, .NET, and JavaScript. Also because of this focus on being a hosted language, he went to great lengths to ensure the interop with its hosting platforms is as seamless as possible. If you need an example for awkward interop with Java, try Scala.
You are not forced by the language to wrap libraries. In fact "Programming Clojure" by some of the authors says the following:
"Clojure embraces java and its libraries. Idiomatic Clojure code calls Java libraries directly and doesn't try to wrap everything under the sun to look like Lisp. This surprises make new Clojure developers but is very pragmatic. Where Java isn't broken, Clojure doesn't fix it"
So the ecosystem is a superset of the Java and JS ecosystems, which are pretty developed.
I do agree that the cost of required to know 2 or 3 languages is real though.
"Clojure embraces java and its libraries. Idiomatic Clojure code calls Java libraries directly and doesn't try to wrap everything under the sun to look like Lisp. This surprises make new Clojure developers but is very pragmatic. Where Java isn't broken, Clojure doesn't fix it"
So the ecosystem is a superset of the Java and JS ecosystems, which are pretty developed.
I do agree that the cost of required to know 2 or 3 languages is real though.
Thank you for articulating my (limited) experience. It was a very leaky abstraction. I remember thinking "If this is it, Python wins."
Armed Bear Common Lisp (Common Lisp on the JVM) may be the most obvious choice if you prioritize ecosystem above all else (which isn't a bad thing).
https://abcl.org/trac/
https://abcl.org/trac/
Actually they pretty much do, much more so now than in 2000. QuickLisp has been a real game-changer.
How many of those 1500 QuickLisp libraries work together without extra work?
I seriously tried to use Common Lisp for numerical programming 10 years ago. It was faster and would have been better platform for numerical programming than Python, R or Julia. Just a great language. (Ross Ihaka had plans to port R into Common Lisp to make R fast at one point)
The real problem was the lack of convergence of data structures and conventions above the language standard.
Python has pandas tables and numpy arrays. R has Data frame. Every numerical library for CL had their own conventions, and ways to implement the basic data structure, Some used lists, some just arrays, some had list of vectors, classes, structs, property lists.
The impedance mismatch was not worth it. Either implement numpy equivalent on your own or half of your code is data massaging data between libraries.
--
Perlis epigram: "9. It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures."
I seriously tried to use Common Lisp for numerical programming 10 years ago. It was faster and would have been better platform for numerical programming than Python, R or Julia. Just a great language. (Ross Ihaka had plans to port R into Common Lisp to make R fast at one point)
The real problem was the lack of convergence of data structures and conventions above the language standard.
Python has pandas tables and numpy arrays. R has Data frame. Every numerical library for CL had their own conventions, and ways to implement the basic data structure, Some used lists, some just arrays, some had list of vectors, classes, structs, property lists.
The impedance mismatch was not worth it. Either implement numpy equivalent on your own or half of your code is data massaging data between libraries.
--
Perlis epigram: "9. It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures."
> How many of those 1500 QuickLisp libraries work together without extra work?
I'm not sure what kind of question is that. A whole bunch of them? Certainly not worse ratio than many contemporary or even modern languages. There's a lot less friction to get any random GitHub CL project working than say a Swift one.
I'm not sure what kind of question is that. A whole bunch of them? Certainly not worse ratio than many contemporary or even modern languages. There's a lot less friction to get any random GitHub CL project working than say a Swift one.
> Certainly not worse ratio than many contemporary or even modern languages
CL has no standardized extensible abstraction classes for basic collection types. Almost all languages have that because it's so essential for communicating between libraries. I'm relatively sure Swift has one Only other language similar to CL in this regard is C.
And you can't ask if what you have is mapping of symbol number pairs. CL has multiple libraries that fix this problem but no significant convergence has emerged.
For simple key value pairs or maps you must keep track and convert between
CL has no standardized extensible abstraction classes for basic collection types. Almost all languages have that because it's so essential for communicating between libraries. I'm relatively sure Swift has one Only other language similar to CL in this regard is C.
And you can't ask if what you have is mapping of symbol number pairs. CL has multiple libraries that fix this problem but no significant convergence has emerged.
For simple key value pairs or maps you must keep track and convert between
;; property list (implicit type)
(type-of '(foo 1 bar 2 baz 3)) => CONS
;; assoc-list (implicit type)
(type-of '((foo . 1) (bar . 2) (baz . 3))) => CONS
;; list of lists (implicit type)
(type-of '((foo 1) (bar 2) (baz 3))) => CONS
;; hash-table (explicit only about being hash table)
(type-of #<HASH-TABLE :TEST EQL :COUNT 3 {10018A8023}>) => HASH-TABLE)>Either implement numpy equivalent on your own or half of your code is data massaging data between libraries
I haven't tested this but here you go:
https://github.com/numcl/numcl
I haven't tested this but here you go:
https://github.com/numcl/numcl
> How many of those 1500 QuickLisp libraries work together without extra work?
I'm pretty sure that due to the curated nature of code in QuickLisp, there's really no problem with that. If something doesn't load properly, it's a bug that you should report.
I'm pretty sure that due to the curated nature of code in QuickLisp, there's really no problem with that. If something doesn't load properly, it's a bug that you should report.
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.
[0] https://www.quicklisp.org/beta/releases.html
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
> The philosophy of Lisp encourages writing your own libraries because it's so easy to do.
Having professionally worked in CL and Java, this is true and completely misses the point. Of course you can write your own libraries, the question isn’t whether you can but whether or not that’s a wise usage of your time and energy. Java gives me a ton of fantastic libraries out of the box that let me focus on my domain, which is a good thing!
> 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.
Sneering at people who use different languages is both a bad look, and a bad way to convince people that you’re right. I’d recommend staying way clear of any suggestion that your peers don’t know how to program.
> 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.
This is a pretty drastic understatement of how far behind Java CL is. Forget multithreading, think more about metrics, logs, configuration, A/B testing, retries/bulkheads/circuit-breakers, feature flags, and secrets management. All of this stuff I get for free out of Java libraries, often in automatically self configuring ways.
Configuring a Kafka reader in my app and seeing that it automatically discovered Micrometer on my class path and started emitting metrics is a lovely experience. Switching metrics servers from InfluxDB to Datadog with a single code change was damn near nirvana.
If CL wants to be a compelling alternative to Java for industrial use, it’s got to catch up on all this stuff.
Having professionally worked in CL and Java, this is true and completely misses the point. Of course you can write your own libraries, the question isn’t whether you can but whether or not that’s a wise usage of your time and energy. Java gives me a ton of fantastic libraries out of the box that let me focus on my domain, which is a good thing!
> 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.
Sneering at people who use different languages is both a bad look, and a bad way to convince people that you’re right. I’d recommend staying way clear of any suggestion that your peers don’t know how to program.
> 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.
This is a pretty drastic understatement of how far behind Java CL is. Forget multithreading, think more about metrics, logs, configuration, A/B testing, retries/bulkheads/circuit-breakers, feature flags, and secrets management. All of this stuff I get for free out of Java libraries, often in automatically self configuring ways.
Configuring a Kafka reader in my app and seeing that it automatically discovered Micrometer on my class path and started emitting metrics is a lovely experience. Switching metrics servers from InfluxDB to Datadog with a single code change was damn near nirvana.
If CL wants to be a compelling alternative to Java for industrial use, it’s got to catch up on all this stuff.
> Of course you can write your own libraries, the question isn’t whether you can but whether or not that’s a wise usage of your time and energy. Java gives me a ton of fantastic libraries out of the box that let me focus on my domain, which is a good thing!
This was a bug in the Common Lisp community in the early 2000s when I was getting started with it and looking to the community for help identifying libraries for common functionality. People were friendly and helpful, but they gently pushed me to accept that reaching for libraries was a habit I was bringing from other languages, and in Lisp I could (and should) write my own implementations for things like logging and date formatting. Sharing code was for big hard stuff, not easy stuff.
Since then, it seems like a number of people have put a lot of work into moving the community forward from that romantic approach to a more pragmatic one, but if I wanted to use Lisp now, I would scrutinize that aspect of Common Lisp very closely before getting back into it. I would lean heavily towards Clojure instead.
This was a bug in the Common Lisp community in the early 2000s when I was getting started with it and looking to the community for help identifying libraries for common functionality. People were friendly and helpful, but they gently pushed me to accept that reaching for libraries was a habit I was bringing from other languages, and in Lisp I could (and should) write my own implementations for things like logging and date formatting. Sharing code was for big hard stuff, not easy stuff.
Since then, it seems like a number of people have put a lot of work into moving the community forward from that romantic approach to a more pragmatic one, but if I wanted to use Lisp now, I would scrutinize that aspect of Common Lisp very closely before getting back into it. I would lean heavily towards Clojure instead.
> I could (and should) write my own implementations for things like logging and date formatting.
One of my biggest pet peeves when working with Go, is the multitude of logging libraries with disparate interfaces. That can't be configured easily (if at all) or at a desired level of granularity by the end user.
One of the things the Java community got right is SLF4J for a standard interface.
One of my biggest pet peeves when working with Go, is the multitude of logging libraries with disparate interfaces. That can't be configured easily (if at all) or at a desired level of granularity by the end user.
One of the things the Java community got right is SLF4J for a standard interface.
The Java community is going further in this direction, with the norm being empty jars to provide interfaces for libraries, with the implementation being brought by the application. Micrometer, opentracing, and Jax work this way.
I tried to install I-don't-remember-what Java app years ago. The logging didn't work at all. The docs went on and on about how it used this standard, pluggable logging interface and you can plug any logging implementation into it, but as for how to get it to actually log something somewhere (hopefully to syslog, but that's doubtful), nobody seemed interested in that. I rm -rf'd the app and never allowed anything written in Java into the project again.
> Sharing code was for big hard stuff, not easy stuff.
This is exactly where I'm coming from. Maybe it is romantic, but I also find it pragmatic when I write code in Common Lisp.
This is exactly where I'm coming from. Maybe it is romantic, but I also find it pragmatic when I write code in Common Lisp.
> Sneering at people who use different languages is both a bad look, and a bad way to convince people that you’re right.
I'm pretty sure that this was a criticism of NPM rather than of any language.
> Forget multithreading, think more about metrics, logs, configuration, A/B testing, retries/bulkheads/circuit-breakers, feature flags, and secrets management.
I could understand logs and secrets management (if it's what I think you mean by that), but how do the other things relate to the language? Except for retries which I would have thought were much better integrated into CL then they could be in Java, given resumable conditions.
> Configuring a Kafka reader in my app and seeing that it automatically discovered Micrometer on my class path and started emitting metrics is a lovely experience.
Is this a thing that something like asdf-system-connections would solve in Lisp? (IMO also much more elegantly than by "discovering X on my class path".)
I'm pretty sure that this was a criticism of NPM rather than of any language.
> Forget multithreading, think more about metrics, logs, configuration, A/B testing, retries/bulkheads/circuit-breakers, feature flags, and secrets management.
I could understand logs and secrets management (if it's what I think you mean by that), but how do the other things relate to the language? Except for retries which I would have thought were much better integrated into CL then they could be in Java, given resumable conditions.
> Configuring a Kafka reader in my app and seeing that it automatically discovered Micrometer on my class path and started emitting metrics is a lovely experience.
Is this a thing that something like asdf-system-connections would solve in Lisp? (IMO also much more elegantly than by "discovering X on my class path".)
> I'm pretty sure that this was a criticism of NPM rather than of any language.
> You’re expected to know how to program if you use lisp.
Why would they say this if they weren’t implying that NPM users can’t program?
> I could understand logs and secrets management (if it's what I think you mean by that), but how do the other things relate to the language?
They don’t, not directly. But it’s the community for that language that makes and supports these things, and comparisons between these communities (and the libraries they share) is a fair area of analysis.
> Except for retries which I would have thought were much better integrated into CL then they could be in Java, given resumable conditions.
They could, but they have not to my knowledge. In my opinion the language’s capability is far less important than a community that values creating and maintaining these libraries.
(I also think functional programming aficionados drastically underrate how much Java has changed. There are still issues I personally whine about, but they’ve fixed a lot of warts since the 1.6 days)
Retries in particular are one of those things that seem obviously standalone, but are not. Having my retries automatically expose micrometer counters has been a godsend for monitoring. I’d like to see them automatically expose opentracing information too, which is an obvious area of opportunity for r4j.
> Is this a thing that something like asdf-system-connections would solve in Lisp?
The technical ability to make libraries auto-configure together is meaningless if the community doesn’t have the will to take regular advantage of it.
Frankly, Java the language is incredibly weak for this kind of stuff, yet the Java community is busy doing it anyways. I’ll remain unimpressed by interoperability improvements to CL so long as the culture of “roll your own libraries!” remains in place.
> You’re expected to know how to program if you use lisp.
Why would they say this if they weren’t implying that NPM users can’t program?
> I could understand logs and secrets management (if it's what I think you mean by that), but how do the other things relate to the language?
They don’t, not directly. But it’s the community for that language that makes and supports these things, and comparisons between these communities (and the libraries they share) is a fair area of analysis.
> Except for retries which I would have thought were much better integrated into CL then they could be in Java, given resumable conditions.
They could, but they have not to my knowledge. In my opinion the language’s capability is far less important than a community that values creating and maintaining these libraries.
(I also think functional programming aficionados drastically underrate how much Java has changed. There are still issues I personally whine about, but they’ve fixed a lot of warts since the 1.6 days)
Retries in particular are one of those things that seem obviously standalone, but are not. Having my retries automatically expose micrometer counters has been a godsend for monitoring. I’d like to see them automatically expose opentracing information too, which is an obvious area of opportunity for r4j.
> Is this a thing that something like asdf-system-connections would solve in Lisp?
The technical ability to make libraries auto-configure together is meaningless if the community doesn’t have the will to take regular advantage of it.
Frankly, Java the language is incredibly weak for this kind of stuff, yet the Java community is busy doing it anyways. I’ll remain unimpressed by interoperability improvements to CL so long as the culture of “roll your own libraries!” remains in place.
> Why would they say this if they weren’t implying that NPM users can’t program?
I'm pretty sure that numerous Quicklisp users can't program either, but Quicklisp is manually curated while NPM (AFAIK?) isn't so their code won't end up in Quicklisp.
> You tell me.
I'm not sure what there is to say. The ASDF extension in question allows you to write systems that get loaded when a specific combination of other systems gets loaded, so when there's some room for collaboration of multiple systems, all such code naturally belongs into that autoloaded system. It can assume the presence of all required systems and hook them up together. Is this something like what you're describing? Except for the "discovered Micrometer on my class path" part of course since you're not concerning yourself with any paths here (that feels a bit brittle to me) but the notion of doing something special when combining specific multiple libraries is supported on system loading level.
I'm pretty sure that numerous Quicklisp users can't program either, but Quicklisp is manually curated while NPM (AFAIK?) isn't so their code won't end up in Quicklisp.
> You tell me.
I'm not sure what there is to say. The ASDF extension in question allows you to write systems that get loaded when a specific combination of other systems gets loaded, so when there's some room for collaboration of multiple systems, all such code naturally belongs into that autoloaded system. It can assume the presence of all required systems and hook them up together. Is this something like what you're describing? Except for the "discovered Micrometer on my class path" part of course since you're not concerning yourself with any paths here (that feels a bit brittle to me) but the notion of doing something special when combining specific multiple libraries is supported on system loading level.
> I'm pretty sure that numerous Quicklisp users can't program either, but Quicklisp is manually curated while NPM (AFAIK?) isn't so their code won't end up in Quicklisp.
This interpretation of GP’s comments strains credulity.
As for the rest, I edited and expanded my unnecessarily glib response. The technical ability you mentioned is nice, but I will remain unimpressed until it sees wider use. This is a shortcoming in the CL community, not a shortcoming in the CL language.
I’ll change my opinion once I see evidence of the CL community coming together to value shared, reusable code to accomplish common tasks.
This interpretation of GP’s comments strains credulity.
As for the rest, I edited and expanded my unnecessarily glib response. The technical ability you mentioned is nice, but I will remain unimpressed until it sees wider use. This is a shortcoming in the CL community, not a shortcoming in the CL language.
I’ll change my opinion once I see evidence of the CL community coming together to value shared, reusable code to accomplish common tasks.
I guess I'm just a very credulous person, then.
Regarding asdf-system-connections, it would probably help if this were core functionality of ASDF. I don't get why it isn't yet, since it perfectly fits Lisp's overarching concept of independently defined things cooperating (cf. classes and generic functions, or multimethods). I might want to ask some people about that.
Regarding asdf-system-connections, it would probably help if this were core functionality of ASDF. I don't get why it isn't yet, since it perfectly fits Lisp's overarching concept of independently defined things cooperating (cf. classes and generic functions, or multimethods). I might want to ask some people about that.
It might, but I doubt it will. “Roll your own libraries” is so core to the CL community’s self identity, that I doubt it will ever change within my lifetime.
Honestly, if you want a modern Lisp experience, I’d recommend Clojure. Clojure doesn’t philosophically align with my own preferences, but that community is very active and very invested in solving common problems as a community.
Honestly, if you want a modern Lisp experience, I’d recommend Clojure. Clojure doesn’t philosophically align with my own preferences, but that community is very active and very invested in solving common problems as a community.
I find Clojure awful both conceptually and implementation-wise (the imposition of lowest common denominators by JVM dependency really sucks here, starting with lack of tail calls, but not ending there), so that's most likely not going to happen. I don't see why the good things in Clojure should be impossible to achieve in CL as libraries. You might argue that CL community should be working on those, and you'd be completely right.
> I find Clojure awful both conceptually and implementation-wise (the imposition of lowest common denominators by JVM dependency really sucks here, starting with lack of tail calls, but not ending there), so that's most likely not going to happen.
You do you, but I personally would do some thinking on why Clojure has eaten CL’s lunch, despite your belief in its inferior design and implementation.
(Edit: for the record I’ve worked professionally in CL, Clojure, Java, and some others. I think Java is best, but I think that your argument about Clojure being inferior to CL is incorrect).
Also, tail calls? Really? Genuinely can’t remember the last time that mattered to me.
> I don't see why the good things in Clojure should be impossible to achieve in CL as libraries.
I don’t see why “impossible” would be a factor here. It’s not technology that’s holding CL back here, but rather what the community values and spends its collective time on.
You do you, but I personally would do some thinking on why Clojure has eaten CL’s lunch, despite your belief in its inferior design and implementation.
(Edit: for the record I’ve worked professionally in CL, Clojure, Java, and some others. I think Java is best, but I think that your argument about Clojure being inferior to CL is incorrect).
Also, tail calls? Really? Genuinely can’t remember the last time that mattered to me.
> I don't see why the good things in Clojure should be impossible to achieve in CL as libraries.
I don’t see why “impossible” would be a factor here. It’s not technology that’s holding CL back here, but rather what the community values and spends its collective time on.
> but I personally would do some thinking on why Clojure has eaten CL’s lunch, despite your belief in its inferior design and implementation.
It's largely a similar reason why Java has eaten Smalltalk's lunch (upfront environment costs have been disastrous in the past for both Smalltalk and CL, and in many ways they continue to be - Allegro, LispWorks, VisualWorks are still expensive), plus the fact how Clojure latched itself onto Java's large ecosystem. For a large user base, inferior design and implementation don't matter as much, as PHP has demonstrated amply, so why should they matter here for a similarly large number of people? They won't mind, although some other might.
> Also, tail calls? Really? Genuinely can’t remember the last time that mattered to me.
It's not the only thing deficient in Clojure, but I've noticed that many fairly common patterns get significantly more convoluted without them. If there's no drawback to having them, why not have them? Oh, wait, I forgot, JVM does not support them...
It's largely a similar reason why Java has eaten Smalltalk's lunch (upfront environment costs have been disastrous in the past for both Smalltalk and CL, and in many ways they continue to be - Allegro, LispWorks, VisualWorks are still expensive), plus the fact how Clojure latched itself onto Java's large ecosystem. For a large user base, inferior design and implementation don't matter as much, as PHP has demonstrated amply, so why should they matter here for a similarly large number of people? They won't mind, although some other might.
> Also, tail calls? Really? Genuinely can’t remember the last time that mattered to me.
It's not the only thing deficient in Clojure, but I've noticed that many fairly common patterns get significantly more convoluted without them. If there's no drawback to having them, why not have them? Oh, wait, I forgot, JVM does not support them...
The CL community clearly doesn’t value working together to make Lisp a real world productive language. That’s why the world runs on C/C++ and not Lisp.
No, the world runs on C/C++ mostly because CL vendors were too greedy. It's difficult to convince people to use a $100k environment when you could have gotten a $2k environment instead.
> I’ll remain unimpressed by interoperability improvements to CL so long as the culture of “roll your own libraries!” remains in place.
How do you think those Java libraries got made? Java has also long had a culture of roll your own libraries -- and you had to, because the base language and standard library were quite deficient. (That's a snarky point, admittedly, but there are a lot of libraries in various languages that are just built-in functions in Lisp or Python or whatever, and there's a scale of effort there between built-in functions, built-in standard library, etc. that influences the pressure to make and share libraries. Like, I once wanted to get an approximate fraction, like Python's fractional's Fraction.limit_denominator, but in JS I had to bring in Google's Long.js and then steal a hundred lines of code from Python's implementation and elsewhere. There might be a library now.)
Where Java won out was copying Perl et al. of having a centralized place anyone could upload open source, and then having armies of programmers forced to use it who inevitably end up making and sharing libraries and frameworks to make their lives better and eventually a desirable place to be for lots of things. J2EE and the JCP/JSRs were also masterclass social innovations to improve the ecosystem and take over enterprise and allow groups to agree on specifications if not implementations. Lisp's version of that is still absent. At best there's functionality that implementations add beyond the ANSI spec, and differences papered over with trivial-blah libraries, and occasionally some informal lobbying will get a feature implemented with the same protocol across each active implementation (package-local nicknames coming to mind as a recent one). Of course this situation isn't that different to a lot of other language ecosystems.
CL got quicklisp, much too late, but it's here now and provides a baseline experience to beat if someone wanted to try like has happened in Java with ant/maven/ivy/gradle/etc. CL is then just missing hordes of programmers, and is unlikely to get them without either big company backing, many more small companies using it (this seems to be the way it's slowly been improving in popularity in the last several years), or an unexpectedly popular application domain (perhaps with accompanying hardware) where using it and its tools provides the clear best-in-class experience, or even the only experience, good or not, as is the case for many things involving other languages.
The culture now seems to be "check quicklisp, if it's not there, roll your own, and share to quicklisp". Maybe some more effort needs to be made on "try to collaborate and improve if something is on quicklisp and not quite what you want but close" rather than making something brand new, but collaboration exists on quite a few projects, and Java has lots of overlapping libraries too, it's not that big a problem. If Lispers lost any of their "roll your own" enthusiasm, the logical endpoint when something's not in the quicklisp set is to give up and search for a library in another language. And if it doesn't exist there either? Your only option is to program it yourself or pay someone.
It really seems like you just want CL to get the libraries and tooling you expect from the Java world, especially stuff mostly used by big companies with big deployments. And that's totally fair, Java's a great ecosystem despite annoyances with the language (which a big IDE helps paper over). I just think painting the lack of an equivalent ecosystem as a consequence of "roll your own libraries!" culture is mistaken.
How do you think those Java libraries got made? Java has also long had a culture of roll your own libraries -- and you had to, because the base language and standard library were quite deficient. (That's a snarky point, admittedly, but there are a lot of libraries in various languages that are just built-in functions in Lisp or Python or whatever, and there's a scale of effort there between built-in functions, built-in standard library, etc. that influences the pressure to make and share libraries. Like, I once wanted to get an approximate fraction, like Python's fractional's Fraction.limit_denominator, but in JS I had to bring in Google's Long.js and then steal a hundred lines of code from Python's implementation and elsewhere. There might be a library now.)
Where Java won out was copying Perl et al. of having a centralized place anyone could upload open source, and then having armies of programmers forced to use it who inevitably end up making and sharing libraries and frameworks to make their lives better and eventually a desirable place to be for lots of things. J2EE and the JCP/JSRs were also masterclass social innovations to improve the ecosystem and take over enterprise and allow groups to agree on specifications if not implementations. Lisp's version of that is still absent. At best there's functionality that implementations add beyond the ANSI spec, and differences papered over with trivial-blah libraries, and occasionally some informal lobbying will get a feature implemented with the same protocol across each active implementation (package-local nicknames coming to mind as a recent one). Of course this situation isn't that different to a lot of other language ecosystems.
CL got quicklisp, much too late, but it's here now and provides a baseline experience to beat if someone wanted to try like has happened in Java with ant/maven/ivy/gradle/etc. CL is then just missing hordes of programmers, and is unlikely to get them without either big company backing, many more small companies using it (this seems to be the way it's slowly been improving in popularity in the last several years), or an unexpectedly popular application domain (perhaps with accompanying hardware) where using it and its tools provides the clear best-in-class experience, or even the only experience, good or not, as is the case for many things involving other languages.
The culture now seems to be "check quicklisp, if it's not there, roll your own, and share to quicklisp". Maybe some more effort needs to be made on "try to collaborate and improve if something is on quicklisp and not quite what you want but close" rather than making something brand new, but collaboration exists on quite a few projects, and Java has lots of overlapping libraries too, it's not that big a problem. If Lispers lost any of their "roll your own" enthusiasm, the logical endpoint when something's not in the quicklisp set is to give up and search for a library in another language. And if it doesn't exist there either? Your only option is to program it yourself or pay someone.
It really seems like you just want CL to get the libraries and tooling you expect from the Java world, especially stuff mostly used by big companies with big deployments. And that's totally fair, Java's a great ecosystem despite annoyances with the language (which a big IDE helps paper over). I just think painting the lack of an equivalent ecosystem as a consequence of "roll your own libraries!" culture is mistaken.
> How do you think those Java libraries got made? Java has also long had a culture of roll your own libraries -- and you had to, because the base language and standard library were quite deficient.
That’s quite a silly argument. Basically no language has all the things I pointed out in the core library. By this definition every language community is the same, which is obviously not true.
Also, the Java standard library is pretty damned big compared to CL.
> Where Java won out was copying Perl et al. of having a centralized place anyone could upload open source
You’re rewriting history a bit here. Java didn’t start with a central repository, it was shipped nearly a decade after Java was released. This wasn’t a planned decision by the Java team, but a consequence of decisions made by the community. CL could’ve done this decades ago too, but they’ve been very slow to the party.
I also believe that QL’s plan of manually approving every new library is putting unnecessary friction in the process.
> It really seems like you just want CL to get the libraries and tooling you expect from the Java world, especially stuff mostly used by big companies with big deployments.
Not personally, no. I’ve worked in CL, and I did not enjoy it. I do not suffer from “grass is greener” syndrome, and I’m perfectly happy with Java.
But to those that still hold up CL as a reasonable alternative to Java, my answer is that these things are the tablestakes for even being considered for industrial use.
That’s quite a silly argument. Basically no language has all the things I pointed out in the core library. By this definition every language community is the same, which is obviously not true.
Also, the Java standard library is pretty damned big compared to CL.
> Where Java won out was copying Perl et al. of having a centralized place anyone could upload open source
You’re rewriting history a bit here. Java didn’t start with a central repository, it was shipped nearly a decade after Java was released. This wasn’t a planned decision by the Java team, but a consequence of decisions made by the community. CL could’ve done this decades ago too, but they’ve been very slow to the party.
I also believe that QL’s plan of manually approving every new library is putting unnecessary friction in the process.
> It really seems like you just want CL to get the libraries and tooling you expect from the Java world, especially stuff mostly used by big companies with big deployments.
Not personally, no. I’ve worked in CL, and I did not enjoy it. I do not suffer from “grass is greener” syndrome, and I’m perfectly happy with Java.
But to those that still hold up CL as a reasonable alternative to Java, my answer is that these things are the tablestakes for even being considered for industrial use.
> 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.
Sorry to be so blunt but this is ridiculous. You are mentioning hash tables and multithreading to prove your point. I am pretty sure this is not what parent meant when they wrote "The ecosystem is just not there". And what does "writing your own libraries because it's so easy to do" even mean? You still have to do it and it takes a lot of time and money. A library that talks a specific protocol to a medical devices. A library that writes some obscure data format used by some government somewhere on earth. This is the real world.
Sorry to be so blunt but this is ridiculous. You are mentioning hash tables and multithreading to prove your point. I am pretty sure this is not what parent meant when they wrote "The ecosystem is just not there". And what does "writing your own libraries because it's so easy to do" even mean? You still have to do it and it takes a lot of time and money. A library that talks a specific protocol to a medical devices. A library that writes some obscure data format used by some government somewhere on earth. This is the real world.
Writing your own library also has the disadvantage that 100% of the new hires have never seen how to use that library.
As opposed to "a library that talks a specific protocol to a medical devices" or "a library that writes some obscure data format used by some government somewhere on earth" which new hires wouldn't know how to use either because only a hundred people on Earth have ever used either of those?
Actually yes. While there are a lot of different medical devices if you have an engineer who worked with that specific device before (not unlikely if you hire for that) will most likely have worked with the vendor library, but not with yours.
In that case, should you choose to write your application in Lisp for whatever reason, it's very likely that you'd be able to use that library from Lisp with a more-or-less isomorphic API and recycle that knowledge.
> 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.
Some people love to point out how stupid JS programmers are because of the left-pad incident.
The reality is that, in almost every domain, there are many things which are either difficult and/or time-consuming to implement, or common across several projects and tasks. Do you really want to waste your own time and the time of your teammates reimplementing these things for every project if you don't need to?
Even if the underlying implementation is "easy", having a handful of well-tested libraries with thoughtfully-designed APIs is important for productivity in many (most?) programming tasks. Yes, there might always be a specific case when you can't use the popular library for X, but that's the exception and not the norm.
"It's easy to write your own libraries" is true in any professional-grade language. Arguably it's one of the things that makes a professional-grade language professional-grade. It's not a justification for having a bad library ecosystem, it's a rationalization.
As a side note, I think the Lisp library ecosystem in 2021 is pretty good, considering how unpopular it is in industry.
Some people love to point out how stupid JS programmers are because of the left-pad incident.
The reality is that, in almost every domain, there are many things which are either difficult and/or time-consuming to implement, or common across several projects and tasks. Do you really want to waste your own time and the time of your teammates reimplementing these things for every project if you don't need to?
Even if the underlying implementation is "easy", having a handful of well-tested libraries with thoughtfully-designed APIs is important for productivity in many (most?) programming tasks. Yes, there might always be a specific case when you can't use the popular library for X, but that's the exception and not the norm.
"It's easy to write your own libraries" is true in any professional-grade language. Arguably it's one of the things that makes a professional-grade language professional-grade. It's not a justification for having a bad library ecosystem, it's a rationalization.
As a side note, I think the Lisp library ecosystem in 2021 is pretty good, considering how unpopular it is in industry.
Agree. I find it super easy to write my own libraries in C++/Java/Haskell/… but it is silly to do that when somebody else have already spent years creating a great library you can just drop in and use in a few minutes.
> The philosophy of Lisp encourages writing your own libraries because it's so easy to do
That statement could be said of any language the programmer is comfortable with. It's no more a LISP philosophy than a C++ one. The difference is that way more people are working with C++ (or Java) thus opensourcing their libraries for others to be used.
That statement could be said of any language the programmer is comfortable with. It's no more a LISP philosophy than a C++ one. The difference is that way more people are working with C++ (or Java) thus opensourcing their libraries for others to be used.
I think the argument there was that lots of things were so much easier to do in Lisp that people wrote their own implementation, then they thought "what's the big deal about it?", and then they didn't share their library because they didn't think they've accomplished something meaningful to share. So you end up with people doing things in C++ and Java and publishing it and getting their code reused because 1) the authors of the code were more likely to think of publishing their code as a useful thing, and 2) due to some things being harder in those languages, other people were more likely to shop for libraries rather than to think "I can do this myself".
[deleted]
> You're expected to know how to program if you use Lisp
I am pretty sure you are expected to know how to program if you use any programming language. And writing everything from scratch, instead of taking advantage of the work done by thousands of other skilled developers, is just silly. With that attitude, no wonders the world runs on C/C++ and not Lisp.
I am pretty sure you are expected to know how to program if you use any programming language. And writing everything from scratch, instead of taking advantage of the work done by thousands of other skilled developers, is just silly. With that attitude, no wonders the world runs on C/C++ and not Lisp.
You know your Lisp.
If you are every in need of a subject to write about--I might even pay for a walkthrough of the code that built Hackernews.
I don't think I'm alone either.
If you are every in need of a subject to write about--I might even pay for a walkthrough of the code that built Hackernews.
I don't think I'm alone either.
It's not a library unless it's 80% as hard to use it as it would be to implement its functionality from scratch.
[deleted]
Sure, libraries exist in Lisp. The claim that they don't was a fairly ridiculous statement. But...
Do libraries exist in Lisp on the same scale as they exist in Java? Especially, do they exist with the same level of quality, professionalism, and maintenance as they exist in Java? I'm guessing that the answer is no.
Do libraries exist in Lisp on the same scale as they exist in Java? Especially, do they exist with the same level of quality, professionalism, and maintenance as they exist in Java? I'm guessing that the answer is no.
But you just touched on the reason programmers don't like Lisp: they prefer a language that has a lot of little bits of available functionality that they can mix and match, without having to do any real programming. Programming, as we knew it, is a dead art, modern developers only want to reuse some library that was created by someone else. Languages like Python and Java are bad to program, but ideal for this kind of lego-based development.
> … are bad to program
And yet everything you run your software on (Linux/Windows/your browser etc.) is written in those languages. Mostly C/C++. So clearly millions of developers can do real work with those languages. And very little real world useful software (except a few websites and Emacs) is built with Lisp. Despite Lisp being an older language that most. And yes I know the standard reply to this is “all non-Lisp developers are stupid” which is just unbelievably childish/arrogant.
And yet everything you run your software on (Linux/Windows/your browser etc.) is written in those languages. Mostly C/C++. So clearly millions of developers can do real work with those languages. And very little real world useful software (except a few websites and Emacs) is built with Lisp. Despite Lisp being an older language that most. And yes I know the standard reply to this is “all non-Lisp developers are stupid” which is just unbelievably childish/arrogant.
There have been several idiotic comments by lisp proponents in this thread and this is one of the stupidest. You appear to be criticizing all programmers that use libraries. You, and your peers, are coming off as arrogant and ignorant hobbyists, but the people you're talking to are largely professional programmers solving real world problems. Of course, one solves the problems that remain to be solved, and reuse good and proven solutions where these exist.
You are absolutely right. The arrogance of Lisp developers is just breathtaking. Especially because the very same developers have no evidence to support their claims. The world runs on C/C++/JavaScript. Not Lisp.
Yes, honestly, I love lisp, although my only claim to being a lisp programmer is that I'm the author of some emacs packages. But I have to admit that yes I've noticed a definite tendency for people in the emacs lisp community to be abrasive and difficult and not very friendly in open source work. I think perhaps more of them are in university-related jobs in europe and hence haven't experienced the wonderful fake friendliness of california tech companies.
Thanks for being honest about it. Lots of kudos! It is fine to be happy with a specific language. It is not fine (and very immature) to assume everybody else are idiots. Especially when those “idiots” have created all the software we use.
I don’t think Lisp is popular in European academia? Europe is very much hard core type theory. Just look at Coq, Idris, Haskell etc.
This is ridiculous! When you want to write a book or just take some notes, do you want to make your own paper all the time? Mix your own ink? I see the appeal to do this once or from time to time, but if I have to scribble something down, I'm glad these are ready-made for me. Guess I'm just a lego-based author.
This is not a good comparison at all. The better way to describe it is this: when you want to write a book, do you write paragraphs or you just write quotes from other authors? Writing your own text is similar to write your own code. On the other hand, pasting quotes from other people is not a good way to convey your ideas, but it is much quicker for those who don't want to write themselves.
No, it's a perfect comparison. If I do an art project, I might want to start from the very basics and want to do everything on my own. If I have work to do, a budget and a deadline, I use existing building blocks wherever possible.
I just imagine telling my boss I could do the job in a week in Python ... or I could use this amazing forgotten language that requires me to implement almost everything from scratch. But it will be totally worth it, some day, I swear!
I just imagine telling my boss I could do the job in a week in Python ... or I could use this amazing forgotten language that requires me to implement almost everything from scratch. But it will be totally worth it, some day, I swear!
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.
The ecosystem is a function of popularity.
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.
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.
25 years of programming experience here. I have written my own Lisp runtimes, micro kernels, C compilers, high performance web servers, a million selling game written in C, high performance pairing/rostering optimisers for the airline industry etc. I am a language geek and have programmed in pretty much everything I could get my hands on. And are currently maintaining a high performance compiler for a Haskell style language, and have fun learning how to prove code correct using Coq/F*/Idris/Lean. Is that mature enough for you? I would have zero problem writing applications in Lisp. But I choose not to. Why? Because I am more productive in other languages. That might not be the case for you. However your N=1 experiment doesn’t in any way generalise to N=everybody else.
I think it is a matter of education. Software developers learn to program in traditional languages, and Lisp is just an add on. So they really don't know how to use Lisp well. Languages like Python and Java benefit from all the formal education programmers have received in the concepts they use.
I think it's more fundamental than that. Reading and writing Lisp means turning your brain into an AST analyzer. Some programmers love this. Most don't.
Yeah although changing from print(x) to (print x) isn't that much of a deal.
Where I saw fellow university friends having a problem was with thinking in Prolog and computational logic.
Where I saw fellow university friends having a problem was with thinking in Prolog and computational logic.
You're right - at the single element level it's not that different.
But the overall effect is very different. For instance, simple ergonomic things that help programmers read code, like the word "else" in an if statement/expression are elided because its AST is implicit in its position in Lisp. Similarly, you can't quickly scan a page of code for something like "=" to see what's getting assigned - you have to look for let pairs.
And even then, making local variables seems to be considered wasteful in Lisp if there's a way to structure it so that the value can be placed somehow directly into the AST as the evaluation of an expression. The result is that most Lisp code I've seen has a rigidity to it of deep expressions within expressions. Deep expressions are certainly possible to implement in other languages, but it's rare to see it done so thoroughly as Lisp developers seem to enjoy doing.
The result is "hard to read" in the sense that it's harder to scan syntactically (lisp having essentially no syntax) and harder to modify due to the carefully constructed expression nesting. These may both be seen as my own shortcomings wrt the language, but I think many others share them.
But the overall effect is very different. For instance, simple ergonomic things that help programmers read code, like the word "else" in an if statement/expression are elided because its AST is implicit in its position in Lisp. Similarly, you can't quickly scan a page of code for something like "=" to see what's getting assigned - you have to look for let pairs.
And even then, making local variables seems to be considered wasteful in Lisp if there's a way to structure it so that the value can be placed somehow directly into the AST as the evaluation of an expression. The result is that most Lisp code I've seen has a rigidity to it of deep expressions within expressions. Deep expressions are certainly possible to implement in other languages, but it's rare to see it done so thoroughly as Lisp developers seem to enjoy doing.
The result is "hard to read" in the sense that it's harder to scan syntactically (lisp having essentially no syntax) and harder to modify due to the carefully constructed expression nesting. These may both be seen as my own shortcomings wrt the language, but I think many others share them.
Hardly any different than hunting down for ?: on C derived languages, clever uses of LINQ inspired expressions, or why a bunch of ([{((}]]) distributed across function call, if, else, while expressions aren't nesting properly.
> (...) although changing from print(x) to (print x) isn't that much of a deal.
Except it is.
One is just syntax you write to get compiler to emit code you can more or less predict at "write time" and the other is a data structure you can operate on and get to emit any code you want.
Most people I worked with on Common Lisp / Clojure projects never made the leap to treat the program as data structure. So it evidently is "a big deal".
The whole point of Lisp is to have your program be a data structure and then have a core language that is very good at manipulating data structures, so if somebody doesn't get it they are not really realizing benefits of Lisp and they would be better off in a poorer but more approachable language like Java.
Except it is.
One is just syntax you write to get compiler to emit code you can more or less predict at "write time" and the other is a data structure you can operate on and get to emit any code you want.
Most people I worked with on Common Lisp / Clojure projects never made the leap to treat the program as data structure. So it evidently is "a big deal".
The whole point of Lisp is to have your program be a data structure and then have a core language that is very good at manipulating data structures, so if somebody doesn't get it they are not really realizing benefits of Lisp and they would be better off in a poorer but more approachable language like Java.
They have, they just did not realize that is what they were doing when placing those Spring annotations, or compiler plugins invoked via Maven dependencies.
It is a matter of quality as well, many universities do still teach Lisp languages.
> it requires a relatively high level of maturity and experience to be used effectively on nontrivial projects.
Other languages scale smoothly from beginner to expert. So I guess that your assertion shows that Lisp is a less useful language?
Experienced programmers using non-Lisp languages are successful every day. Your OS/mobile phone/browser/… is the result of their work. So I guess other languages are better for experienced developers as well?
In other words, the real world evidence seems to suggest that Lisp is not good for beginners and not good for experienced developers.
Other languages scale smoothly from beginner to expert. So I guess that your assertion shows that Lisp is a less useful language?
Experienced programmers using non-Lisp languages are successful every day. Your OS/mobile phone/browser/… is the result of their work. So I guess other languages are better for experienced developers as well?
In other words, the real world evidence seems to suggest that Lisp is not good for beginners and not good for experienced developers.
It would be really nice to see all the awesome code written by the Lisp lover who downvoted this post. Because Lisp is apparently this magical language that enable you to write world class software so much faster than languages used by the rest of us. So where is it? All of this wonderful Lisp code that is so much better than the C/C++/Java/JavaScript code that actually run the world? I suspect I will have to wait a very long time for a good answer.
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.
Things are not so simple
Things are not so simple
https://github.com/CodyReichert/awesome-cl there are less than in Java-land but there might be more than you think. And there are options for the rest.
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.)
One can still say "to moot an issue for discussion (bring up an issue)" but what also fascinates me is the other meaning for mute involving bird evacuation. I have to wonder what happened in Latin?
Interesting to look back on this in a world where Clojure has carved out a space for itself
Lisp as an alternative to Java, still, in 2021 (and C++ and Rust[1]): https://renato.athaydes.com/posts/revisiting-prechelt-paper-...
[1] talking about speed
[1] talking about speed
I want to see an article:
"Go as an Alternative to C"
"Go as an Alternative to C"
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.
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)