Simplifying problems is hard work - it means making firm decisions about your needs and laying bare how much of your work is truly original, vs. being regurgitated effort done thousands of times by others.
Writing a very complex solution appeals because it defers that work until later: "when I decide what I want, I'll just configure it that way." (And then you never decide.) Bonus points for "it will be the fastest/most comprehensive/most modular solution around." You reassure yourself, with one of these fallacious ideas, that "other people will use this for many years."
This is an issue that goes straight to the programmer's ego and purpose as a craftsman - who are they writing code for, what problems they are solving, what is the thing they are going to tout on their resume. They aren't going to be confident or arrogant enough to railroad all projects into minimal, ground-up Forth-idiomatic projects. Most of the perceived brass rings revolve around short-term ideas like a buzzword technology or a new platform or some other obviously overcomplicated and unnecessary thing.
I have tremendous respect for Chuck and have definitely aimed to emulate him more and more, little by little, though I am not a Forth coder and cannot claim to have neared the style he advertises. My most reusable bits of code tell a similar tale, though: Algorithm and data structure implementations. Parsers and compilers. Formats and protocols. In between those, lots of architecture that I thought was a good idea. Most of it unnecessary.
Side note: Format and protocol support tends to introduce a tremendous amount of complexity. The sign of a good format is in how much it manages to limit this "complexiplosion" while still giving users the features they need. One of the things holding me back is my desire to stick to existing formats.
Writing a very complex solution appeals because it defers that work until later: "when I decide what I want, I'll just configure it that way." (And then you never decide.) Bonus points for "it will be the fastest/most comprehensive/most modular solution around." You reassure yourself, with one of these fallacious ideas, that "other people will use this for many years."
This is an issue that goes straight to the programmer's ego and purpose as a craftsman - who are they writing code for, what problems they are solving, what is the thing they are going to tout on their resume. They aren't going to be confident or arrogant enough to railroad all projects into minimal, ground-up Forth-idiomatic projects. Most of the perceived brass rings revolve around short-term ideas like a buzzword technology or a new platform or some other obviously overcomplicated and unnecessary thing.
I have tremendous respect for Chuck and have definitely aimed to emulate him more and more, little by little, though I am not a Forth coder and cannot claim to have neared the style he advertises. My most reusable bits of code tell a similar tale, though: Algorithm and data structure implementations. Parsers and compilers. Formats and protocols. In between those, lots of architecture that I thought was a good idea. Most of it unnecessary.
Side note: Format and protocol support tends to introduce a tremendous amount of complexity. The sign of a good format is in how much it manages to limit this "complexiplosion" while still giving users the features they need. One of the things holding me back is my desire to stick to existing formats.