Comment by evdubs | Hacker News Reader

Comment by evdubs | Hacker News Reader

Parent Full thread

> Because it's weird enough to be off-putting, and it doesn't solve a real-world problem.

Nonsense. Quoth Wikipedia, "Lisp pioneered many ideas in computer science, including tree data structures, automatic storage management, dynamic typing, conditionals, higher-order functions, recursion, the self-hosting compiler, and the read–eval–print loop." These are all solutions to real world problems.

So many languages borrow features that were originally developed in Lisp.

> However, this flexibility is also a massive footgun: if you're not careful your junior developer might end up reinventing the wheel a dozen times, and writing completely unmaintainable code in the process.

Plenty of code written in Lisp looks just like your Python, Ruby, JavaScript, Java, et al programs where you're defining structures or classes, writing and calling functions, importing useful libraries, etc. Plenty of this Lisp code is just as maintainable as the non-S-expression code.

> Anyone who knows C# will be able to pick up a basic understanding of C, Python, or JavaScript well within a day

Same with Lisp. It's just:

(function arg1 arg2)

Instead of

function(arg1, arg2)

> You want code which is quick and easy to write, trivial to read, and understandable by even the worst programmer in your company.

There is plenty of "lowest common denominator" code like this written in Lisp. Much Lisp code is not buried under inscrutable macros, just like not all Java code is buried under layers of inscrutable classes.

> (function arg1 arg2) > > Instead of > > function(arg1, arg2)

That isn't the problem of learning Lisp. The problem with learning Lisp is

   (`a ,b c)

and the infinite power thus infinite responsibility of the wizard programmer.

> There is plenty of "lowest common denominator" code like this written in Lisp. Much Lisp code is not buried under inscrutable macros, just like not all Java code is buried under layers of inscrutable classes.

But the problem remains: it only takes one wizard to make reading code impossible by outsiders.

The canonical way to write a Lisp system is to define a DSL (or, should I say, system-specific language) and implement the system in that. But this means no-one outside of the language/system developers know the language, this means Lisp tends to be write-only by design - not in the line-noise meaning, but in the obscure foreign language meaning.

You certainly can not do that, but if you choose to not do that, why pick Lisp? You can argue that all software systems develop their internal system-specific languages, and I agree - but the overall strict language provides a rigid framework for anchoring understanding, something you have to conciously work for with Lisp. (Note Java pre-2020 was so limited in expressivity it wasn't any better, because all the complexity ended up in the class hierarchies you reference - it was more similar to Lisp in that way than many realize.)

> it only takes one wizard to make reading code impossible by outsiders.

One Java architect can make the code unreadable, even for himself.

> canonical way to write a Lisp system is to define a DSL

It's popular, but not canonical. But even those DSL language patterns can be learned. In many non-Lisp projects, the DSL gets implemented in C/C++.

> One Java architect can make the code unreadable, even for himself.

I agree, even in my original post.

> But even those DSL language patterns can be learned. In many non-Lisp projects, the DSL gets implemented in C/C++.

The friction is everything, otherwise we'd all be programming Turing machines. In Lisp, it is zero, by design; it can be good or bad, as most things in engineering. Consequences of uncontrolled growth of a DSL vs imposing artificial process limitations for the future of the software project must be considered explicitly; this is automatic when the cost of starting a DSL is non-zero.

> The canonical way to write a Lisp system is to define a DSL

That's just a subtle lie popularized by Paul Graham in "Beating The Averages".

> The problem with learning Lisp is `(a ,b c)

If you can understand "String ${interpolation}", you can understand list quasiquoting.

> But the problem remains: it only takes one wizard to make reading code impossible by outsiders.

This really is a Lisp meme. There are plenty of Lisp wizards like Guy Steele, Rich Hickey, and Matthew Flatt. The wizards perform the magical act of making code legible and intelligible. I have stumbled around several Clojure and Racket code bases and never felt like "I should understand this code but the features of Lisp make it impossible to know for sure." "Infinite power" macros and whatever are really only used sparingly and generally when it's impossible to achieve a goal otherwise. No one is doing (define + -).

> But this means no-one outside of the language/system developers know the language, this means Lisp tends to be write-only by design - not in the line-noise meaning, but in the obscure foreign language meaning.

I, as a Racket novice, have been able to add candlesticks [1] to the plot library without learning much about it. I have also debugged DrRacket (an IDE) to uncover that Racket GUI operations performed significantly worse if non-integer scaling was used [2]. At no point when I was going through Racket internal code did I ever feel it was write-only. In fact, it was quite convenient to modify Racket internal source code, rebuild, and test changes in a way that would be much more difficult in Java or C++.

> You certainly can not do that, but if you choose to not do that, why pick Lisp?

Built in rationals.

The ergonomics of defining [XML / JSON / etc] data as S-expressions and doing things like pattern matching on that data.

Great, coherent integration between GUIs, plots, statistics functions, and all the other bits of Racket's batteries inclusions.

You still have access to all the other great features that other languages have borrowed from Lisp like REPL development, package managers (edit: maybe package managers were not a Lisp invention), good IDE tools, etc.

It is nice to learn the meta-syntax of parentheses once and know that the code will always look like that. No need to consider if some feature is implemented as a syntactically different new keyword, annotation, function call, or whatever. It'll always be a (feature).

> something you have to conciously work for with Lisp.

Plenty of languages have style guides, linters, static analysis tools, etc. to make sure the code conforms to certain restrictions. Lisp feels no different in this regard.

[1] https://docs.racket-lang.org/plot/renderer2d.html#%28def._%2...

[2] https://github.com/racket/gui/commit/20e589c091998b0121505e2...

Reply on news.ycombinator.com