4 ms·

To not go absolutely insane with Lisps, you need some kind of parentheses tool with your editor such as ParEdit. The up side is once you get used to your tool,

by city41 6y ago

To not go absolutely insane with Lisps, you need some kind of parentheses tool with your editor such as ParEdit. The up side is once you get used to your tool, you can do really cool things and navigate/change code in higher level ways. But the massive downside (in my experience), is convincing coworkers to adopt a Lisp is practically impossible. The language itself being so foreign, and when they ask about the parentheses bringing up a tool they need to learn on top of the language is a double whammy.

deleted 6y ago
[deleted]
jwr 6y ago
While I would agree that paredit in Emacs is fantastic, the real shock comes when you have to go back to editing code in those languages that have the weird arbitrary punctuation. I mean, your editor can't even properly manipulate those expressions most of the time. In order not to go absolutely insane when dealing with JavaScript, C++, Java, you need absolutely top-notch editor support, and even then you can't do everything that paredit does. This gets even worse with languages where indentation matters (Python, and the horrible abomination that is YAML) — which aren't even auto-indentable, because the editor has no idea what you actually mean. I'm not sure if you can avoid going insane with those.
- mbrodersen 6y ago
  I am a bit puzzled reading this. I have programmed in C++ for 20+ years and (as far as I know) am still fairly sane. I also have never met or heard about anybody programming in C++ who lost their mind programming C++ ;)
- jb1991 6y ago
  This is a common argument, but I think your mileage may vary. I had a Clojure job for many years, and it was the only thing I wrote in that time. When I moved to a different job in a more conventional language, I also had that initial frustration from the syntax context switch in my head. But it was very short-lived. Now I find that there’s really no such frustration, it’s just a different way of writing code, going from either direction to the other requires some getting used to it.
  - didibus 6y ago
    I think you might have just got used to it, but it's definitely worse. My job involves consistent writing of 50% Clojure, 40% Java, 3% Kotlin, 3% Scala and another 3% of others (Python, Javascript, HTML, SQL, etc.). And so as I actively code in both Lisp and Algol syntaxes (and wtv Python is), I definitely always miss my structural navigation and editing features in the non-Lisp languages. So I'm guessing you kind of just forgot how nice it is. Having said that, there's some disadvantages to the Lisp syntax as well, rightward drift due to constant nesting is real, and can make readability and even some edits a lot more annoying, whereas the flatter structure of other syntaxes doesn't have this problem as much. I still find its pros outweighs the cons personally, but your mileage may vary.
    - jb1991 6y ago
      Nah, the benefits of structural editing can be nice, but so too are the benefits of a great line-by-line editing workflow ala vim, which makes one just as productive, regardless of language. And I think that a job where you have to constantly switch between lisp and non-lisp styles would be a lot more frustrating than just using only one style and getting used to it, so I can see your pain there.
    - marcosdumay 6y ago
      My experience is that I agree that a standard punctuation is easier to write, but it's harder to get a big picture from it than non-standard. Anyway, it's way harder to adapt to "parenthesis before the function name vs parenthesis after the function name" and "semicolons after every statement vs. never use semicolons" than "punctuation is all parenthesis and commas (or newline and space as in normal Haskell) vs. punctuation uses the entire keyboard". Meaningful vs meaningless indentation is also one of the things that don't give me any problems at all to adapt.
    - yakubin 6y ago
      I find that the default movement commands in Emacs match Lisp syntax pretty well (although paredit is much better still, when quotes and commas are involved e.g.), but when I switch to C++, they're infuriating. Since I'm editing code written in a programming language and not text written in a natural language the forward-word command can often jump over an entire line worth of C++ tokens, and sometimes it jumps into the middle of a token. This mismatch is really tiresome. Vim commands usually hit closer to the "move by token" motivation, even though it's still just regular expressions. And so editing in it is a breeze (but then it has other disadvantages that deter me from it). Overall, I don't think you need the full power of paredit when programming. For any given language, your editor movement commands understanding what tokens in this language look like will usually already be sweet and enough.
- Igelau 6y ago
  Strike against all those "Lisp makes you a better programmer" arguments?
  - p_l 6y ago
    Not really, it's not lisp's fault that you have to carefully count parens in modern JavaScript without the tools that make it easy in Lisp, same with nonsensical indentation in Python (miss one space and watch the program explode in worst possible moment). What Lisp helps you is grokking actual operations of computing and, especially when all you have is a really dumbed down algol, opens you up to more programming methods and techniques. All of that happens on layer high above syntax.
    - dmux 6y ago
      >What Lisp helps you is grokking actual operations of computing Computing in the theoretical sense, right? I've always heard the opposite of this claim: Lisp abstracts away how computation is done on actual hardware. Isn't that what the famous Alan Perlis quote was referring to?
      - p_l 6y ago
        I'd say both, though low-level is more specific to compiled Common Lisp implementations rather than general for all of lisp family. Specifically, ANSI Common Lisp is equipped with a function called DISASSEMBLE, and on many implementations it will provide you not only with plain assembly dump, but also with comments regarding said assembly, for example a comment specifying "we're calling X here", "this is handler for single parameter, and this is for multiple parameters" (in case of optional arguments to function)
  - dkersten 6y ago
    More like a strike against other languages for not having the same editing tools.
- city41 6y ago
  I agree with you and I really enjoy the flow you can get into with s-expressions. But in my experience this frustration is typically viewed as very different and foreign from the frustration more mainstream languages bring. I think one reason is the mainstream frustrations have a lot of similarities. Wrangling blocks in C like languages and even languages like Python and Ruby have a lot of similarities, where as in a lisp it's just completely different.
- fiddlerwoaroof 6y ago
  Paredit (smartparens, actually) works semi-decently in almost every language I’ve tried: there are quirks that have to be worked around, but splicing/slurping/etc. are a lot more convenient than the alternatives.
  - dkersten 6y ago
    Sure, its just more useful when your languages syntax revolves around parentheses.
- onetom 6y ago
  You can get quite close to "AST editing"-like experience if you just use the expand/shrink selection feature of a JetBrains IDE. It supports most mainstream languages. You just select a syntactic unit with opt-up/down, then u either type over it, copy/cut/past or press left or right to go to the beginning or the end of the selection, hence using the selection as an intermediate step achieving AST-level navigation. And of course you can teach Emacs to behave similarly, using the Expand Region (https://wikemacs.org/wiki/Expand_region https://wikemacs.org/wiki/Expand_region) + some hacks, but I agree, that smartparens also solves this problem quite well. UPDATE: also use avy-jump for emacs or acejump for intellij: https://plugins.jetbrains.com/plugin/7086-acejump https://plugins.jetbrains.com/plugin/7086-acejump these in combination with expand/shrink-region operations are a significant productivity boost, which is easy to learn and teach.
- ojnabieoot 6y ago
  You can do indentation with the same semantic rigor as parentheses - the problem with Python is less that it’s whitespace-significant and more that it’s procedure-based rather than expression-based. Parenthesis might mitigate this somewhat to the human eye (at the cost of some clutter and compromised immediacy), but unlike a LISP the Python interpreter doesn’t really understand what an expression is. By contrast, I never have these kinds of semantic issues in whitespace significant languages like F# - I make mistakes that I might make less often in Scheme, but the compiler usually sets me straight since it realizes a branch isn’t returning a value, etc. In my view parentheses versus whitespace is really a judgment call based on how your eyes read the source code. The crucial thing is having something like s-expressions.
dgb23 6y ago
The interesting thing is that Lisp syntax editing mechanics scale. There are more “moves” that you can do with a Lisp, especially if most your code is also functional. My approach: learn 2-4 navigational moves first for a while. Then add more nav and editing moves at a later point. As with everything: deliberate practice leads to mastery. At some point it becomes apparent that the weird syntax is a feature that has huge upsides (another one being macros for example).
agumonkey 6y ago
Yes, I'm a solid lisp fan, but anytime I have to edit lisp without paredit I die. Now paredit has been around for decades (1991 ? I forgot) so it's not like it's rarity. Now that said, a little bit of paredit-fu allows for some funky coding sessions.. you can swap sexps, move blocks up down the tree .. you can even process the sexp with some elisp code in emacs.. it's very very swift. What annoys me is the people who never expanded their knowledge beside a few paradigm .. they'll stick with python only or js .. or cpp. They're stuck onto a few libs and syntax.. it's a pity.
vikeri 6y ago
I use paredit myself but I also think that parinfer is very interesting: https://shaunlebron.github.io/parinfer/ https://shaunlebron.github.io/parinfer/
- jgalt212 6y ago
  The repo is archived. Last commit is 2 years ago. Is the project completed, or abandoned?
  - chrisoakman 6y ago
    The Parinfer core algorithm is mostly "complete", with the remaining work being various editor integrations (which can be quite tricky). I maintain an up-to-date fork of Parinfer JS here: https://github.com/oakmac/parinfer https://github.com/oakmac/parinfer The Rust implementation is also popular and actively maintained: https://github.com/eraserhd/parinfer-rust https://github.com/eraserhd/parinfer-rust
  - didibus 6y ago
    Both, most editors have their own implementation though, this repo is more a demonstration on the idea around the UX.
schmooser 6y ago
I’m using lispy[1] instead of paredit and absolutely happy about it. [1]: https://github.com/abo-abo/lispy https://github.com/abo-abo/lispy
kmstout 6y ago
ParEdit's nice, especially when combined with mark-sexpr (C-M-Spc) and narrow-to-region (C-x n n). Somewhere out there is a smattering of Elisp for gracefully handling recursive narrowing.

by city41 6y ago

deleted 6y ago

[deleted]

jwr 6y ago

While I would agree that paredit in Emacs is fantastic, the real shock comes when you have to go back to editing code in those languages that have the weird arbitrary punctuation. I mean, your editor can't even properly manipulate those expressions most of the time. In order not to go absolutely insane when dealing with JavaScript, C++, Java, you need absolutely top-notch editor support, and even then you can't do everything that paredit does. This gets even worse with languages where indentation matters (Python, and the horrible abomination that is YAML) — which aren't even auto-indentable, because the editor has no idea what you actually mean. I'm not sure if you can avoid going insane with those.

mbrodersen 6y ago
I am a bit puzzled reading this. I have programmed in C++ for 20+ years and (as far as I know) am still fairly sane. I also have never met or heard about anybody programming in C++ who lost their mind programming C++ ;)
jb1991 6y ago
This is a common argument, but I think your mileage may vary. I had a Clojure job for many years, and it was the only thing I wrote in that time. When I moved to a different job in a more conventional language, I also had that initial frustration from the syntax context switch in my head. But it was very short-lived. Now I find that there’s really no such frustration, it’s just a different way of writing code, going from either direction to the other requires some getting used to it.
- didibus 6y ago
  I think you might have just got used to it, but it's definitely worse. My job involves consistent writing of 50% Clojure, 40% Java, 3% Kotlin, 3% Scala and another 3% of others (Python, Javascript, HTML, SQL, etc.). And so as I actively code in both Lisp and Algol syntaxes (and wtv Python is), I definitely always miss my structural navigation and editing features in the non-Lisp languages. So I'm guessing you kind of just forgot how nice it is. Having said that, there's some disadvantages to the Lisp syntax as well, rightward drift due to constant nesting is real, and can make readability and even some edits a lot more annoying, whereas the flatter structure of other syntaxes doesn't have this problem as much. I still find its pros outweighs the cons personally, but your mileage may vary.
  - jb1991 6y ago
    Nah, the benefits of structural editing can be nice, but so too are the benefits of a great line-by-line editing workflow ala vim, which makes one just as productive, regardless of language. And I think that a job where you have to constantly switch between lisp and non-lisp styles would be a lot more frustrating than just using only one style and getting used to it, so I can see your pain there.
  - marcosdumay 6y ago
    My experience is that I agree that a standard punctuation is easier to write, but it's harder to get a big picture from it than non-standard. Anyway, it's way harder to adapt to "parenthesis before the function name vs parenthesis after the function name" and "semicolons after every statement vs. never use semicolons" than "punctuation is all parenthesis and commas (or newline and space as in normal Haskell) vs. punctuation uses the entire keyboard". Meaningful vs meaningless indentation is also one of the things that don't give me any problems at all to adapt.
  - yakubin 6y ago
    I find that the default movement commands in Emacs match Lisp syntax pretty well (although paredit is much better still, when quotes and commas are involved e.g.), but when I switch to C++, they're infuriating. Since I'm editing code written in a programming language and not text written in a natural language the forward-word command can often jump over an entire line worth of C++ tokens, and sometimes it jumps into the middle of a token. This mismatch is really tiresome. Vim commands usually hit closer to the "move by token" motivation, even though it's still just regular expressions. And so editing in it is a breeze (but then it has other disadvantages that deter me from it). Overall, I don't think you need the full power of paredit when programming. For any given language, your editor movement commands understanding what tokens in this language look like will usually already be sweet and enough.
Igelau 6y ago
Strike against all those "Lisp makes you a better programmer" arguments?
- p_l 6y ago
  Not really, it's not lisp's fault that you have to carefully count parens in modern JavaScript without the tools that make it easy in Lisp, same with nonsensical indentation in Python (miss one space and watch the program explode in worst possible moment). What Lisp helps you is grokking actual operations of computing and, especially when all you have is a really dumbed down algol, opens you up to more programming methods and techniques. All of that happens on layer high above syntax.
  - dmux 6y ago
    >What Lisp helps you is grokking actual operations of computing Computing in the theoretical sense, right? I've always heard the opposite of this claim: Lisp abstracts away how computation is done on actual hardware. Isn't that what the famous Alan Perlis quote was referring to?
    - p_l 6y ago
      I'd say both, though low-level is more specific to compiled Common Lisp implementations rather than general for all of lisp family. Specifically, ANSI Common Lisp is equipped with a function called DISASSEMBLE, and on many implementations it will provide you not only with plain assembly dump, but also with comments regarding said assembly, for example a comment specifying "we're calling X here", "this is handler for single parameter, and this is for multiple parameters" (in case of optional arguments to function)
- dkersten 6y ago
  More like a strike against other languages for not having the same editing tools.
city41 6y ago
I agree with you and I really enjoy the flow you can get into with s-expressions. But in my experience this frustration is typically viewed as very different and foreign from the frustration more mainstream languages bring. I think one reason is the mainstream frustrations have a lot of similarities. Wrangling blocks in C like languages and even languages like Python and Ruby have a lot of similarities, where as in a lisp it's just completely different.
fiddlerwoaroof 6y ago
Paredit (smartparens, actually) works semi-decently in almost every language I’ve tried: there are quirks that have to be worked around, but splicing/slurping/etc. are a lot more convenient than the alternatives.
- dkersten 6y ago
  Sure, its just more useful when your languages syntax revolves around parentheses.
onetom 6y ago
You can get quite close to "AST editing"-like experience if you just use the expand/shrink selection feature of a JetBrains IDE. It supports most mainstream languages. You just select a syntactic unit with opt-up/down, then u either type over it, copy/cut/past or press left or right to go to the beginning or the end of the selection, hence using the selection as an intermediate step achieving AST-level navigation. And of course you can teach Emacs to behave similarly, using the Expand Region (https://wikemacs.org/wiki/Expand_region https://wikemacs.org/wiki/Expand_region) + some hacks, but I agree, that smartparens also solves this problem quite well. UPDATE: also use avy-jump for emacs or acejump for intellij: https://plugins.jetbrains.com/plugin/7086-acejump https://plugins.jetbrains.com/plugin/7086-acejump these in combination with expand/shrink-region operations are a significant productivity boost, which is easy to learn and teach.
ojnabieoot 6y ago
You can do indentation with the same semantic rigor as parentheses - the problem with Python is less that it’s whitespace-significant and more that it’s procedure-based rather than expression-based. Parenthesis might mitigate this somewhat to the human eye (at the cost of some clutter and compromised immediacy), but unlike a LISP the Python interpreter doesn’t really understand what an expression is. By contrast, I never have these kinds of semantic issues in whitespace significant languages like F# - I make mistakes that I might make less often in Scheme, but the compiler usually sets me straight since it realizes a branch isn’t returning a value, etc. In my view parentheses versus whitespace is really a judgment call based on how your eyes read the source code. The crucial thing is having something like s-expressions.

dgb23 6y ago

The interesting thing is that Lisp syntax editing mechanics scale. There are more “moves” that you can do with a Lisp, especially if most your code is also functional. My approach: learn 2-4 navigational moves first for a while. Then add more nav and editing moves at a later point. As with everything: deliberate practice leads to mastery. At some point it becomes apparent that the weird syntax is a feature that has huge upsides (another one being macros for example).

agumonkey 6y ago

Yes, I'm a solid lisp fan, but anytime I have to edit lisp without paredit I die. Now paredit has been around for decades (1991 ? I forgot) so it's not like it's rarity. Now that said, a little bit of paredit-fu allows for some funky coding sessions.. you can swap sexps, move blocks up down the tree .. you can even process the sexp with some elisp code in emacs.. it's very very swift. What annoys me is the people who never expanded their knowledge beside a few paradigm .. they'll stick with python only or js .. or cpp. They're stuck onto a few libs and syntax.. it's a pity.

vikeri 6y ago

I use paredit myself but I also think that parinfer is very interesting: https://shaunlebron.github.io/parinfer/ https://shaunlebron.github.io/parinfer/

jgalt212 6y ago
The repo is archived. Last commit is 2 years ago. Is the project completed, or abandoned?
- chrisoakman 6y ago
  The Parinfer core algorithm is mostly "complete", with the remaining work being various editor integrations (which can be quite tricky). I maintain an up-to-date fork of Parinfer JS here: https://github.com/oakmac/parinfer https://github.com/oakmac/parinfer The Rust implementation is also popular and actively maintained: https://github.com/eraserhd/parinfer-rust https://github.com/eraserhd/parinfer-rust
- didibus 6y ago
  Both, most editors have their own implementation though, this repo is more a demonstration on the idea around the UX.

schmooser 6y ago

I’m using lispy[1] instead of paredit and absolutely happy about it. [1]: https://github.com/abo-abo/lispy https://github.com/abo-abo/lispy

kmstout 6y ago

ParEdit's nice, especially when combined with mark-sexpr (C-M-Spc) and narrow-to-region (C-x n n). Somewhere out there is a smattering of Elisp for gracefully handling recursive narrowing.