4 ms·

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 n

by doktrin 14y ago

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.

phkamp 14y ago
You never read ESR's essay/book, did you ?
- brlewis 14y ago
  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?
  - tedunangst 14y ago
    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.
    - brlewis 14y ago
      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.
      - snogglethorpe 14y ago
        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.
        bjourne 14y ago
        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.

by doktrin 14y ago

phkamp 14y ago

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

brlewis 14y ago
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?
- tedunangst 14y ago
  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.
  - brlewis 14y ago
    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.
    - snogglethorpe 14y ago
      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.
      - bjourne 14y ago
        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.