2 ms·
It's mainly that the core editor is Emacs or proprietary ones that have indeterminate futures, there are different implementations that are incompatible for thi
by bmitc 3y ago
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.
- vindarel 3y agoToday other editors have good to very good support, such as Vim or Atom/Pulsar: https://lispcookbook.github.io/cl-cookbook/editor-support.html 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.
- eadmund 3y ago> 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.
- bmitc 3y ago> 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.
- eadmund 3y ago> 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!