Comment by CobrastanJorji | Hacker News Reader

Comment by CobrastanJorji | Hacker News Reader

Parent Full thread

> Should we strive to satisfy the Shakespeare for Dummies demographic?

A thousand times, yes!

There is code out there so elegant and pure that, after painstakingly pulling apart its pieces and analyzing each choice of word like a Robert Frost poem, we're left feeling like we've seen a face of God.

When debugging in the middle of the night because an alarm went off or a customer is angry, T. S. Elliot is absolutely the last thing I want to see. When I want to maintain a large system quickly, I want to be treated like I'm 5. I don't want Shakespeare. I don't even want Shakespeare for Dummies. I want "Dick and Jane Process a Customer Order."

I absolutely agree with the author that when I say "This code is unreadable," I actually mean "I haven’t spent enough time trying to read," but time is something I don't have. My coworkers and I will likely read the same code many times. We only have so much time to spend reading code. Code that takes a lot of time to read is bad. We do not have time to keep studying the code until it is no longer unreadable.

We are more than willing to invest quite a lot of additional time writing the code to make the time it takes to read the code as low as conceivably possible. Heck, with a small handful of exceptions, I will happily trade quite a bit of performance for simplicity.

Sure, if you're Terje Mathisen, and you're writing Quake 3, and Polyhymnia or Velvel Kahan descend from Mt. Helicon singing of inverse square roots and the number 0x5f3759df, and you happen to be trying to optimize a 3D game engine, sure, write poetry. Ages and ages hence, we shall read of your algorithm by the fireside and slowly smile as a blog explains to us why it is brilliant. Sing on! But if you're writing a normal program that's gonna be maintained frequently by normal people, you call security. That muse does not have a badge. She does not work here. There is a clear "no children of Mnemosyne" sign in the lobby.

But, in the general case, who is this lowest common denominator programmer you are writing for? I can probably work out a few lines of terse Haskell more quickly than a page or two of boilerplate Java, because that's what I'm familiar with. Readable code is about pattern recognition, and everybody has a different set of patterns.

"Shakespeare for Dummies" works because English speakers tend to have a shared cultural familiarity that you can write for, but programmers typically don't.

That's not to say style isn't important. I'd say consistency is more important than any notion of simplicity, because once the reader has recognised a pattern they can re-recognise it quickly.

This. The problem with the Shakespeare argument is that authors compares code to artistic writing. But code should be compared to technical writing. When you write technical analysis or documentation, you are expected to create easily understood document that is tailored for the reader. Even if you really enjoy Joyce, you usually do not do your technical writing in Finnegans Wake style. That would be a terrible practice.

It is similar with code. People are writing obscure code for various reasons (trying to break the language, code golfing, etc.), but when you write code for a project that is to be maintained in the future, you should use the "formal" style of coding. This also means using the best practices and patterns that other people are accustomed to so they can be more effective.

Yeah, we shouldn't compare code to literary text or poetry, since these texts are not malleable in the way we want code to be.

For example Shakespeare often uses obsolete words or words which have changed meaning - but we can't replace these with more modern words or phases, since then it would break the meter or rhyme and destroy some of the double meanings. This is not a quality we want for code. We want code to be maintainable.

Perhaps this is the reason why pure FP is just as obscure as it is? Sure, it's technically more beautiful and pure and stuff, like a piece of art -- but a bunch of Java is easier to figure out, because it's plain as a cloth sack.

There's no reason "pure FP" should be fundamentally any more inscrutable than Java code; that assumption may just be a personal bias due to familiarity. It's definitely possible to go the other way too, with an object-oriented mess where a judicious application of functional principles would make for much clearer code.

> but a bunch of Java is easier to figure out, because it's plain as a cloth sack.

I think you have been lucky! I have seen plenty of Java which was confusingly overdesigned.

Preach it. The less cognitive load required to dive in and make changes, the better.

The young version of me wanted every opportunity to show off, but the grizzled veteran I am today is in love with simplicity and clarity.

Have you ever encountered code that's easy to change but needs to be changed very often, is that strictly better than code that is hard to change but very unlikely to ever change?

A more concrete example, fixing null pointer exceptions is often easy but code that avoids them using abstractions like maybes and sum types is harder to change but requires less maintenance overall.

Lessening cognitive load while increasing easy manual work is not always better

Let's imagine that the person that wrote that code has left the company, and all of their coworkers are 4 years out from touching that area of code.

What is the answer to your question, now?

Well that code has already provided its value over 4 long years without bothering anyone, it doesn't hurt if someone has to struggle a bit understanding how it works now.

Have you read dick and Jane? I have, 150 pages to say "Sally is upset because her toy sailboat got left outside in the rain, and she wants dick to go get it". When I'm looking at a 3am level bug I don't want to wade through that mess, and odds are that the more complex rendering I gave. The complex rendering might have even "used the word storm above" and averted the entire 3am crisis.

Dick and Jane has a place for my 5 year old. But we expect 5 year olds to grow up to better.

> But we expect 5 year olds to grow up to better.

But we shouldn't where it's important (implying that code is important). Don't put the "open door" button next to the "set building on fire" button, just because all employees should know which button to press to open the door.

It reminds me of Pointing and Calling [1]. Of course you expect everybody to be able to do things without pointing and calling, but it improves safety and reduces errors, and that's more important than "but people should be able to do it without silly gestures", isn't it?

[1] https://en.wikipedia.org/wiki/Pointing_and_calling

Truly. Illegibility as a programmer sport is a horrible and costly thing to pick up after.

Also you should not need to press "go to definition" 10 times in a row...

Reply on news.ycombinator.com