First: No, that's not the point of "worse is better". The point is that usability comes from rapidly iterating as you run into real problems, not from an ivory-tower design. The first paragraph of Gabriel's essay says: "The concept known as 'worse is better' holds that in software making (and perhaps in other arenas as well) it is better to start with a minimal creation and grow it as needed. Christopher Alexander might call this "piecemeal growth." This is the story of the evolution of that concept." This has nothing to do with inertia and old code bases preserving old things.

Second: I would suspect that there are far more new projects started today in C than there are in COBOL. C is in use (at least sometimes) as a voluntary choice, and COBOL is not.

"First: No, that's not the point of "worse is better". "

I hear lots of interpretations of it. I could be misremembering. I'll take another look at it. Appreciate the specific points to look into. :)

"Second: I would suspect that there are far more new projects started today in C than there are in COBOL. C is in use (at least sometimes) as a voluntary choice, and COBOL is not."

If we're using that constraint, then Java and PHP are the example with Java for about any kind of app. A lot of people even like Java. They think it's great and hate C. So on and so forth. Yet, the popularity still tells me nothing as I got to watch Java get forced by Sun and others into its position step-by-step with insane amounts of work to get it to match performance and productivity of better-designed languages... partly successful there. It was actually experience of Java IIRC (later C#) that was the reason many people didn't think an OS could be done in a GC'd language. They mentally associated GC'd language with stuff like that. That a small team pulled it off in Oberon with a handful of people at a time porting or extending it is always news to Java developers I meet here.

Lack of context, bad design, meant to replace prior languages for most applications, platform orientation, and massive ecosystem + uptake + tooling make it a better comparison. So, I'll use it and COBOL next time.

Off topic: Do Enterprise Java and COBOL feel kind of the same to you? I mean, as languages they're completely different, and yet...

Maybe anything that winds up trying to play in that "language for big corporate enterprise software" winds up like that?

Nah, the experiences are extremely different. Old-school GUI's with files locked up in mainframes vs Netbeans with tons of middleware, ANT, etc. Java has all these frameworks, model-driven development with UML, and so on. COBOL is probably strict waterfall with Java shops taking on forms of agile. Huge differences even if I see some superficial similarities.

What they have in common, as with C, is they were pulled or pushed in for ecosystem benefits + marketing then spread and sustained on that bases mostly. So much stuff written in them with so many talent or tools that they're self-perpetuating. I'm claiming most C adoption & entrenchment is the same phenomenon outside embedded or ultra-high-performance applications where use is quite practical. You constrained the COBOL example but I recalled popularity effect applied to Java, too.

You are missing my point by focusing on just half of it. I like C and know a few more people that like it too. I'd happily start new projects in C as long as they fit C's (traditional) use cases.

I don't think anyone really likes COBOL. And I don't think anyone would start a new project in COBOL given the choice.

Your main point is you like it. The other is it's popular, which is non-technical. Glad you enjoyed using it, though. I'm all for programmers enjoying their work. Everyone's preferences are different on that.

"I don't think anyone really likes COBOL."

COBOL was like the Visual Basic of mainframes. It looked close enough to pseudo-code or business problems that even lay people could learn to write mediocre code in it. They could Get Stuff Done. Versus assembly, ALGOL, or C, they'd prefer it since they can grok it. Truth is that those people probably don't need to be coding business-critical apps but that plus mainframes making compilers for it gave COBOL an adoption advantage. Much like relationship between cheap hardware, spread of UNIX, and C compiler availability.

Personally, I can't stand to look at COBOL. I tried to do my part ridding us of it by forwarding things like Semantic Designs Inc to COBOL shops where possible. Very entrenched, though, due to inertia of tons of software written in about a billion lines or so of it in shops where it's what most people know. Sound familiar?

Both C and COBOL are entrenched and (for very different reasons given their areas of applicability) are very difficult to displace. I don't disagree on this, it's an obvious fact.

But COBOL alternatives won. Where COBOL used to rule, Java rules now and .NET languages follow closely. People want to throw COBOL away but can't.

C alternatives just can't get past their niches. Even when people don't have to use C, they choose C. It's more than clear to me that this happens because people like C and actively work to keep it entrenched.

And liking C doesn't mean being unaware of its problems. But it means people want those problems fixed while keeping the core of what they like. I believe C alternatives fail because they go too far. They fix its shortcomings but also go for a different aesthetic.

So yes, my point is largely non-technical. However, our industry is full of examples of things that "won" for largely non-technical reasons.

Fair points. I disagree that all the C alternatives went too far. Even C compilers that just added bounds checks didnt get adoption. The Plan 9 C, with minimal mods, didn't get adoption. C fans won't take fixes in the core language no matter how similar to C. They will and did accept extensions thqt increase its power on occasion.