Many would argue that Haskell ends up more consistent and elegant than those, despite having been designed by committee.

> the Linux kernel

Ends up with messier code and design than that of FreeBSD; perhaps an inevitable side effect of popularity, but perhaps exacerbated by the person-oriented command hierarchy.

> No one would set out to design a system to generate a file to probe a system for 26 programs that you don't even need to choose build options for a program that only runs on a handful of nearly identical systems.

Actually almost all of libtool's code was written by one person, Gary Vaughan.

Bazaars can produce elegant code, and cathedrals can produce monstrosities; a handful of anecdotal examples prove very little.

I would argue that Haskell is an outlier in more than one dimension.

The language most people know as C has been developed by a committee since 1983 (try reading pre-ANSI C). C++ has been developed by an ISO committee since 1993(?) and has expanded hugely in scope (standard library, namespaces, RTTI).

So successful programming language design by committee seems to be the rule and not the exception.

My point stands.

Total nonsense.

> and not languages to empower and liberate the programmer

Also nonsense.

Ask your manager why you can't switch to a better language. The answer is it's harder to find talent for it. Bingo.

That's a really good point.

IDK if I would say that about Scheme though. There are a lot more people around that know Scheme than know Common Lisp. I learned to program Lisp starting with Scheme; going back to Scheme from Common Lisp feels really disempowering.

So many programming languages. So much confusing choice and wasted effort.

What we need is for someone to be put in charge and consolidate all those programming languages in to one language.

The paradox of choice and duplication of effort are very real problems. Let's take web app development for example. We have PHP, Python, Ruby, Java, C#, etc. Each language has their own set of libraries/frameworks and it takes a lot of time and effort for a programmer to learn all of them. I've been developing web apps for 10 years and yet, I couldn't contribute to a web app written in Java. What if instead of having X libraries in Y languages, we had X*Y libraries for a single language or X libraries of Y higher quality for a single language?

Standardisation has lots of benefits.

The web standardised on HTTP/HTML/CSS/Javascript and it enabled the creation of a massive ecosystem of tools, libraries and pool of developers. Front-end developers can easily switch jobs and contribute to other projects. I personally dislike languages that compile to HTML/CSS/Javascript because I think standardisation trumps their benefits. C is a de facto standard in the embedded world.

In my opinion, sometimes the hammers are so similar (e.g. Python/Ruby) that we should just collectively agree to only use one.

He points out that with Linux you officially have the ability to customize everything perfectly, but spend a lot of effort just deciding what your stack will be. And if you integrate 4 or 5 things together, you get a lot of redundant crap because they did things differently.

In the C# world, by contrast, Microsoft declares technology winners and everyone adopts them. Those winners may be in principle not ideal, but the fact that everyone actually uses them saves a lot of wasted duplication of effort.

However the cost is no worse than the cost in the open source world of jumping on technology decisions that then wind up fading away and dying. And the fragmentation in the open source world makes that more likely.

Yes, in principle you can support open source software yourself. But you'd be amazed at the long term costs of doing so when you are locked in to a platform with diminishing market share.

We had almost reached the point where, notwithstanding any commercial licensing barriers, you could either still run application software natively, or it was so old that you could host a virtual machine containing the old OS within the new one. That's a great situation to be in if you rely on the software, and it's also a very nice situation if you write software, because it basically means that once you've got software that works it works forever. A firm foundation keeps everyone safe.

It's regrettable that under Ballmer and now Nadella they seem to have been pushing hard in IMHO the wrong direction with increasingly rapid updates and more reliance on inherently unstable on-line services, instead of playing to those traditional strengths. This makes Windows just as unlikely a prospect for long term stability as anything from Apple or the Linux world these days.

Personally, all I want is a system that I can buy today to do useful work and reasonably expect to still be doing useful work more than a year or two later. It's disturbingly difficult to find software that meets that apparently simple requirement any more.

Their mainframe family still runs most serious financial platforms around the world, and it is routine to run code written decades ago on the latest generation of hardware.

No, it is not cool. It is not sexy. It is not cheap.

But it is backwards compatible. With a vengeance.

There is a difference between being able to choose between 15 tools and being able to choose between 15 hammers. The point of the article is that we just don't need 15 hammers -- especially as 10 of those are obviously inferior -- and the existence of 15 hammers is incredibly unhelpful.

You're not going to need 15 hammers on a specific job (... for one person), but there are a lot of kinds of jobs in the world with particular needs.

I think the key phenomenon here is that software is non-portable by default, and portable through effort. If your problem is that the Linux code should use epoll() and the BSD code should use kqueue(), but OS X has quirks in its kqueue() implementation, and you need to fall back to poll() otherwise, autoconf will help... slightly. Then you need Sys V init scripts, or rc scripts, or launchd scripts, or... who even knows, unless you actually convince someone to port your project to that system.

So, you already have people testing and fixing bugs on other platforms, but now you tell them that they need to also learn M4 so they can write an Autoconf macro to test for some... thing... that you need which doesn't have a standard test. I'm not convinced that this makes my life any better.

Whether or not you like Autoconf, however, you have to agree that libtool has serious problems.

In my opinion, when possible, it is better to stuck to standards, and use just a Makefile for POSIX targets (it allows context detection) and a custom scripts or Makefiles for exotic platforms.

In the end, the reason for e.g. Autoconf, is the mess of different non-standard crazy stuff. Why not to agree a build standard base, at least for the C language and library handling?

Speaking as someone who was a system administrator responsible for compiling a large number of packages across a wide variety of platforms (let's see, SunOS, Solaris, AIX, Irix, Linux, and HP-UX, all at different versions at different times) through the '90s and early 2000s, autoconf made things much, much easier.

It doesn't help the developers any; each individual difference has to be identified by the developer. (My biggest complaint isn't that it's written in m4, but that there's no comprehensive list of what I need to do with it. That information makes up the m4 tests, but there was no documentation.)

Don't like libtool? http://www.fortran-2000.com/ArnaudRecipes/sharedlib.html

The bazaar model embraces the mess, believing that something spectacular will emerge. The cathedral model argues that coherence produces better results.

Both can point to successes. phk is arguing that the open source community has lost more than it has gained from accepting the bazaar as the one true way.

Even in the last ten years, where has the innovation in operating systems come from?

The CatB essay predates the book, and the idea predates UNIX.

As for libtool, anything that deals with shared libraries is inherently non-portable. The file extension they're created with and the compiler and linker flags to create them are entirely platform specific - POSIX won't help you there. (Also, a lot of libtool's hairyness exists because some older proprietary Unix systems don't support shared library dependencies.) If you're only planning on supporting open source OSes you don't actually need libtool though - their native toolchains are either the GNU one or something compatible with it, and include most of its functionality natively.

Compare POSIX to the Java spec: without Sun forcing coherence, "write once, run anywhere" would have died very early on, and we'd be saying the same thing about Java as you've just said about POSIX.

POSIX was just an example, and it is possible to write portable code using #ifdef. But you have to have a goal of writing portable code.

Re: libtool, most of the reason it's ever necessary is because of the historical rush and the incompatibilities created. Again, a single command line switch could handle that.

Still, plenty of software which has clearly only ever been built for Linux requires libtool. It's just the way things are done, just like autoconf. It works, poorly, inefficiently, fragile-ly -- and to most, mysteriously.

Appreciation for autoconf and libtool depends on one's position on the defeatism-pragmatism-idealism spectrum.

Yes, two ways. One way uses autoconf (and tests each individual option to see which branch of the ifdef to use) and the other uses Imake (and has a big, continuously maintained database of which option to use on each system).

So if you dropped SunOS, Tru64, HP-UX, IRIX, and AIX how many users would you use? How much of that configuration garbage would go away?