> I think hardcore Lispers see stuff like a Lisp GUI and natively-graphical Lisp editors as pointless bells and whistles – Emacs was good enough for John McCarthy and it still is for me! – but they really are not in 2021.
That's almost the last line of the article, but it hasn't established any credible argument about why "they really are not in 2021" other than a much longer form of the same assertion.
> Summary: You have to get in there and compete with mainstream, play their game by their rules, if you want to compete.
1. Why does someone want to "compete" ?
2. What would you be competing with?
Convincing people that they could & should use Lisp instead of Python or Swift is facing stumbling blocks far, far larger than the user-experience in an editor/IDE.
If you happen to already be a Vim/Neovim user, the Vlime plugin + Parinfer (or at least Paredit) is pretty good.
If you don't use either Vim or Emacs... that's harder. You can use the Lispworks IDE, although that's limited if you're not paying for it.
I don't think the lack of tooling in Common Lisp is for lack of trying, but for lack of person-hours dedicated to open-source.
That said, there are a lot of gaps in the overall Lisp experience:
- Quicklisp is very unusual, and while it's quite an impressive effort (and definitely a good thing to have in the world), it's a bit odd coming from other programming languages.
- Roswell is great, but under-documented in some areas, and appears to be outright missing features that are actually specified in the docs.
- Qlot, like Roswell, is under-documented in some areas. In particular, using it in conjunction with Roswell can be unintuitive, and there's no guide out there (that I know of) to help with this.
- ASDF itself has the weird restriction that all of your source code has to be in one single directory. A lot of Lisp users I've spoken to don't see this as a problem, but that in and of itself I think is a problem and a reflection of the problems with the Lisp world when seen from the outside. Of course, Qlot alleviates this issue, but see above.
- There is a huge documentation discoverability gap in general. Docs tend to have very trivial examples, and hardcore reference material, with nothing in between. Figuring out how to use even popular libraries like Hunchentoot is not a trivial task.
- There's no actual spec for the SWANK protocol (that I know of), which makes it difficult to build new tooling around it.
- Editing s-expressions efficiently requires special tooling. Paredit is table stakes, but Parinfer is really what you need once you learn the basics and you understand how indentation works in Lisp code style.
Experienced programmers don't need a GUI IDE to get started. But they do need a base of sensible tooling. There will always be a push and pull between "harnessing the full power of Lisp" and "making the power of Lisp accessible outside of some very specific text editors".
> If you don't use either Vim or Emacs... that's harder.
Honestly, it's full on "hacker heresy", but who would, at this point?
That's part of the disconnect. The current generation (hell, the last 3-4 generations of programmers) has earnestly given vim/emacs a fair shake and found the whole paradigm of CLI editors wanting. And that's old news; that shoe dropped a couple decades ago. To them it's not a serious tool; it's a "toy" you dabble in for historical re-enactment like you would with film photography versus digital. Or like writing traditional console games in assembly. A curio.
There were real advantages to oldschool CLI editors, and it's not like they've gone away, but the world moved on. GUI editors have grown so many of their own advantages that you'd have to live without that it stopped being worth it a long time ago. Hacker heresy, like I said, but it's exactly that sense of "things you're not allowed to say" that breeds the disconnect of "why isn't anyone using this?"
I wouldn't be surprised if someone has a solid VSCode language server for LISP out there, and it'd be damned ironic — but not surprising — if something like that grew legs with the traditional community being completely oblivious to its existence.
I don't think that's true. I'm in this current generation, I use VSCode for almost everything, and I don't see Emacs and Vim as toys. I see them however as a very large timesink, and I don't know if it's the best way to invest my time. Grinding leetcode and studying system design can get me into a big company that pays very well, almost 5 times more than what I make currently. Learning about JS, the web in general, the cloud can be used in my day job, and can allow me to easily spin up my own product. Learning about technical writing and blogging can increase the value of my "personal brand". Learning about people and how to navigate an organization will be useful wherever I am. Contributing to open source can also help my "personal brand", and it gives me a sense of accomplishment. And that's only for the "work" part of my life. I don't think Emacs and/or Vim are a good investment compared to those other things.
On the other hand, I know that a lot of people use them, and like them, and I respect that. If I could take a pill to instantly know how to use efficiently one of them, I would. But right now, they're far from a priority.
For what it's worth, Neovim has at least 3 solid open-source GUI frontends, a closed-source full-fledged IDE, and at least 2 more experimental open-source ones.
And your guess about LSP is exactly why I think Swank not having a protocol is such a problem. It discourages entry and expansion.
Ah yes, the last 3-4 generations of programmers that have lived and died out in only 8 years. Behold the most popular editor chosen by 1366 programmers on HN in 2012 https://news.ycombinator.com/item?id=3717754 is none other than vim.
Sure, basically no one uses vi. vim is not vi.
There is an LSP backend for Common Lisp (two actually if memory serves) that probably just wraps the venerable Swank, but I haven't tried it. I like vim + slimv + all my other plugins.
I agree with your list, except for what I feel is the implicit argument behind:
> Editing s-expressions efficiently requires special tooling.
In the interest of clarity to non-lispers: without Paredit/Parinfer, editing S-expression is an experience equivalent to writing C++/Java - you roughly have that many delimiters to deal with when structuring code. Paredit/Parinfer make this process much more efficient than you can reasonably do for Algol-like languages, because of the inherent simplicity of S-expression structure.
I think that for most people, s-expressions are harder to deal with than curly braces and begin/end.
1. Non-Lisp languages have fewer braces in general due to the presence of non-expression "statements" and infix operators, while in Lisp nearly everything is an s-expression. Common Lisp in particular has a lot of double parens, so even a garden-variety LET form already has _three_ levels of parens, or four when you have a function call involved:
(let ((x (foo :a 1 :b 2)))
(princ x))
2. Indentation and spacing conventions in non-Lisp languages generally make it easier to spot unbalanced braces, while Lisp indentation and spacing conventions are specifically designed to make the braces "disappear".
3. Non-Lisp languages have a wider variety of delimiters, which can help visually distinguish groups of delimiters in . Common Lisp and Scheme almost exlusively use parens (). Clojure has more variety in this area, and I have no doubt that this was a deliberate design distinction.
4. Lisp and Scheme tend to be more functional, and discourage things like early returns, often leading to deeper nesting in the syntax tree and therefore a larger number of parens to juggle. Many other popular functional languages generally use as few parens as possible, almost entirely eschewing their traditional purpose for function calls, so they don't share this problem.
The combined effect of these differences makes editing non-trivial Lisp code a bit tiring and slow/difficult for someone who isn't already very comfortable doing it without the editor support. That's a serious deterrent for would-be newbies, who could go try any one of 1000 other interesting good-quality languages out there.
Being forced to use _Emacs or Vim/Neovim_ of all things is a huge compounding factor. At that point, they'd be better off even with Clojure, which at least has excellent support in VSCode (via Calva https://marketplace.visualstudio.com/items?itemName=betterth...).
C-like curly brace pseudocode:
function pythag2(a, b) {
if (a <= 0 || b <= 0) {
throw MathDomainException("Sides of a right triangle must be positive in length.")
}
const aSquared = pow(a, 2)
const bSquared = pow(b, 2)
return sqrt(aSquared + bSquared)
}
Algol/Pascal-like begin/end pseudocode:
function pythag2(a, b)
if a <= 0 or b <= 0 do
raise MathDomainException.new("Sides of a right triangle must be positive in length.")
end
const aSquared = pow(a, 2)
const bSquared = pow(b, 2)
return sqrt(aSquared + bSquared)
end
Haskell/ML-like pseudocode:
square = pow 2
pythag2 a b =
if a <= 0 || b <= 0
then (MkMathDomainError "Sides of a right triangle must be positive in length.")
else
let aSquared = square x
bSquared = square x
in sqrt (aSquared + bSquared)
Lisp-like pseudocode:
(defun pythag2 (a b)
(if (or (<= a 0) (<= b 0))
(error 'math-domain-error
:message "Sides of a right triangle must be positive in length.")
(let ((a-squared (pow 2 x))
(b-squared (pow 2 x)))
(sqrt (+ a-squared b-squared)))))
When writing this, the _only_ one that I had to stop and really think about was the Lisp one. With Parinfer, the parentheses completely disappear and I can code at the speed of thought, and I have the sublime Lisp experience that everyone talks about. But without it, I had to somewhat-carefully construct the "skeleton" of the IF and LET forms, and I had to literally count the parens at the end to make sure I did it right.
Moreover, I would bet good money that for most inexperienced programmers, the Lisp version would be the hardest to read.
Honestly, I've written a fair amount of Lisp, and sometimes Lisp-like languages (e.g. GCC RTL), and never felt the need for either paredit or parinfer, and virtually never use structural navigation either.
Somehow the assisted indentation in Emacs is enough that I've never been confused about parentheses or felt the need to have them typed for me. I find them visually clear, so long as the indentation is not misleading.
I do find the close-paren matching which lets me know when a mismatching parenthesis is typed quite useful though. I use that in all programming languages, sometimes to tell me where a long block begins.
So I wouldn't agree that paredit or parinfer are essential.
For me, the fastest available cursor key repeat rate is more essential. I code like it's a video game: Hold down cursor key, let go when it lands in the right place. Write what I need, newlines and all, use <tab> or C-M-q a few times to trigger automatic indentation as needed. But this applies to all languages, not just Lisp.
I was exactly there, after experimenting with someone else's CommonLisp and being amazed at how fast and concise the code was.
Result: learned emacs. I have to say I don't regret a second of the weeks it took me to fully grasp it :D highly recommend going down the rabbit hole.
I would recommend perhaps to start with Spacemacs though: everything is ready to do the job: just install the "layer" you want, in this case, Lisp, and you're set... if you don't like Vim just make sure to not choose "evil-mode" (Vim bindings on emacs) as I think that's what you get by default.
> Convincing people that they could & should use Lisp instead of Python or Swift is facing stumbling blocks far, far larger than the user-experience in an editor/IDE.
It is a perennial complaint among those learning lisp that they didn't want to have to learn a new editor too. It's certainly possible that lots of other hurdles keep people from ever getting far enough to complain, but given that growth begets growth, fixing any hurdle would potentially have outsized gains.
That's almost the last line of the article, but it hasn't established any credible argument about why "they really are not in 2021" other than a much longer form of the same assertion.
> Summary: You have to get in there and compete with mainstream, play their game by their rules, if you want to compete.
1. Why does someone want to "compete" ?
2. What would you be competing with?
Convincing people that they could & should use Lisp instead of Python or Swift is facing stumbling blocks far, far larger than the user-experience in an editor/IDE.