7 ms·

Alan Kay has famously cited the half page of code on page 13 of the Lisp 1.5 manual as the "Maxwell's Equations of Software" https://www.gnu.org/software/mes/m

by ozten 4y ago

Alan Kay has famously cited the half page of code on page 13 of the Lisp 1.5 manual as the "Maxwell's Equations of Software" https://www.gnu.org/software/mes/manual/html_node/LISP-as-Maxwell_0027s-Equations-of-Software.html https://www.gnu.org/software/mes/manual/html_node/LISP-as-Ma...

p-e-w 4y ago
That's extremely clever code, yes, and the implementation is "elegant" in the sense that it compresses a concept down to its essence, and casts that essence in code, using a language that is uniquely suited to expressing the structure of the underlying idea. It's terrible code from a software engineering perspective though. The readability is roughly that of x86 Assembly. The density obfuscates what is actually happening. If someone opened a pull request containing one of these function implementations, I would probably assume they're trying to insert a backdoor somehow. Either way, I'd never accept code like this. Great code is simple and clear in a human sense, not just minimal in a conceptual or computational sense.
- WheelsAtLarge 4y ago
  "Great code is simple and clear in a human sense, not just minimal in a conceptual or computational sense." Old time programmers can't get past the low resources of old systems so they continue to prefer clever and tight code over simple and clear code. Last I was in school many of my teachers preferred clever code so that's the coding style we strived to copy. I suspect that's still the gold standard. But I agree, simple and clear in a human sense, is much better. Specially in a team environment where we need to read other's code. Having to explain your code is just wasted effort and time.
  - wanderingstan 4y ago
    As an old time programmer myself, I anecdotally notice that junior developers seem more prone to use dense/clever code, while more experienced devs prefer clear and easy to maintain code.
    - waste_monk 4y ago
      They're probably being taught by academics who were adapted to the old school low-resource style of programming, and have been out of industry long enough that they never adapted to modern best practice. And assignments tend to praise cleverness over readability and long-term maintainability, because who cares if it's read-only code when your assignment only spans a few weeks and then never matters again - you just need to impress the professor (or TA who does the actual grading) and move on. The university system does sometimes result in students having strange ideas that are a bit divorced from industry best practices (and in some cases reality), due to the attitudes of their teachers rubbing off on them. I had one professor who continually insisted we were on the verge of a major resurgence of semantic web technologies and strict XHTML, and a friend who took a dev tools course (mostly focusing on git, makefiles, etc.) and was told tools like Maven would never take off and you're better off managing dependencies by hand (this was around ~2017). I don't want to be harsh on academics / the tertiary education system in general, but I think it's kind of an unavoidable consequence. Maybe "boot camp" students fare better?
- chii 4y ago
  > I would probably assume they're trying to insert a backdoor somehow well, it's an eval/apply loop, which by definition, is going to be able to execute code! I dont think it's obfuscated at all. Of course, reading it requires knowledge of how the read/eval loop works in lisp - something the viewer might not have studied, but that doesn't make it obfuscated.
  - p-e-w 4y ago
    > I dont think it's obfuscated at all. Not deliberately obfuscated, true. But any code that contains tokens like "CAR", "caar", "CDR", "cdar", "CONS", "caddr", etc doesn't belong in a modern production environment where auditability and maintainability are paramount. What's the goal here, shortest possible text? Why not just replace each of those with a Unicode Greek letter and save two bytes and three characters each? If that means Lisp itself is the problem, so be it. The assumption that "software engineers" in the late 1950s somehow designed the holy grail of programming languages is laughable anyway.
    - ctrlmeta 4y ago
      > Not deliberately obfuscated, true. But any code that contains tokens like "CAR", "caar", "CDR", "cdar", "CONS", "caddr", etc Do you code in Lisp? I do and I don't find it obfuscated at all. On the other hand I find it absolutely clear and beautiful. car, caar, cdr, etc. are no more obfuscated than chmod, chown, cp, ls, etc. in shell. If you are unfamiliar with Lisp, sure they would seem obfuscated but so would those commands in shell to someone who has never done shell. But after using the shell for a while those commands become clear, concise and convenient. So do car, cdr, caar, etc. "cons" just constructs a cell. (cons "foo" "bar") constructs a cell with "foo" as its car (first element) and "bar" as its cdr (second element). It can't get simpler than that!
      - duped 4y ago
        LISP is beautiful with terrible naming conventions, and I don't think that's a hot take. "caddr means car of the cdr of the cdr" is almost intentionally obtuse for describing the third element of a list. > It can't get simpler than that! It can, because in your description you introduce multiple levels of indirection.

by ozten 4y ago

p-e-w 4y ago

That's extremely clever code, yes, and the implementation is "elegant" in the sense that it compresses a concept down to its essence, and casts that essence in code, using a language that is uniquely suited to expressing the structure of the underlying idea. It's terrible code from a software engineering perspective though. The readability is roughly that of x86 Assembly. The density obfuscates what is actually happening. If someone opened a pull request containing one of these function implementations, I would probably assume they're trying to insert a backdoor somehow. Either way, I'd never accept code like this. Great code is simple and clear in a human sense, not just minimal in a conceptual or computational sense.

WheelsAtLarge 4y ago
"Great code is simple and clear in a human sense, not just minimal in a conceptual or computational sense." Old time programmers can't get past the low resources of old systems so they continue to prefer clever and tight code over simple and clear code. Last I was in school many of my teachers preferred clever code so that's the coding style we strived to copy. I suspect that's still the gold standard. But I agree, simple and clear in a human sense, is much better. Specially in a team environment where we need to read other's code. Having to explain your code is just wasted effort and time.
- wanderingstan 4y ago
  As an old time programmer myself, I anecdotally notice that junior developers seem more prone to use dense/clever code, while more experienced devs prefer clear and easy to maintain code.
  - waste_monk 4y ago
    They're probably being taught by academics who were adapted to the old school low-resource style of programming, and have been out of industry long enough that they never adapted to modern best practice. And assignments tend to praise cleverness over readability and long-term maintainability, because who cares if it's read-only code when your assignment only spans a few weeks and then never matters again - you just need to impress the professor (or TA who does the actual grading) and move on. The university system does sometimes result in students having strange ideas that are a bit divorced from industry best practices (and in some cases reality), due to the attitudes of their teachers rubbing off on them. I had one professor who continually insisted we were on the verge of a major resurgence of semantic web technologies and strict XHTML, and a friend who took a dev tools course (mostly focusing on git, makefiles, etc.) and was told tools like Maven would never take off and you're better off managing dependencies by hand (this was around ~2017). I don't want to be harsh on academics / the tertiary education system in general, but I think it's kind of an unavoidable consequence. Maybe "boot camp" students fare better?
chii 4y ago
> I would probably assume they're trying to insert a backdoor somehow well, it's an eval/apply loop, which by definition, is going to be able to execute code! I dont think it's obfuscated at all. Of course, reading it requires knowledge of how the read/eval loop works in lisp - something the viewer might not have studied, but that doesn't make it obfuscated.
- p-e-w 4y ago
  > I dont think it's obfuscated at all. Not deliberately obfuscated, true. But any code that contains tokens like "CAR", "caar", "CDR", "cdar", "CONS", "caddr", etc doesn't belong in a modern production environment where auditability and maintainability are paramount. What's the goal here, shortest possible text? Why not just replace each of those with a Unicode Greek letter and save two bytes and three characters each? If that means Lisp itself is the problem, so be it. The assumption that "software engineers" in the late 1950s somehow designed the holy grail of programming languages is laughable anyway.
  - ctrlmeta 4y ago
    > Not deliberately obfuscated, true. But any code that contains tokens like "CAR", "caar", "CDR", "cdar", "CONS", "caddr", etc Do you code in Lisp? I do and I don't find it obfuscated at all. On the other hand I find it absolutely clear and beautiful. car, caar, cdr, etc. are no more obfuscated than chmod, chown, cp, ls, etc. in shell. If you are unfamiliar with Lisp, sure they would seem obfuscated but so would those commands in shell to someone who has never done shell. But after using the shell for a while those commands become clear, concise and convenient. So do car, cdr, caar, etc. "cons" just constructs a cell. (cons "foo" "bar") constructs a cell with "foo" as its car (first element) and "bar" as its cdr (second element). It can't get simpler than that!
    - duped 4y ago
      LISP is beautiful with terrible naming conventions, and I don't think that's a hot take. "caddr means car of the cdr of the cdr" is almost intentionally obtuse for describing the third element of a list. > It can't get simpler than that! It can, because in your description you introduce multiple levels of indirection.