> to think about how your change is going to affect the whole system. That's a good thing.
I don't think you've made a coherent argument why that's a good thing. Putting in a printf for debugging is not spaghettification and does/should not affect the whole system.
You can printline for debugging using the trace function in Haskell. Or use unsafePerformIO, which is usually outlawed for production code but just fine in a transient state for debugging.
On "writing code shouldn't be easy", you're right that this statement, out of context, seems ridiculous. What I mean is that, when there are trade-offs between making it easy to write vs. read code, generally the reader's interests should be favored, because legible code is so rare. Obviously it's better for it to be easy to write code and to read it, but ease-of-writing is a secondary priority for large, production systems.
I pretty much agree with everything you say here. Thanks for the trace and unsafePerformIO tips.
> ease-of-writing is a secondary priority
In my experience, once you have enough experience and witnessed the suck of maintaining crappy code, writing good code is second nature and doesn't take conscious effort.
There's a lot of truth in what you're saying. However, if maintaining shit code turned people into good coders, then there'd be a lot less bad code (because the precursor is so damn common). I think it also requires curiosity, desire to do things right, and access to the right information (which is now trivial if one knows where to look).
What I would actually say is: the differential in difficulty between writing good code and writing bad code should be minimal or, if possible, negative.
Actually I disagree on your first point. My first job was maintainenance programming, and for some reason I stuck around and did it for 3 years. That has taught me the suck of trying to maintain and work with shitty code.
Now, X years later I still tell stories about that first job, and I always remember how I felt maintaining spaghetti code when I write code.
BUT, I find that most of my fellow programmers either have not worked as m.programmers; or have done so but didn't notice it, because I guess they don't have a built-in desire for arete or just didn't want to get upset about their work and chose to ignore the crappy code.
I don't think you've made a coherent argument why that's a good thing. Putting in a printf for debugging is not spaghettification and does/should not affect the whole system.
> Writing code shouldn't be easy
Eh?