Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Code Runs on People

rachelbythebay.com

Post reply on HN
Print view View original

31–35 of 35 posts

Re: Code Runs on People

#31

Post by indigochill »

makeitdouble wrote: post #23
indigochill wrote: post #20

Earlier quoted context omitted.

> If as a software developer you optimise for writing as little code as possible and not having to spend much time reading code either then what exactly are you working on? Minimizing code read/written _per unit of work_. The less code you have to work with for a particular task, the more tasks you can accomplish in a fixed time frame. I'd much rather read and understand three tasks in an hour than only one.

It still doesn't add up to me. I take your "less code" as more terse and straight to the point code, which would go towards "clever" code instead of long, verbose and "simple" code. Which would go against most of what she rants about.

We might further expand the model in my previous comment with "units of comprehension". You might do five operations (each costing one unit of comprehension) in one line or in five lines. If it's one terse clever line, that's basically the same thing as five simple lines because there's the same amount of comprehension cost. The clever line might actually be penalized if it's not immediately clear that it's doing five things at once (and if it's clever, that implies it's not immediately obvious).

However, you might instead pack those five simple lines into a function that you give a good descriptive name. Now although the computational units are unchanged, the work now sometimes only costs one comprehension unit if the programmer working with the code understands at a sufficient-for-their-needs level what's going on from the function name/signature without needing to delve into implementation details. The difference between that and the terse clever line is that the terse clever line is still implementation whereas the function is descriptive abstraction.

This is of course very rough pretend-math and there are plenty of real-world cases where function names aren't descriptive, but hopefully conveys the idea of how you can reduce the code you need to read without needing to resort to cleverness.

Re: Code Runs on People

#32

Post by Zababa »

cjfd wrote: post #30
lmm wrote: post #2

I find this kind of exhortation to be useless in practice, because while everyone agrees that code shouldn't be too clever, no-one agrees on what kind of code is being too clever. For example, I'd argue that using C/C++ at all is probably "too clever" - humans are good at simulating the happy path, but very bad at simulating all the possible different ways such code might actually be executed. But all too often peopl…

Actually, I am a big fan of C++ code. Smart code may cause problems and I agree with that. You know what else causes problems? Tool churn and language churn. At any time of the night and day I very much prefer figuring out somebody elses smart code than figuring out yet another tool that we apparently need. It may not necessarily be that one thing wastes more time than the other but I am 100% sure where my preference…

Doesn't C++ have a lot of churn recently? The transition to C++11, best practices evolving, new features in C++14/17/20?

Re: Code Runs on People

#33

Post by Zababa »

np_tedious wrote: post #25
qsort wrote: post #4

Earlier quoted context omitted.

Yeah, I agree, it's the old complex/complicated conundrum. What's easier: a super compact representation of the problem that uses high-level concepts, or a verbose listing of dumb procedural code? Chances are it depends on both who you ask and the problem at hand.

I once read a HN comment the made an analogy to reading levels in a newspaper or other natural language. I found this very apt. If you have a rich vocabulary and so does your audience, you can explain an idea succinctly. Imagine a chain of function compositions in one line, very declarative. You grasp it near immediately or else its very difficult. If you don't, you use simpler words and need more of them. Imagine a…

There's something I always thought about but haven't been able to express clearly, and that's about "shared mental models". For example, with Go, the standard library is huge, people tend to not use many libraries, especially ones that change the language, and most people write code the same way. That means that for any two people writing Go code, they share a big part of their mental model about what code should be. That makes it "boring" when one reads the other.

On the opposite end of the spectrum, you could put Scala. There are already a few ways to use Scala as a language: Java with better types, OO all the way, functional all the way. And then there are ecosystems. Zio, cats, Akka. All of that means that for two people writing Scala code, the shared mental model is going to be small unless they use it the exact same way.

You can infer some things from that. Languages with big standard libraries that are somewhat good will allow people to share a bigger part of their mental model compared to languages with bad standard libraries (people will create replacements) or languages with very small standard libraries. Languages with a lot of features that are actually used will have a low amount of shared mental models, but also languages with not many features as people will reimplement things themselves.

Re: Code Runs on People

#34

Post by makeitdouble »

indigochill wrote: post #31
makeitdouble wrote: post #23

Earlier quoted context omitted.

It still doesn't add up to me. I take your "less code" as more terse and straight to the point code, which would go towards "clever" code instead of long, verbose and "simple" code. Which would go against most of what she rants about.

We might further expand the model in my previous comment with "units of comprehension". You might do five operations (each costing one unit of comprehension) in one line or in five lines. If it's one terse clever line, that's basically the same thing as five simple lines because there's the same amount of comprehension cost. The clever line might actually be penalized if it's not immediately clear that it's doing fiv…

I think I get your point.

On a documenting perspective, having the well named function contain five lines of simple operations will look better than the terse 1-in-5 line.

To me the catch is that the reader/reviewer will need to trust the function actually does what it is named after. Otherwise they'll need to go look at the 5 lines anyway, and it might be more costly to go navigate to the function and come back than reading the same content inline.

With that 5-in-1 terser (that's such an horrible compression ratio BTW) line, there is no need for blind trust. It might need more effort to understand, but you also don't have the burden to associate the name of the function with what it actually does (even aptly named functions will still have some gap with what they do or don't). I'd hold my head while decrypting that 5-for-1 bundle while cursing the world, but I'd also see that as a very pragmatic and reasonable choice if it relies only on standard libraries and don't abuse undefined or deprecated behaviors.

BTW I'd still go with a separate function containing the longer code if it helps for tests for instance. As everything and as you point out, real-world cases are always more complex and nuanced.

Re: Code Runs on People

#35

Post by lmm »

cjfd wrote: post #30
lmm wrote: post #2

I find this kind of exhortation to be useless in practice, because while everyone agrees that code shouldn't be too clever, no-one agrees on what kind of code is being too clever. For example, I'd argue that using C/C++ at all is probably "too clever" - humans are good at simulating the happy path, but very bad at simulating all the possible different ways such code might actually be executed. But all too often peopl…

Actually, I am a big fan of C++ code. Smart code may cause problems and I agree with that. You know what else causes problems? Tool churn and language churn. At any time of the night and day I very much prefer figuring out somebody elses smart code than figuring out yet another tool that we apparently need. It may not necessarily be that one thing wastes more time than the other but I am 100% sure where my preference…

C++ is notorious for each new version introducing a new way of doing things, so I don't think it's a good anti-churn language (plain C is more defensible for that, though I wouldn't use it for other reasons). And there's certainly tool churn in the C++ world. And frankly C++ has been a poor choice for long enough that I don't think "churn" is a good reason to keep using it - I'm not exactly thrilled when I pick up a TCL codebase from 1996, but you can do it and it'll work.
Post reply on HN