6 ms·

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 unles

by zaro 6y ago

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

Fishysoup 6y ago
From what I understand, this relates closely to the "Lisp Curse"
- deleted 6y ago
  [deleted]
Jtsummers 6y ago
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.
- Reelin 6y ago
  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.
  - cloogshicer 6y ago
    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.
lawl 6y ago
> 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.
andreareina 6y ago
'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.
- Fishysoup 6y ago
  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/ https://docs.julialang.org/en/v1/manual/metaprogramming/
Viliam1234 6y ago
> 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.

by zaro 6y ago

Fishysoup 6y ago

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

deleted 6y ago
[deleted]

Jtsummers 6y ago

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.

Reelin 6y ago
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.
- cloogshicer 6y ago
  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.

lawl 6y ago

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

andreareina 6y ago

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

Fishysoup 6y ago
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/ https://docs.julialang.org/en/v1/manual/metaprogramming/

Viliam1234 6y ago

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