[gregjor]

Good point, I agree with everything you wrote. I didn't intend to compare code language style to literature, maybe I failed to make that clear.

I tried to make the more subtle comparison that some programmers react reflexively to code that doesn't look familiar to them and call it unreadable, the same way that a person unfamiliar with Shakespeare and unprepared (or unwilling) to make the effort to read it will dismiss Macbeth as hard to read.

A person new to Shakespeare picking up Macbeth will find the book challenging because of the antique language, the poetic form and dramatic devices, maybe the historical setting and allusions. A person new to a body of programming code may react the same way, for similar reasons. A reader new to Shakespeare probably knows that the problem lies in their own abilities and patience, not in the book. A programmer new to a body of code will tend to blame the code, in my experience.

[Alex3917]

> A programmer new to a body of code will tend to blame the code, in my experience.

The key thing I disagree with about this is essay is that when it comes to code, there isn't really any reason ever to have anything other than The Hungry Caterpillar or Puppy Peek-a-boo.

There will obviously be differences between projects, but within a single API or whatever, there's no reason why every endpoint shouldn't be coded in exactly the same way. E.g.:

1) Validate user permissions

2) Validate user input

3) Validate business logic

4) Persist results

5) Return data or an error

Within a given project all variables and functions should be named consistently, there should be a consistent style of error handling, etc. Once you've read the style guide and understand how one endpoint works, you should be able to understand how every endpoint works. IMHO saying "I don't understand this, rewrite it" is always the most valuable code review one can give or receive.

If you hired someone to advertise your product on TV and viewers weren't able to understand the ad, you'd probably fire your ad team immediately. I don't see why developers should be held to any lesser standard.

[JamesBarney]

Good writing is not necessarily readable writing. Shakespearean works are good writing, but they are most certainly not easily readable. There is code that is great code because for many other reasons than readability.(Like performance, correctness, robustness)

Easy to read writing is simple and concrete. Code that is easy to understand is also simple and concrete.

Complexity and abstraction push away understanding like two positive magnets. But sometimes readability is worth sacrificing to achieve a separate goal with the code.

[Alex3917]

> they are most certainly not easily readable

They would have been easy to understand by folks who were alive at the time they were written when performed on stage. The only unfamiliar words would have been the ones he coined, but most of those were easy cognates from latin. If Shakespeare wrote the same works today then he'd be a terrible writer.