Hacker News Reader

Comment by zaro | Hacker News Reader

I get the code is data thing, but I don't really find it that much useful. And there is a good reason most languages don't allow it - other people :)

The unless example is a good one. So while you can trivially implement 'unless' in lisp, most probably in a large code base, you'll en up with 'unless', 'if-not' and depending on how creative others are probably also 'negat-if'.

View on HN

You have the same problem in any language when you start scaling up to larger team sizes (or multiple teams). If they don't bother reading the docs or existing libraries, they're likely to reinvent the wheel over and over. The solution is, unfortunately, more social than technical. You have to be deliberate in selecting what goes into the common libraries, and be deliberate in code reviews to make sure junk like that doesn't get created and widely used when an existing solution already exists.

Agreeing, I'd point out that C++ templates are Turing complete (and now they've added constinit and friends). That can certainly result in bad code, but it also enables very good code as well (ex the Eigen library). Python objects can be monkey patched at runtime - a powerful ability, but trivial to misuse.

Certainly the design of a language should facilitate and even actively encourage writing good code. Attempting to solve systemic organizational or educational issues with it is probably counterproductive though.

Since you mentioned the Eigen library: I'm sure it's an extremely elegantly designed library, and I know it's super powerful and efficient. But for someone like me, with fairly limited C++ experience, it was absolutely painful to learn and understand how to use it. Even though it's fairly well documented, I had to really dig through the sources whenever bugs arised. Understanding all these templating abstractions was a huge pain.

'unless vs 'if-not vs 'negat-if is "just" a naming issue, it's the same in any other language wrt functions. IME a bigger issue is jumping between code and data, both for the writer of the macro (viz macros to ensure that a form is evaluated at most once) and the user (is this thing a macro? Is this form going to be evaluated or quoted?).

The benefit is being able to extend the language. Context managers in Lisp are just macros. Clojure's spec and async are macros.

For sure, the joke about blowing your whole leg off (as opposed to just your foot) applies, but it's the same for concurrency, distributed systems, cryptography, etc. The answer isn't to ban it, it's to exercise more care in the construction of these abstractions so that mere mortals can use them safely.

Julia seems to get around this by making macro syntax explicit [1]: e.g. the macro "code_native" is used as @code_native (expr)

This makes macro wizardry easier to spot, but restricts how "plastic" the language is somewhat.

https://docs.julialang.org/en/v1/manual/metaprogramming/

> most probably in a large code base

imo this is not only a problem in a singular large code base, but also libraries.

I know not everyone likes Go, but I've noticed that i find it super easy to dig into some open source dependency and navigate it, because in some ways Go is the exact opposite of lisp. In terms of the language not allowing a lot of flexibility at least.

I never found navigating foreign java code bases that easy because this project uses spring for dependency injection, that one does some other class loader magic etc, streams, no streams etc. pp.

That said, I do think LISP is cool, but I think it ends up being a right tool for the job kind of thing. I could imagine LISP being nice for things like game engine scripting etc.

> most probably in a large code base, you'll en up with 'unless', 'if-not' and depending on how creative others are probably also 'negat-if'.

In Clojure, "if-not" is part of clojure.core (the equivalent of java.lang in Java), so a decent programmer would almost certainly be familiar with it; and if not, it would be pointed out at a code review.

People use Lisp for a while, so the obvious simple ideas were probably already noticed and implemented.

With less frequent things, implementing the same thing twice under two different names is a problem that happens regardless of the language.

From what I understand, this relates closely to the "Lisp Curse"

Reply on news.ycombinator.com