[globalreset]

Large part of biggest crimes I've seen in software comes down to picking some allegedly good property and optimizing for it irrespective of costs and limitations it involves. Encapsulation, modularity, flexibility, readability, purity, testability - you name it. Some dubious, some reasonable - no matter what, it usually involves costs and drawbacks.

I have 99 big problems developing software, and not being able to read it from start to end ain't one.

I'm a bit jealous for people advocating such things, being able to work on software tiny enough to even be able to think this is practical. Literate programming could work for tiny software that can be approximately flattened to a 1d "story": "beginning -> end" with only minor detours.

Most of projects I worked with was large enough that things are optimized precisely for not having to understand large parts that were abstracted away (and the problem is to try to do it without introducing too much complexity).

[gyulai]

It's not so much about the size of the codebase, it's more about the tradeoff of how much code there is, versus how much intrinsic/real complexity.

By "real" complexity, I mean to exclude complexity for complexity's sake, or complexity that's a side effect of a piece of software being concerned with itself and its own structure rather than with solving any problem that exists outside of it. -- We can surely all agree that the latter is bad.

Academic prototypes, for example, tend to solve highly complex problems with small codebases, but the problems are often contrived or they are tiny pieces of systems that would have to be much larger to be of any use.

Software systems you encounter in your run-of-the-mill software engineering business often have huge codebases, but the large size is not due to the fact that there's any problem there of any real complexity. The system just needs to solve trivial problems, and there are just a lot of them.

But you can certainly have systems that need to solve many problems and some of those problems have high intrinsic complexity. In such a scenario, it's important to recognize that there's a part of your system that's "extra special" due to its complexity, and needs to be approached in a way that's different from how you approach most of your engineering. You might need to write a library in a literate programming style, and then use that library from your other code, which isn't written in literate style. Engineering organizations are seldom able to have that kind of flexibility. The opinion you're likely to get is "we don't do literate programming here". The outcome is that such organizations are just not capable of writing such systems, because a system is only as good as the worst job you've done at solving any of the problems it raises.

I'd also like to point out that you're guilty of a bit of a strawman argument there, because all I did was point out a technique I sometimes find useful, and you responded as if I was advocating applying it "irrespective of costs and drawbacks" by pointing out that this often ends up as "crimes against software".