4 ms·

Modularity incurs a complexity tax. If you are smart enough to keep it all in your head, like a Motie Engineer, you can simplify by omitting it. But if you're n

Modularity incurs a complexity tax. If you are smart enough to keep it all in your head, like a Motie Engineer, you can simplify by omitting it. But if you're not...

mcv 7y ago
That's the thing here. Knuth can easily juggle far more complexity in his head than the average programmer, and that's fine for software that only he has to maintain. But when something needs to be maintainable by average programmers, you need to write for them and avoid that complexity.
- squiggleblaz 7y ago
  Who's writing for the average programmers? It's the average programmers. How can average programmers write code that is sufficiently abstract that it hides the complexity they can't handle? How can they change that code when it doesn't work? Does every company of 5 devs need to have a PhD?
  - mcv 7y ago
    Everybody who writes code that's going to be supported by other people, should be writing for the average programmer.
  - hyperpallium 7y ago
    > How can average programmers write code that is sufficiently abstract that it hides the complexity they can't handle? Well said. Hiding complexity is harder than handling it. Designing an effective way to expose it for use amounts to (part of) a "programming system" [Brooks]. So it's library writers who hide the complexity for average programmers, with a "programming product": stdlib, open source project or (rarer these days) commercial "engine". When there is no such library, we get the current state of our art: many projects failing.
squiggleblaz 7y ago
I think that's the point of literate programming. You no longer have to keep it all in your head. You have an article or a book. You go to the chapter that interests you, and modify it. Now those modifications get scattered throughout the monolith. The point of literate programming is that you have a text which is structured in a way that humans are good at dealing with, which is not some nifty mathematical abstraction like functional or oop code nor coherent modules. (Having worked with a badly structured monolith with a mixture of literal code and a million bad abstractions, I must admit the simplicity of working with the used-once literal code has its advantages. But so does the more abstract code. The only thing I know is that I want to control my entry point rather than go via a framework and suffer my concrete classes getting upcasted.)
mikevp 7y ago
But always keep in mind Gene Spafford's observation: Debugging is twice as hard as programming. So, if you write a program as cleverly as you can, you are by definition not smart enough to debug it.

Modularity incurs a complexity tax. If you are smart enough to keep it all in your head, like a Motie Engineer, you can simplify by omitting it. But if you're not...

mcv 7y ago

That's the thing here. Knuth can easily juggle far more complexity in his head than the average programmer, and that's fine for software that only he has to maintain. But when something needs to be maintainable by average programmers, you need to write for them and avoid that complexity.

squiggleblaz 7y ago
Who's writing for the average programmers? It's the average programmers. How can average programmers write code that is sufficiently abstract that it hides the complexity they can't handle? How can they change that code when it doesn't work? Does every company of 5 devs need to have a PhD?
- mcv 7y ago
  Everybody who writes code that's going to be supported by other people, should be writing for the average programmer.
- hyperpallium 7y ago
  > How can average programmers write code that is sufficiently abstract that it hides the complexity they can't handle? Well said. Hiding complexity is harder than handling it. Designing an effective way to expose it for use amounts to (part of) a "programming system" [Brooks]. So it's library writers who hide the complexity for average programmers, with a "programming product": stdlib, open source project or (rarer these days) commercial "engine". When there is no such library, we get the current state of our art: many projects failing.

squiggleblaz 7y ago

I think that's the point of literate programming. You no longer have to keep it all in your head. You have an article or a book. You go to the chapter that interests you, and modify it. Now those modifications get scattered throughout the monolith. The point of literate programming is that you have a text which is structured in a way that humans are good at dealing with, which is not some nifty mathematical abstraction like functional or oop code nor coherent modules. (Having worked with a badly structured monolith with a mixture of literal code and a million bad abstractions, I must admit the simplicity of working with the used-once literal code has its advantages. But so does the more abstract code. The only thing I know is that I want to control my entry point rather than go via a framework and suffer my concrete classes getting upcasted.)

mikevp 7y ago

But always keep in mind Gene Spafford's observation: Debugging is twice as hard as programming. So, if you write a program as cleverly as you can, you are by definition not smart enough to debug it.