4 ms·

If there's one thing I've learned on the topic in my life and career, it's that everything written should be written for the reader, not the writer. Perl, C, a

If there's one thing I've learned on the topic in my life and career, it's that everything written should be written for the reader, not the writer. Perl, C, and C++ are very much for the writer. To some extent, Rust also. Python and Go are good for the reader. These aren't exhaustive lists, just what I'm familiar with. Admittedly, Python is tricky because it looks simple(boring) at first glance, but lets one use a lot of magic. My daughter is learning cursive and it just reminded me how much I blasted hate it. I can write it fine, reading it is a tossup. It's solely a shortcut for the writer, at the expense of reading. But anything of importance is read thousands or millions more times than it's written. In programming especially, the easier to read the better, no matter how verbose and boring the language. I think we'll get there, when we all quit pretending we're too clever to write that way.

lmm 5y ago
I find people make the mistake of thinking about how long it takes them to read 20 lines rather than how long it takes them to read x piece of functionality. (Of course it's much harder to compare the latter, but that's like the drunk searching for his keys under the streetlamp rather than where he dropped them). 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? Well, maybe, but if those 200 lines are replacing 20,000 lines of Go, then maybe not.
- 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 ago
    I 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 ago
      kind 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 ago
      And 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.
michaelcampbell 5y ago
True, but everything is hard to read until you learn to read it; cursive included.
- silisili 5y ago
  I studied and wrote cursive for a decade. I don't believe there's a person who can read cursive as well as printed language. I think it's also why there's no cursive font in widespread use.
  - chousuke 5y ago
    Cursive makes sense of you're a writer and still for some reason write your drafts by hand. The final result will get printed anyway. Otherwise, it's rather useless as anything but an art form; modern pens don't benefit from it at all and if you're not writing a lot by hand for whatever reason, why bother?
  - michaelcampbell 5y ago
    Partially because you've been exposed to printed language more.
jefftk 5y ago
How much to optimize for the reader versus writer depends on context. In my daily work on a mature system I completely agree I should optimize for readers: the things I'm writing will likely last a long time, during which many people will work on them. On the other hand, there are other contexts such as research or prototyping where it's much more important to get things out quickly; turn your ideas into code so you can see how they work.
- silisili 5y ago
  It's a common excuse in any place...we just need an MVP. I guess my wish is that the language du jour was one that made things harder for the writer and easy to read. The only reason people seek shortcuts is because they exist.
  - Zababa 5y ago
    > I guess my wish is that the language du jour was one that made things harder for the writer and easy to read. This has been the trend for a few years with static typing being added to every language.
  - unionpivo 5y ago
    > It's a common excuse in any place...we just need an MVP. Software projects are more than just code. Getting MVP out in 2 Months instead of 3 or 4 that it would take to do it properly, could doom the project. And I am not just talking about startups. I am talking about project at big slow moving enterprises. Getting somethin that the client can see, is one of the most important milestones. Sometimes that means that you will need to do a lot of cleanup, after first mvp, and sometimes yes it stays in sad state. But the alternative often is not better project, but project that got canceled/failed before first release. There are times that you want to go fast, and times that you want to take your time and do it properly.
pharmakom 5y ago
Python is hard to read at scale in my view. There are no mechanisms for managing state effectively. Long procedures that mutate globals can be very difficult to follow.
- xz0r 5y ago
  Instagram uses Python.
  - pharmakom 5y ago
    And? I think you can find an example of every major language at scale.
    - kamaal 5y ago
      Python is hard to read if you use vim and don't use something like lsp. IDE's make languages like Python really easy to read. Plus these days you also have type hints in Python as well.
      - Seirdy 5y ago
        "IDE features are language smells" -- Reg Braithwaite
        kamaal 5y ago
        Yeah, Ideally we should all be using Common Lisp. But let's not go down that debate again.
        Seirdy 5y ago
        My interpretation of that quote is that if a language is so complex and unergonomic that it needs complex tooling for developers to be productive, then maybe the language is poorly designed. Advanced tooling should be a nice-to-have, not a requirement.

lmm 5y ago

I find people make the mistake of thinking about how long it takes them to read 20 lines rather than how long it takes them to read x piece of functionality. (Of course it's much harder to compare the latter, but that's like the drunk searching for his keys under the streetlamp rather than where he dropped them). 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? Well, maybe, but if those 200 lines are replacing 20,000 lines of Go, then maybe not.

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 ago
  I 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 ago
    kind 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 ago
    And 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.

michaelcampbell 5y ago

True, but everything is hard to read until you learn to read it; cursive included.

silisili 5y ago
I studied and wrote cursive for a decade. I don't believe there's a person who can read cursive as well as printed language. I think it's also why there's no cursive font in widespread use.
- chousuke 5y ago
  Cursive makes sense of you're a writer and still for some reason write your drafts by hand. The final result will get printed anyway. Otherwise, it's rather useless as anything but an art form; modern pens don't benefit from it at all and if you're not writing a lot by hand for whatever reason, why bother?
- michaelcampbell 5y ago
  Partially because you've been exposed to printed language more.

jefftk 5y ago

How much to optimize for the reader versus writer depends on context. In my daily work on a mature system I completely agree I should optimize for readers: the things I'm writing will likely last a long time, during which many people will work on them. On the other hand, there are other contexts such as research or prototyping where it's much more important to get things out quickly; turn your ideas into code so you can see how they work.

silisili 5y ago
It's a common excuse in any place...we just need an MVP. I guess my wish is that the language du jour was one that made things harder for the writer and easy to read. The only reason people seek shortcuts is because they exist.
- Zababa 5y ago
  > I guess my wish is that the language du jour was one that made things harder for the writer and easy to read. This has been the trend for a few years with static typing being added to every language.
- unionpivo 5y ago
  > It's a common excuse in any place...we just need an MVP. Software projects are more than just code. Getting MVP out in 2 Months instead of 3 or 4 that it would take to do it properly, could doom the project. And I am not just talking about startups. I am talking about project at big slow moving enterprises. Getting somethin that the client can see, is one of the most important milestones. Sometimes that means that you will need to do a lot of cleanup, after first mvp, and sometimes yes it stays in sad state. But the alternative often is not better project, but project that got canceled/failed before first release. There are times that you want to go fast, and times that you want to take your time and do it properly.

pharmakom 5y ago

Python is hard to read at scale in my view. There are no mechanisms for managing state effectively. Long procedures that mutate globals can be very difficult to follow.

xz0r 5y ago
Instagram uses Python.
- pharmakom 5y ago
  And? I think you can find an example of every major language at scale.
  - kamaal 5y ago
    Python is hard to read if you use vim and don't use something like lsp. IDE's make languages like Python really easy to read. Plus these days you also have type hints in Python as well.
    - Seirdy 5y ago
      "IDE features are language smells" -- Reg Braithwaite
      - kamaal 5y ago
        Yeah, Ideally we should all be using Common Lisp. But let's not go down that debate again.
        Seirdy 5y ago
        My interpretation of that quote is that if a language is so complex and unergonomic that it needs complex tooling for developers to be productive, then maybe the language is poorly designed. Advanced tooling should be a nice-to-have, not a requirement.