Packaging software for Linux users is a nightmare. Unless
- your program is extraordinarily simple
- you can manage to statically link libc
- you can ship (or statically link) all .so files
- you can ensure your app can run in a sandbox
- you limit the distros you build for
- your app can be built by whatever is on flathub
etc., most solutions to shipping software simply don't work out-of-the-box. Despite the kernel being reasonably stable, userspace APIs are a mess of incompatible.
This is a great point, and you are right. However, using cpack+cmake makes the packaging pretty easy, gets the dependencies right for you. The problem is in dealing with all the package various manager repos.
The problem is that the intersection between your business's interests and the interests of the small pool of available developers is usually very small.
Building banking apps? Well, even if it's Haskell, the Haskellers were dreaming of GPU compiler jobs, not banking front ends. So you're probably down to literally 5 qualified people on earth who want your job.
But then 3 of those 5 don't want to relocate or have other operational desires that require you to re-think how you run your team, and 2 of those 5 believe so strongly in supply-demand that their salary should be 3x the industry average.
Many companies, including Jane Street, come to the same conclusion: If you really want developers of a niche language, you have to be very good at finding smart people who don't know the language and training them.
What evolution in particular do you think? The developers use it for commercial products in quantum computing and defense [1]. That doesn't mean it's done in some complete language ecosystem sense (which is discussed in [1], and one could argue Haskell also never feels "finished"), but it also doesn't seem like an unfinished hobby project. Given that it's embedded in Common Lisp, there's always a way to fill in the library gaps, sort of like how if a "native" library doesn't exist in Clojure, one can always reach for Java.
[1] From Toward Safe, Flexible, and Efficient Software in Common Lisp at the European Lisp Symposium, "[Coalton] has been used for the past 5 or so years [...] first in quantum computing and now a serious defense application." https://youtu.be/xuSrsjqJN4M&t=9m14s
I am an avid sbcl and coalton user (and sponsor of both when I can) and never said it was not a great thing; comparing it to Haskell is, outside the theoretical type system roots, just a bit early type system wise.
I agree with you further and you did an excellent promotional comment for Coalton and CL; keep doing that please. I have said many times here before that I did not like my time away from CL and Coalton makes it even better.
Actually, variations on M-expressions have been created many times in the Lisp world. (Look what you can do with macros!) So far, none of them has caught on. The latest attempt for Scheme is SRFI-266, which creates a very nice infix expression sublanguage. If I were working on a team, I would encourage them to use this, but I don't know if it has enough traction to become widespread.
It's a common mistake to think that the syntax of Lisps are a problem. People solving the supposed problem then discover it wasn't something that needed to be solved.
<meta>I've noticed this more recently on HN. Either the top comment has to be some negative sentiment even if seemingly good-faith, or a comment on something completely tangential (like the color of the website), or a comment on their own project that's related to the thing posted but it feels more like look-at-me advertising rather than earnestly engaging with the submission. Some of these go against the guidelines, but maybe my own comment here does as well.
As of writing, the top comment is "Why?" like the project has to defend itself, on a website that's notionally about curious, interesting, and insightful discussions.</meta>
I used Notepad++ way back when, sort of before I "graduated" to Emacs and the like. I don't know how it's evolved over the past two decades (I presume, intentionally, not much) or what attracts its fanbase anymore. I know I liked it because it felt like a substantial jump from notepad.exe without feeling bloated and slow. At the time, some of the competition felt sluggish while Notepad++ felt nimble.
What do people love about Notepad++ that still isn't really addressed by the "less humble" editors out there?
"It should be easy enough for" sets a UX bar, not a target audience. Kind of like the English phrase "X is so easy that even a toddler could do it," regardless of whether such a statement is figurative or literal.
For historical interest, Lem did used to advertise itself as a Common Lisp development tool specifically, but that has changed relatively recently (past year?). From my distant vantage point, it looks like general interest in it grew, and Lem itself evolved in general-purpose directions, so they pivoted the messaging to be about it serving as a general-purpose editor instead of one just for Common Lisp.
Something like SLIME isn't essential to execute Lisp code, you're right, but it is essential in order to understand the efficiencies afforded by interactive development, which may as well be one of the pillars of the language, since "garbage collection" and "an object system" aren't in and of themselves differentiators anymore*. Using something like SLIME also takes a lot of the pains that people have with Lisp away, namely balancing parens and indenting code correctly. People who do the "I'll use my own editor" approach to beginning Lisp usually write things that look like:
(defun myfun(x)
(let (x)
(setq x 5)
(when (eq x 6)
(print "6")
)
)
)
Which is absolutely not what Lisp code should look like. Emacs-and-kin don't outright stop that, but the defaults are such that it's less likely.
____
* Of course, technically, CLOS is something to behold. But you won't sell someone on Lisp because it can do "OOP".
Interactive development is because Common Lisp runntime has the concept of images and systems. Just like you start you OS and do things with it, you start the Lisp runtime and do things with it. It’s a point A to point B type of interaction like running a script. Smalltalk, SMl, a modern web browser,… has the same kind of interaction. It’s not dependent on any editor.
Also automatic idiomatic formatting of lisp code is possible in any editor as long as they have the settings for it. Not sure how Emacs is the gatekeeper on that one.
What you say is entirely true in theory. An editor can have whatever it wants. Anything is possible—but somebody needs to do the work. If your favorite code editor is Zed, chances are nobody wrote proper Lisp indentation in it or any sort of Lisp interaction mode.
Why has it stuck with Emacs and its derivatives? I don't know. It seems interest in investing time to make a good Lisp environment for a non-Emacs editor fizzles out once it gets to the difficult part of productionizing it, which is why Emacs continues to be the #1 no-cost choice.
Someone threw out a Zed LSP for Common Lisp with LLMs help: https://github.com/etyurkin/zed-cl It requires heavy compilation of the wasm toolchain so I finally didn't try it. It seems it doesn't have a lisp debugger.
Emacs has support for all kind of programming languages and other tools. It's very easy to hack somethings and the effort required to polish it enough for a 0.1 release is small. Compared that to creating a plugin for VS Code or IDEA? Not worth it especially with the disjointed interfaces (Emacs has buffers and nothing else).
Sometimes now just refers to extremely personal cosmetic changes one makes to their OS/DM/WM/SW.
See also this old bit of computer lore [2].
[1] https://en.wikipedia.org/wiki/Rice_burner
[2] https://www.shlomifish.org/humour/by-others/funroll-loops/Ge...