Hacker News Reader

Comment by city41 | Hacker News Reader

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.

View on HN

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.

Strike against all those "Lisp makes you a better programmer" arguments?

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.

>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?

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)

More like a strike against other languages for not having the same editing tools.

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.

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.

Sure, its just more useful when your languages syntax revolves around parentheses.

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) + 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 these in combination with expand/shrink-region operations are a significant productivity boost, which is easy to learn and teach.

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.

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.

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.

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.

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.

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.

Oh ya, Emacs default movements aren't great for more line oriented syntaxes, even for s-expressions I have customized things a lot more to my liking and smartparens isn't part of default Emacs either. I don't think Emacs really expect you to stick to defaults, the whole editor is designed to be customized.

When I edit the non s-expressions languages I mentioned I do it in IntelliJ, sometimes with the vim bindings.

In my experience, it's not about being line-oriented. It's about being punctuation heavy or not. Lisp, except parens, for the most part doesn't have all that much punctuation (quotes and commas are rare). Now let's take this program in C++:

  #include <iostream>
  
  int main() {
      std::cout << "hello, world!" << std::endl;
  }

If my cursor is after "main", then M-f will move my cursor to after "std". It completely ignored "()" and "{". Another M-f moves my cursor to after "cout". Here it ignored "::". Another M-f moves the cursor to after "hello" ("<<" and the quote-mark ignored), another to after "world", and another to after "std" (quote-mark and "::" ignored) etc. It behaves similarly when hitting C-Backspace, where sometimes half a line disappears suddenly, because it was punctuation-heavy. I think once I stumbled upon code where it deleted several lines. On the other hand, when I have a variable like "big_number", then Emacs will happily jump into the middle of it. Even though it's an indivisible token in the eyes of the language's lexer. Of course there is a well-known hack of adding the "_" character to be recognised as a "word character". But it doesn't solve the issue really. The issue is that forward-word uses just one set of word-characters, instead of several sets of characters/regexes for different syntactic categories, which would enable jumping first to "cout" and then to "<<".

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++ ;)

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.

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

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

The repo is archived. Last commit is 2 years ago. Is the project completed, or abandoned?

Both, most editors have their own implementation though, this repo is more a demonstration on the idea around the UX.

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

The Rust implementation is also popular and actively maintained: https://github.com/eraserhd/parinfer-rust

I’m using lispy[1] instead of paredit and absolutely happy about it.

[1]: https://github.com/abo-abo/lispy

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.

Reply on news.ycombinator.com