Hacker News Reader

Comment by doktrin | Hacker News Reader

According to phkamp, iOS is a cathedral kind of project.

This is true. The OP has made several somewhat-arbitrary and vague assertions about what may or may not constitute a "Cathedral", on top of lambasting others for not agreeing with his definition ("Read Brooks Book")

Excerpts from the HN discussion :

"Windows and Office are actually not examples of cathedrals, because the architectural focus of Microsoft was not on software but on a near-monopoly market." -phkamp

"...iOS is very much a Cathedral and has a designer and architect who cares and who is in control." -phkamp

Does Apple not care about achieving market dominance? Did no version of Windows or Office have a lead architect who "cared"?

Frankly, the entire concept of a "Cathedral" - rigidly defined as it appears to be here - is a little nebulous and hand-wavy.

View on HN

You never read ESR's essay/book, did you ?

I read ESR's essay. He was protesting how hard GNU makes it for outside contributors such as himself. Somehow the essay got construed as open source vs. closed source, and ESR pivoted to align with the popular interpretation of his essay. I've never read the book (someone would have to give me a really good reason), but I assume it doesn't focus on GNU.

You're calling a ot of people out on using Microsoft as a cathedral example, so I assume you want the original bazaar-vs-cathedral reading of the paper. But if you do that, how can autoconf be a bazaar example, when it's GNU software?

In a world where software is designed by cathedrals, there is no need for autoconf. You read the POSIX spec and write software that conforms to it.

That is true. But the article decries autoconf's implementation, not just the need for it. It implies that cathedral designers would never implement it, or if they did implement it, do a better job.

I suppose this is the essence, because however much he may chaff at autoconf's implementation (and it surely is ugly), it actually works pretty well. Users (in this case, "user" = "developer") never see the ugliness for the most part.

With more open development communities there are tradeoffs, but often the result is that you can do stuff you simply wouldn't have the manpower to do in closed communities.

I think most of us would love it if every library and tool we used was pretty and elegant, but in the end, it's often better to have something, however much you'd ideally wish for it to be prettier.

Morever, a community in which different components are often the result of disparate teams with different thinking probably results in more attention paid to robust and simple interfaces between them, simply because that's the only way you can get everything to work. Systems composed of heterogeneous components with robust and simple interfaces between them, are, I think, a good thing. I suspect they tend to be more future proof than systems with everything designed by one person from the top down, because in the end, change is inevitable, so having to deal with heterogeneity from the beginning is an advantage.

No stop it! Don't defend autoconf, it is not worth it and the software does not deserve it. Users of autoconf, that is developers that try to use that POS to build their software definitely experiences its pains.

It is not just that M4 is a horribly ugly, badly, inconsistent language. You also have about a million leaky caches in the build process to deal with. Autoconf rewrites the build scripts in three stages, each which is cached and also keeps an autom4te.cache directory around. So what happens is that you update something in the M4 build script and then have to spend hours hunting down why the change didn't change anything because some stupid autoconf cache wasn't flushed.

What autoconf has done is to separate free software developers into two categories. Those who can hack the source (the .c and .h files) and those who understand the "autoconf magic." It should be telling that people refer to it as "magic" - it's a fing build system, not rocket science.

The only reason this ugly piece of software has lived on is because people treat it as some kind of magical device and inertia. Configuring and building software is an easy problem. It gets even easier if you finally decide to drop support for 30 year old unices that no one uses. The autoconf team consistently refuses to do that which why the software wont ever become better.

CMake, SCons, Waf and probably half a dozen more tools all do a much better job configuring software than autoconf ever will. People really need to try those alternatives and I'm sure they will realize autoconf needs to die, die, DIE.

Shrug. You don't like autoconf, great; that's clear. As a user of it, I think it's sometimes ugly, but basically fine for its intended purpose (easing portability amongst POSIX-compatible systems). [If you like Windows, you're probably outside its target audience.]

CMake, SCons, etc, all have their pros and cons. They are hardly paragons of virtue though. [Yes, even as a mere "consumer" of CMake (someone who occasionally needs to build packages that use it), I've been bitten and frustrated by it.]

As far as I've found, there really isn't any build tool that really gets everything right -- which suggests that the problem is harder than you suggest. [Although judging from the number of people who try to write their own build tool (most of which languish and eventually die, but cause some pain along the way), it's clear enough that many people think it's a simple problem...]

> autoconf needs to die, die, DIE

Decaf?

You sound a lot like my colleagues when I tell them why I much favor dynamic languages like Ruby and Python over Java. :) They listen politely to my arguments, then shrug their shoulders and go "meh, Java works fine for me". CVS users are the same when it comes to Subversion users who are the same when it comes to Git users.

It doesn't matter for a "works fine" person how many faults their current tool has or how much smoother "your" tool solves all those problems, they won't listen. Logic doesn't work maybe because it is very hard for them to get used to something new. Maybe because if you haven't experienced any alternatives it is very hard to imagine that something could be better.

Reply on news.ycombinator.com