> 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.
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:
Yup, all of those () and {}s and commas and semicolons and single quotes were inputted manually. I say to my editors, "just let me type".
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.
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 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 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.
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."
> 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.
> 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
;; 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)
> 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.
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.
> 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.
> 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.
> 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.
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.
> 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.
> 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.
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.
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.
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.
> 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...
> 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?
I find this dismissive attitude so tiring. Given the huge number of people actually shipping useful code in languages with “inferior design”, perhaps you’re just wrong about what’s good design?
Either way, implying that Lisp is so much better than what the unwashed masses use is not persuasive, and has a tendency to turn off other people.
I never said that you can't make good code in PHP.
> perhaps you’re just wrong about what’s good design?
It does not follow from people making good code in PHP that PHP itself is good (or that it couldn't better than it is), just like it does not follow from people making bad code in any language X that language X is bad. So that would be a "no" on that front.
> implying that Lisp is so much better than what the unwashed masses use is not persuasive
I think you completely missed my point. It's not supposed to be "persuasive". It's the basis for my own personal decisions. I don't need to "persuade" myself. Some people may make this a basis for their own decisions, but whether they do that or not is their business, not mine.
In fact I wouldn't have even mentioned my opinion of Clojure had you not pushed Clojure on me, so there's that. If you don't like that I prefer Clojure over CL, simply don't bring it up the next time.
While it is true that the standard doesn't mandate it, any implementation worth its salt allows you to do tail calls. It's the same with threads; "if you want to write portable Lisp code" you can't expect threads in CL "in general" either. In practice, real-world CL implementations can do threads just fine.
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.
Free open-source high quality Lisp implementations have been available for decades now. Where is all the awesome software written by the self-proclaimed Lisp geniuses? With people that clever and with access to a language that powerful surely software written in Lisp should be totally dominating by now. Surely all the “crappy” software written by those non-smart non-Lisp developers should have been totally outclassed by now right? And yet it isn’t. Not even close. Lisp has had close to zero impact on the real world. So perhaps, just perhaps, the Lisp developers are no more smart than the rest of us and perhaps, just perhaps, Lisp isn’t a more productive language that the languages used by everybody else.
> 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 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.
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.
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.
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".
> 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.
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.
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.
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.
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!
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.
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.
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.
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.
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 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.
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.
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?
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)