Hacker News Reader

Comment by fuzztester | Hacker News Reader

>Common Lisp is just too "hardcore" for pragmatic use, in my opinion.

In what ways? Asking as Lisp newbie.

It's mainly that the core editor is Emacs or proprietary ones that have indeterminate futures, there are different implementations that are incompatible for things not defined in the standard, such as for GUIs, not a well defined and vibrant ecosystem or community, the package system is strange, and other things of this nature. As a language, I think it has a bit of cruft from being a mismash of everyone's favorite features from all the Lisps around the time that the standard was created. I find that it is hard to read, and this is coming from someone who likes Schemes and doesn't care about parentheses. Furthermore, you will struggle finding a job. Although admittedly, the jobs you do find may be cool. But they may also be giant balls of mud, which is my main impression and true from what I have read.

I think for personal or dedicated use cases within a larger system it is probably awesome. For example, I believe the CLR (.NET) garbage collector was generated via Common Lisp code. I personally use other languages for my personal projects, namely F# and Elixir, and when I want to reach for a Lisp/Scheme, I choose Racket. I find Scheme a more focused language. I don't think I'll ever have the time to actually understand things like CLOS and the metaobject protocol in Common Lisp. The condition system seems pretty cool. I have practically every Lisp book there is, and certainly all the major ones. I just can't get into it, and when I try, it just feels like it's stuck in the past as an ecosystem, and I revert to Scheme or another language. The notebooks in F# and Elixir are gamechangers, in my opinion, for learning, going through books, and even production uses. The various Common Lisp books are awesome, but I use F#, Elixir, and Racket when working through the bits I do write code for.

Today other editors have good to very good support, such as Vim or Atom/Pulsar: https://lispcookbook.github.io/cl-cookbook/editor-support.ht... the VSCode plugin is here and evolving, we can use Jupyter notebooks, and even a very cool editor written in CL, working out of the box for CL and other languages with its built-in LSP client, Lem.

> It's mainly that the core editor is Emacs

What’s the problem with that? Emacs is, on balance, the best editor and ecosystem. Nothing else comes close, and time spent on anything else is ultimately wasted.

> I don't think I'll ever have the time to actually understand things like CLOS and the metaobject protocol in Common Lisp.

They are really worth considering. I have found that the longer I use them, the wiser the decisions they encode were.

> The condition system seems pretty cool.

It really is. The more you get used to it, the more intolerable it is that other languages don’t provide something similar out of the box.

Common Lisp isn’t perfect, of course. It has some very real flaws! But at the end of the day, nothing else matches it, even though over the past three decades the baseline language has gotten closer.

Garbage collection was a huge win on the past. Gradual typing, too. But the baseline language of today still doesn’t have macros. It still doesn’t have something approaching CLOS, let alone the MOP. Almost no languages have reasonable condition handling.

In a ton of ways, Common Lisp is an improvement on its successors.

> What’s the problem with that? Emacs is, on balance, the best editor and ecosystem. Nothing else comes close, and time spent on anything else is ultimately wasted.

That is a pretty strong statement. Every time I try Emacs I revert to VS Code. Is it as immediately programmable? No. But it doesn't have to be because the extensions are plenty and quite good and work without mucking about with .emacs. One can go quite deep with it when developing an extension, though. VS Code has the remote server extensions as well, which are seamless. I use VS Code on three or four different computers (as in running it as a GUI as a desktop app) every day all the while developing locally, in a Docker container, in a Linux distribution through WSL, or SSHed into several Linux machines. My settings and extensions automatically sync, the extensions just work on any machine including while remoting, and its all seamless from use case to use case. No other editor has this experience. Plus, it supports rich graphics like Markdown preview, HTML preview, notebooks like Polyglot Notebooks that can share data between cells in different languages and display images and animations, and more. Emacs does not have that support to the same degree.

> Almost no languages have reasonable condition handling.

That's true. But Erlang and Elixir are major contenders. Erlang actually probably got there first.

> VS Code has the remote server extensions as well, which are seamless … No other editor has this experience.

Emacs has TRAMP.

> it supports rich graphics

Emacs supports graphics in a GUI. I view PNGs and PDFs in it all the time.

> HTML preview

Emacs has eww, w3m-el, emacs-webkit & xwidgets.

> notebooks like Polyglot Notebooks that can share data between cells in different languages and display images and animations

Have you heard of Org Mode? It’s rather more than that.

> Emacs does not have that support to the same degree.

While I am certain that is true of at least a few things, for many things it has more impressive support.

Emacs is not perfect. For one thing, it’s not written in Common Lisp (blame rms for a startlingly bad misjudgment there). And it’s certainly acquired some cruft over the course of its lifetime. But there is a very real sense in which time spent using or extending any other editor is ultimately wasted. I am fairly certain that in 40 years there will be no VisualStudio; there will be no Vimscript; there will be probably be no Lua; if we are very, very lucky there will be no JavaScript. But there will be Emacs, and there will be Lisp. Each investment made in either today will continue to pay dividends for the rest of one’s life, no matter how young one is today.

> Erlang actually probably got [condition handling] first.

Erlang was first released in 1986, according to Wikipedia. Guy Steele’s Common Lisp the Language was released in 1984 and documented a language which had been in use for quite some time. The condition system was reported on in 1983’s Signaling and Handling Conditions.

I think that Smalltalk’s condition-handling is similar to Lisp’s. Smalltalk is a really awesome language. So’s Erlang, from what I remember!

> The condition system was reported on in 1983’s Signaling and Handling Conditions.

Symbolics had the New Error System in 1983. Which was inspired by the condition system of Multics.

Yes, those are always mentioned. Do you have a video or documentation showcasing that they can do these things and in an integrated fashion and don't take more than 5 minutes to setup? Do all those packages work seamlessly when remoted into another machine and across operating systems?

In VS Code, I open VS Code and install the extensions. I don't need to install an extension manager. I don't need to configure an extension manager. I don't need to go and find which extension manager the extension I want is in. And I don't need to configure the extensions once installed (but can if I want).

I guess the point is, Emacs is not the only editor with a vast amount of workflows that can be merged together. It's powerful, for sure, but it's not the objectively best editor.

It doesn't give you good tools for networking, for writing concurrent or asynchronous code, for graphics, it doesn't give you a good package manager or means of distributing code, its data structures are unwieldy, it takes work to make it performant, etc.

The obstacles add up, and the time you spend on these issues by dealing with hopefully supported community libraries or rolling your own is time spent not dealing with the real problem you're trying to solve.

Racket and Clojure are better suited for pragmatic use in my opinion/experience.

Perhaps you can get some of the advantages that you cite as missing by using an embedded LISP or Scheme implemented in Rust, so you can piggy-back on Rust's nice ecosystem and still have a dynamic "LISP sub-system". For instance:

https://github.com/isamert/scheme.rs (a Scheme in 3853 lines of Rust)

That's really what Clojure is, except based on the JVM, with access to the Java stdlib.

> obstacles add up

I actually agree. It wasn't smooth for me to ship my first CL app. It's all better now (more tools, more documentation, more blog posts from several people, more SO questions and answers!).

> performant

SBCL is in the same ballpack of C, Rust or Java in many benchmarks.

In this article series, the author writes the same program in CL, Rust and Java. In fact, he copy-pastes a PG snippet from 30 years ago. This snippet beats Rust and Java in LOC and speed. But, yeah, he wasn't writing super efficient Rust code, so after many discussions, pull requests and sweating, the Rust code became the most performant. https://renato.athaydes.com/posts/revisiting-prechelt-paper-... It didn't take work to make the CL code performant, more so for the Rust one ;)

a benchmark after sb-simd vectorization: https://preview.redd.it/vn5juu36v2681.png?width=715&format=p... (https://www.reddit.com/r/Common_Lisp/comments/riedio/quite_a...)

> good tools for networking, for writing concurrent or asynchronous code, for graphics,

I refer the reader to https://github.com/CodyReichert/awesome-cl but yes, CL won't have the best libraries in some scenarii (GUI? Tk libs are good, we have Gtk4, a Qt5 library used in production© by a big player but difficult to install etc)

> it doesn't give you a good package manager or means of distributing code

Quicklisp is neat, with limitations, that can be addressed with Qlot, ql-https, or CLPM or the newest ocicl.

These types of comparisons aren't "fair". As in most fields of engineering, programming languages/databases/etc. are about tradeoffs, and benchmarks aren't even more tricky.

From the blog:

> If you don’t have time: Rust can run much faster, but so can the other languages, and it turns out that the Java implementation might run faster than the Rust fastest implementation, according to the new benchmarks I’ve run after many Rust developers came to assist in making Rust faster. Common Lisp may have fallen behind, but that’s likely just because it was not nearly as optimized as the Java and Rust implementations were.

The reason PHP, Ruby, Python, bash, etc. are popular are because of developer productivity, not performance.

Also, it's a false dichotomy. Java uses `zlib` for its GZIP*Streams for performance reasons, and if there was a nice Rust library I wanted to use, I would just build a shared library and call it from Java, just like Java internally uses for `zlib`.

Additionally, there's a fairly large difference in performance between C compilers. See clang, gcc, icc, etc., and the 100+ different options you can use when compiling something.

It's not even close to "apples vs oranges", it's like more "apples vs fire trucks". :-P

Here's the follow-up with an optimized CL version: https://renato.athaydes.com/posts/revenge_of_lisp-part-2.htm... See the conclusion:

- the CL version is the fastest of ALL… in certain conditions ;)

> obstacles add up well put, this is my experience as well. Still an awesome language so I did not mind learning it but I had better luck using clojure for my projects. Especially for web stuff Clojure is just excellent. It also doesn't hurt that you can actually get a job coding Clojure if you're experienced (or so I hear)

Reply on news.ycombinator.com