4 ms·
>If there's a dense 200 lines of Haskell (or APL) takes you a week to understand, does that mean that Haskell is hard to read. IMO, Yes! If you put a mental o
by silisili 5y ago
>If there's a dense 200 lines of Haskell (or APL) takes you a week to understand, does that mean that Haskell is hard to read.
IMO, Yes! If you put a mental onus on folks to understand x before you understand y, there's no telling how deep the rabbit hole goes. Why not use asm? Why can't you understand pointer arithmetic? The more you increase the mental requirements of the reader, the worse.
I used to be the opposite. I used to write smart C code and feel good about it. Because it was fun and challenging to write, which is what we all desire. With age(mostly) and experience, I realize how much of a mistake that was, if not for others, then older me.
To play off your example, list comprehensions are a nice one liner. In Python, you can do in one line what Go takes 10x more lines for. I still prefer Go, despite it feeling like shackles at time to write.
- strken 5y agoI prefer reading Go, but it's not because Go code is less dense, it's because Go keeps the language's grammar small. I usually don't have to follow a chain of macros or pre-processor directives, because the language discourages them. Reading boilerplate is still tedious. There's a careful balance required to make a language simple yet expressive so that concepts are obvious. On one side is a Turing machine or Brainfuck, where the concepts in a piece of code don't pop out to the reader because the language is too simple to express them concisely. On the other is Haskell or Rust, where the language expresses so many concepts and has so many rules that the reader will necessarily be unfamiliar with some parts of what they read.
- lmm 5y ago> IMO, Yes! If you put a mental onus on folks to understand x before you understand y, there's no telling how deep the rabbit hole goes. Why not use asm? Why can't you understand pointer arithmetic? The more you increase the mental requirements of the reader, the worse. I'm not talking about any difference in "mental requirements". I'm saying suppose, for an equally skilled reader at an equivalent starting point, codebase A (200 lines) takes a week to read, and codebase B (20,000 lines) also takes a week to read. And my point is that many people would blindly say that this means A is harder to read than B, but actually, what matters is whether A is doing more or less than B (i.e. is A solving a harder problem than B or vice versa) - the number of lines is irrelevant!
- jazzyjackson 5y agokind of a "what's heavier, a pound of feathers or a pound of brick" situation you got there, I like it I wonder if there's a measurable difference in possibility space where 200 lines of dense code is less likely to contain bugs than 20,000 lines of readable code. might be a case of "some infinities are larger than others"
- whoisthemachine 5y agoAnd often times, once you become an expert in the language of codebase A, it will take less time to understand it, while codebase B is always stuck at 20K LOC.
- Scarbutt 5y agoTo play off your example, list comprehensions are a nice one liner. In Python, you can do in one line what Go takes 10x more lines for. I still prefer Go, despite it feeling like shackles at time to write. Why would you prefer 10k lines of readable code over 1K lines of readable code?
- silisili 5y agoFor the same reason I'd rather read Romeo and Juliet than 'girl pretends to die. guy kills himself. girl kills herself'. Yeah they're both the same, but one gives you thought process, at minimum.
- lmm 5y agoI find it's far more common that the extra lines are meaningless ceremony. No-one thinks about writing, say, boilerplate getters and setters, whereas a more concise version of the code will express the actual intention with a minimum of chaff.