Discussed at the time: https://news.ycombinator.com/item?id=7091495

Thread from 2017: https://news.ycombinator.com/item?id=13855185

People don't voluntarily read code because most code isn't readable.

That is a reason people do not read code, but imo not the primary one. I don't read code because, unless I am forced, it is a waste of time. I used to grade assignments for an intro CS class @ Stanford, and if I had to read your helper functions it was because your code didn't work. Not because I wanted to.

Not to start wars, but imperative code especially is a waste of time to read unless forced, as I need to understand your desired goal AND how you chose to get there. See for + if vs filter, for example. I would rather just read a function comment or class comment or some doc instead (assuming its up to date...)

Sounds like you haven't read much good code. I have worked on a lot of "reasonably good" code I didn't mind reading. Reasons for code to be good or bad vary. The Linux memory management code (linux/mm), for example, is rather hard to read, but also a big technical accomplishment. So it's still interesting (and I read it just out of interest). Code that pushes around data is nice if it's well organized and named. Etc.

No I've read good code. At work you don't have the liberty to sit and understand every line of a library you're using does or some other teams work.

I did not say code should not be read, just that it shouldn't be expected to be read. Make it clear before you ever get to the code what's going on

What's your opinion on the Lisp paradigm of creating a DSL that reflects the problem domain, and then encoding the solution to the problem—in a readable way—directly in this problem-domain embedding?

Sort of like the more generalized form of what BDD is supposed to allow non-developers to do, where there's no requirement that anyone be able to change the code quickly, just a requirement that they be able to easily audit and understand the code from the code itself.

And there is no concerted effort to make code readable, because most code will exist for its entire lifetime without anyone attempting to read it.

People who need to get up to speed to become new maintainers for such codebases will sit down and grok the codebase, by poking it with tooling, exploring APIs, etc. until they get a sense of it—sort of like getting a sense of a city. But even they won't ever just sit down and read through the code, because they know it wasn't written for that.

It's a bit of a vicious cycle. The question is: which part of the cycle is easiest to break?

Really code is meant to be read like a map or diagram and not a poem.

A table of contents may make codebases easier to read. I have no problem reading code from systems I know well, because I know how to move. Other codebases I don't know where to start

Code is screenplay.

"computers aren't paintings"?

Most code is unreadable, but that doesn't mean there isn't beautiful code out there worth reading.

https://norvig.com/spell-correct.html is like poetry— or at least what I imagine poetry is like to people who like poetry.

Reading it changed the way I look at code, and inverted what I consider good code.

If it's not in a super high level language it probably won't be beautiful, at least not in the same way as Norvig's spelling corrector. For lower-level code, approaching it like a scientist, as OP suggests, may be right; I wouldn't give up on a reading group for sufficiently high-level code.

> ...or at least what I imagine poetry is like to people who like poetry.

Which isn't poetry. Poetry is its own thing. We are not required to compare non-comparable things.