[michaelochurch]

My opinion: there isn't one single good way to do programming. Often, you want your interfaces to be referentially transparent (stateless). Usually, it's best for source code to be in the functional style as well-- but not always. Sometimes, mutable state is exactly what you need. But it shouldn't be the default, unless you're working at a very low level.

There are, on the other hand, a lot of bad ways to do programming: FactoryFactory nonsense, software-as-spec systems, waterfall methodology. We've seen them several times in our careers and have a hair-trigger sensitivity to stupidity, because we've seen it cripple or kill projects.

Great programmers tend to be unforgiving in their condemnation of the bad ways of doing things, but hesitant in accepting one programming model-- even a very good one like Lisp-- as being the One True Way of doing things. As soon as you have a One True Way, some very smart people disagree with you-- and that's a good sign that you're at least partially wrong.

In other words, it's good to be passionate about using the right tools for the job. It's a problem when people think the same tool is right for every job.

[pionar]

It seems that in saying that having a One True Way attitude is wrong, you've developed a Not True Way attitude. Waterfall methodology might work just fine in some situations, software-as-spec works on smaller applications moving to a different platform, and I haven't found one, but I'm sure that the FactoryFactory nonsense can work to keep order in extremely large codebases (I work on a large codebase, and haven't found a need for super abstraction, but that's just me).

Calling these unequivocally bad is counter to the argument you're presenting (which I happen to agree with).

[sliverstorm]

software-as-spec is out of vogue now? I may have misunderstood, but I thought software-as-spec is the same thing as test-driven-development, which I could have sworn is still lauded.

[RogerL]

Can you explain why you think they are the same? SW as spec is problematic because whatever the sw does is interpreted as being what it is supposed to do. So how do you identify bugs? At least with TDD the tests serve as some kind of documentation.

I'm no fan of either, generally, but I also don't work on "move fast. break things" type projects.

[sliverstorm]

I'm not a software developer, so I could easily have misunderstood what sw-as-spec is.

I definitely do not work on "move fast break things" projects.