Hacker News Reader

Comment by wavegeek | Hacker News Reader

> s-expressions are kind of hard to read and reason about for my brain

I think it's likely this is just a matter of familiarity.

Like the way that people think the Windows (/ whatever) GUI is intuitive - but when you test this by putting someone who has never used it in front of a screen, it actually isn't. "What do you mean if I write something and don't also 'save' it, whatever that is, it will disappear? This is supposed to be better than paper...".

The text editor handles indenting and matching. After a while it is completely transparent.

View on HN

Maybe the last sentence needs a bit expanding, I think most readers already use a powerful text editor and don't see how standard features would help with lisp. The thing is, you don't really edit Lisp as text. Two commonly used extensions (for emacs, vim, vscode, sublime...) are paredit and rainbow. Those extensions kick in when lisp code is detected.

It then feels more like tree manipulation than like writing code. Braces are always matched, you literally cannot delete the closing brace using normal text editing. Each tree depth as its own brace color so it's easy to distinguish between them.

Restructuring tree to join two blocks of code or to extract block to higher level is exposed as command mapped to keyboard shortcut. It's not semantic editing in sense that extension is aware what is function and what is data, you can still make nonsense code. Still, reading and manipulating code is quite effortless.

> Two commonly used extensions (for emacs, vim, vscode, sublime...) are paredit and rainbow.

In Emacs, you may find Lispy and Prism even better.

I have learned scheme before camllight (the ancestor of ocaml). The syntax was a pleasure compared to scheme.

That becomes a no true Scotsman fallacy though. People argue "Either you like lisp syntax or you haven't used it enough to have a valid opinion". That is a bullshit argument.

It is and it isn't :)

Obviously opinions on the language shouldn't be given too much weight if a person hasn't spent too much time investigating/ using it.

As a non-JavaScript person, all the JavaScript examples looks like gobbledygook unless I sit down and consciously think about what the examples are showing, and it kinda hurts my head a bit, but I can slowly force myself through it.

But as someone with a few years of lisp under my belt, even the closure examples (and I've never used clojure) parse pretty close the speed of thought.

It really is hard to explain to someone who hasn't used lisp for 6-12 months, but there really is a lisp "enlightenment" experience, which is totally unlike anything I've experienced with any of my other languages. I'm not saying this makes it better or worse than other languages, but I am saying it's real, and that lisp code is not only parsable, but exceptionally so to an experienced lisp programmer. One day you're sitting there thinking there's a whole lot of brackets, balancing and indentation in this godforsaken language, and then something just clicks over in your brain and you don't even see the brackets any more and it's all just data structure, and you see the shape of it, and you say to yourself "well that was pretty fucking cool" and from that day on you don't really see the brackets any more, it's all just names, indentation and data structures.

edit: and it should also be recognised that an editor implementing parentheses balancing, indentation options, and keyword lookup/ completion also becomes a relatively trivial exercise when your code consists of variable names and structured data.

> and then something just clicks over in your brain and you don't even see the brackets any more

In my experience, the Lisp enlightenment comes in stages, two big ones are 1) s-expression parsing you describe here, and 2) grokking "code is data".

WRT. s-expressions enlightenment, I vividly remember when it happened to me. Few months into learning Lisp, I bought a hardcover SICP and, for some reason, decided to do exercises in it on paper. Few exercises in, as I was writing Lisp code with a pen in hand, suddenly something clicked in my head - like my brain JIT-compiled a new processing module - and from then on, I no longer needed to mentally count or track the parens. I just knew how many and where they were, it dropped to semiconscious level. Ever since, I'm very comfortable with s-expressions; in fact, I prefer them as a notation to Algol/C-like code.

I’ve literally seen first-hand GJS lose track of paren matching while lecturing on Sceme/SICP. It happens very rarely sure, but certainly not never. Probably about as often as experts in any other language/profession make silly mistakes. Perhaps you’re a better schemster than him, but I have my doubts :)

I think no matter the language the syntax will disappear over time and your brain will learn to look at the character matrix and directly see logical constructs, moreover this will always apply cross-language to other languages with similar syntax. Fit example, I primarily work in TS, I have decent amount of experience in other C-style, and to me Rust is easily readable with very little experience actually using it.

I'm not sure who GJS is but if you see any lisper editing text instead of operating on structures (with auto-balancing parenthesis and so on), it's 99% certain it's in an environment they are not familiar with, so they will make mistakes.

I don't think anyone who write Lisp-like languages professionally doesn't use tools like parinfer/paraedit, where balancing parenthesis is not something you have to do.

This was on a blackboard. And GJS advised Guy Steele in creating Scheme and coauthored SICP with him.

Yup, makes sense that you make mistakes then, as these folks are surely used to not having to think about balancing parenthesis anymore. Just as over-reliance on GPS will make your navigation skills without a GPS worse over time.

> coauthored SICP with him

Not with him.

I'm pretty sure there are people who write common lisp professionally whithout those tools. Are they even available in the LispWorks or ACL editors?

While specifically parinfer and/or paraedit might not be available in neither LispWorks or ACL editors, they surely have something there to aid with parenthesis.

But I might be wrong here, it's simply hard for me to imagine someone writing with lisps professionally going the route of textual editing when structural editing is right there.

Something, but probably not as much as you think:

http://www.lispworks.com/documentation/lw71/EDUG-M/html/edus...

>I'm not sure who GJS is…

Gerald Jay Sussman

Hey :)

You wrote a really nice comment ages ago, which partly inspired me to learn lisp and also it’s formatting.

I still want clean it up a fair bit, but here’s the draft article:

https://ashokkhanna-530.medium.com/formatting-lisp-5e28020b8...

Hope it’s okay to use your quote! And if not, I’ll take it down

perfectly ok from me, honestly I'm flattered :)

I'd just use parinfer/paredit and forget about the whole formatting 90% of the time.

I think it's like a language family thing. If your familiar with a C-language (or more accurately, AGOL style) then looking at other C-languages isn't as alien to you. While looking at a LISP family language, it's a different language branch and so you have to learn some new ways of thinking, which can be disorienting.

Ex french & english vs french & indonesian. English and french can recognize words from each other and kind of see some similar grammar rules (the medicine vs. la médecine) while with indonesian those moments are not as frequent.

Reply on news.ycombinator.com