4 ms·

Emacs is a huge stumbling block for me. Everyone used emacs and expected you to as well. Common Lisp seems great - I'm so curious about CLOS - but I cannot get

Emacs is a huge stumbling block for me. Everyone used emacs and expected you to as well. Common Lisp seems great - I'm so curious about CLOS - but I cannot get along with emacs, and I have tried.

nerdponx 5y ago
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".
- TeMPOraL 5y ago
  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.
  - neutronicus 5y ago
    Specifically it's really easy to, like, decide all this code here should live in an if statement now, something I still find kind of hard to do in C++
  - nerdponx 5y ago
    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=betterthantomorrow.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.
pjmlp 5y ago
Here, https://franz.com/products/allegro-common-lisp/acl_ide.lhtml https://franz.com/products/allegro-common-lisp/acl_ide.lhtml http://www.lispworks.com/products/lispworks.html http://www.lispworks.com/products/lispworks.html Emacs is a subset of the whole experience.
- kamaal 5y ago
  Thanks. Just installed. Beautiful IDE. >>Emacs is a subset of the whole experience. Can you please elaborate on this? How is emacs a subset of this IDE?
  - pjmlp 5y ago
    Emacs is a subset of Lisp Machines developer experience.
deleted 5y ago
[deleted]
brabel 5y ago
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.

Emacs is a huge stumbling block for me. Everyone used emacs and expected you to as well. Common Lisp seems great - I'm so curious about CLOS - but I cannot get along with emacs, and I have tried.

nerdponx 5y ago

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".

TeMPOraL 5y ago
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.
- neutronicus 5y ago
  Specifically it's really easy to, like, decide all this code here should live in an if statement now, something I still find kind of hard to do in C++
- nerdponx 5y ago
  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=betterthantomorrow.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.

pjmlp 5y ago

Here, https://franz.com/products/allegro-common-lisp/acl_ide.lhtml https://franz.com/products/allegro-common-lisp/acl_ide.lhtml http://www.lispworks.com/products/lispworks.html http://www.lispworks.com/products/lispworks.html Emacs is a subset of the whole experience.

kamaal 5y ago
Thanks. Just installed. Beautiful IDE. >>Emacs is a subset of the whole experience. Can you please elaborate on this? How is emacs a subset of this IDE?
- pjmlp 5y ago
  Emacs is a subset of Lisp Machines developer experience.

deleted 5y ago

[deleted]

brabel 5y ago

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.