←back to thread

Lisp from Nothing, Second Edition

(t3x.org)
366 points nils-m-holm | 1 comments | 27 Aug 25 09:50 UTC | HN request time: 0s | source
Show context
nils-m-holm ◴[27 Aug 25 09:50 UTC] No.45037420[source]▶
Second edition, with a new chapter on lambda calculus.
replies(1): >>45067854 #
gritzko ◴[29 Aug 25 18:41 UTC] No.45067854[source]▶
Thanks. I recently had to reinvent LISP to script my CRDT database. That was not much work, because I already had the notation (I use RDX, a JSON superset with CRDT types). Still, I stumbled at the idiosyncratic LISP bracketing. Luckily, RDX allows for different tuple notations. So, I styled it to look less alien to a curly-braced developer. Like this https://github.com/gritzko/go-rdx/blob/main/test/13-getput.j...

For example, print change-dir make-dir; is equivalent to (print (change-dir (make-dir) ) ) in the old money. I wonder if I am reinventing too much here.

Did LISPers try to get rid of the brackets in the past?

replies(6): >>45068004 #>>45068097 #>>45068164 #>>45068705 #>>45069136 #>>45069145 #
jbritton ◴[29 Aug 25 20:39 UTC] No.45069136[source]▶
I sometimes wonder if the issue is really the parentheses or the ease of nesting. In LISP it’s natural to write (f (g (h x))). Whereas most people are used to. a = h(x); b = g(a); c = f(b);

In C/C++ most functions return error codes, forcing the latter form.

And then there are functional languages allowing: x -> h -> g -> f but I think the implicit parameter passing doesn’t sit well with a lot of programmers either.

replies(1): >>45069930 #
1. jrapdx3 ◴[29 Aug 25 22:02 UTC] No.45069930[source]▶
Interesting comment. I found the lisp/sexpr form instantly understandable. While the others weren't hard to grasp it took a moment to consciously parse them before their meaning was as clear. Perhaps the functional arrow notation is least appreciated because it's seems more abstract or maybe the arrows are just confusing.

More likely than not it's a matter of what a person gets used to. I've enjoyed working in Lisp/Scheme and C, but not so much in primarily functional languages. No doubt programmers have varied histories that explain their preferences.

As you imply, in C one could write nested functions as f (g (h (x))) if examining return values is unnecessary. OTOH in Lisp return values are also often needed, prompting use of (let ...) forms, etc., which can make function nesting unclear. In reality programming languages are all guilty of potential obscurity. We just develop a taste for what flavor of obscurity we prefer to work with.