4 ms·

And yet..I think this critique gets less strong as time goes on. The amount of productivity available to Mr. Kamp for free today is conservatively double or tr

And yet..I think this critique gets less strong as time goes on. The amount of productivity available to Mr. Kamp for free today is conservatively double or triple that available in 1999. Databases, web frameworks, scale know-how, IDEs, hosting platforms, the list goes on. He harkens back, sadly, to an era in which codebases like Genuity Black Rocket cost $100k in licensing, and ran on $30k/month Sun servers. Seriously. Languages are faster, development times are shorter, and chips are WAY faster. And, code can be pushed out for tinkering and innovation onto github for free. Combine that with his estimate that we have 100x more people in computing, and the combination is a riot of creativity, crap, fascinating tech and everything in between. The bazaar is messy, but I'm not aware of any solid critiques which show cathedrals are more efficient at the multiples-of-efficiency kind of gains we get from legions of self-interested, self-motivated coders.

_bpo 10y ago
> Languages are faster, development times are shorter, and chips are WAY faster. This is due to Moore's law, not the software design choices that the article bemoans. Those $30k/month Sun servers were many times faster and cheaper than the earlier machines they replaced as well.
- vessenes 10y ago
  While Moore's law helps, languages are more expressive, safer, more performant and have more batteries included yielding a whole bunch of improvements. We've had software and hardware gains, massive ones, and they compound.
  - SolarNet 10y ago
    > While Moore's law helps, languages are more expressive, safer, more performant and have more batteries included yielding a whole bunch of improvements. I have to disagree, compilers may have gotten a bit better at making faster binaries. But languages, like new languages, are increasing in expressiveness and safety, sure, but very rarely efficiency. Go and Rust are not faster than C or C++, likely never will be (for one C has decades of lead time), Go and Rust may be faster than C was 20 years ago, but that doesn't matter.
    - steveklabnik 10y ago
      If Rust is significantly slower than equivalent C or C++, it's a bug. Please file them. (And yes, sometimes, it's faster. Today. Not always! Usually they're the same speed.)
      - SolarNet 10y ago
        My point is more like this chart [0]. C has so much lead time, Rust will probably never be able to catch up, be close? Sure. But C has decades of lead time. [0] http://www.viva64.com/media/images/content/b/0324_Criticizing-Rust-Language-Why-Cpp-Will-Never-Die/image1.png http://www.viva64.com/media/images/content/b/0324_Criticizin...
        steveklabnik 10y ago
        That chart is extremely old. We are sometimes faster than C in the benchmark games, with the exception of SIMD stuff due to it not being stable yet. (and, it can fluctuate, depending on the specific compiler version, of course.) For example, here's a screenshot I took a few months ago: http://imgur.com/a/Of6XF http://imgur.com/a/Of6XF or today: http://imgur.com/a/U4Xsi http://imgur.com/a/U4Xsi Here's the link for the actual programs: http://benchmarksgame.alioth.debian.org/u64q/rust.html http://benchmarksgame.alioth.debian.org/u64q/rust.html Today, we're faster in C than one program, very close in most, and behind where SIMD matters. > But C has decades of lead time. Remember, Rust uses LLVM as a backend, which it shares with Clang. So all that work that's gone into codegen for making C programs fast also applies to Rust, and all of the work Apple and whomever else is working to improve it further, Rust gets for free.
        SolarNet 10y ago
        I mean true, I'm playing devil's advocate here. I respect the Rust community (heck of all the nu-c languages I respect it the most, I even did a poster on 0.1 of it for my programming languages class), I will be quite impressed if they can pull off (and they are the most likely to be capable of it in my opinion) what so far has been an insurmountable task: beat an old guard language in general purpose performance (Fortran, C, etc.); languages that have every advantage but design foresight. If they do it, it will be a great historical case study on how to build a new programming language. As an aside: As someone who has used LLVM to build a compiler, it doesn't quite work that way, yes rust has access to those gains, but it may not be able to effectively use them (due to differing assumptions and strategies).
  - TeMPOraL 10y ago
    > languages are more expressive, safer Not generally, no. Maybe the popular ones become so, but that's mostly by rediscovering the languages of old, which had better safety and more expressive power.
- GFK_of_xmaspast 10y ago
  Moore's law is just an observation, and the only way chips can actually be made is through sustained, coordinated, and meticulous teamwork.
dkarapetyan 10y ago
How many of those languages were developed in the bazaar style? All the ones I can think of came from a single person designing things from first principles and taking inspiration from other cathedrals around them. Lisp, Scala, Ruby, Smalltalk, Prolog, Typescript, etc. are cathedrals. The one bazaar IDE I can think of is Eclipse and it's terrible. Visual Studio and Visual Studio Code on the other hand are much more sensible and again it's because they're cathedrals.
- jdminhbg 10y ago
  Another bazaar IDE is Emacs, and I'd say it's not terrible, although YMMV. I'm not sure how you can say Lisp is a cathedral; it's not even "a" anything. Common Lisp, Racket, Clojure, Emacs Lisp, etc., many of which are themselves bazaars. Ruby, for another example, may have started as one person's vision, but now the canonical implementation is a big multisourced effort, and there are other implementations with lots of uptake that aren't directed or blessed by the mainline Ruby.
  - TeMPOraL 10y ago
    Cathedral is never built by one person. It's not even entirely designed by one person. But you have people responsible for quality, instead of "anything goes" ad-hoc development. You mentioned Common Lisp - it's a great example of a cathedral. A language carefully designed by a committee, which took into consideration all the previous Lisps that were in popular usage. You can tell there was a lot of thought behind the process. As for Emacs and the bazaar, I think this is a good case study of good and bad aspects of bazaars. On the one hand, you have an incredibly flexible tool, which turns it into a perfect test environment optimizing workflow with text-based tasks. You have people writing Emacs modes for anything including kitchen sink, and it turns out many of those experiments offer superior workflow than standard, dedicated applications (especially when it comes to interoperability and maintaining focus/flow). On the other hand, Emacs often requires you to hot-patch stuff here and there, and its language support is usually worse than that of a cathedral-like IDE dedicated to a particular programming ecosystem. And I say it as an Emacs lover. I still prefer Emacs to IDEs, but that's because of the flexibility benefits, which are unparalleled. But I'm not deluding myself that Emacs has better support for Java than IntelliJ, or better support for PHP than Eclipse, or whatever. For language ecosystems requiring complex tools to back them up, it's a PITA to set up your working environment in Emacs. Hence the negative side of bazaar - you don't get as much focused effort to make something of high quality.
ckastner 10y ago
> The bazaar is messy, but I'm not aware of any solid critiques which show cathedrals are more efficient at the multiples-of-efficiency kind of gains we get from legions of self-interested, self-motivated coders. The article isn't about efficiency, it's about quality. The assertion is "Quality happens only when someone is responsible for it."

_bpo 10y ago

> Languages are faster, development times are shorter, and chips are WAY faster. This is due to Moore's law, not the software design choices that the article bemoans. Those $30k/month Sun servers were many times faster and cheaper than the earlier machines they replaced as well.

vessenes 10y ago
While Moore's law helps, languages are more expressive, safer, more performant and have more batteries included yielding a whole bunch of improvements. We've had software and hardware gains, massive ones, and they compound.
- SolarNet 10y ago
  > While Moore's law helps, languages are more expressive, safer, more performant and have more batteries included yielding a whole bunch of improvements. I have to disagree, compilers may have gotten a bit better at making faster binaries. But languages, like new languages, are increasing in expressiveness and safety, sure, but very rarely efficiency. Go and Rust are not faster than C or C++, likely never will be (for one C has decades of lead time), Go and Rust may be faster than C was 20 years ago, but that doesn't matter.
  - steveklabnik 10y ago
    If Rust is significantly slower than equivalent C or C++, it's a bug. Please file them. (And yes, sometimes, it's faster. Today. Not always! Usually they're the same speed.)
    - SolarNet 10y ago
      My point is more like this chart [0]. C has so much lead time, Rust will probably never be able to catch up, be close? Sure. But C has decades of lead time. [0] http://www.viva64.com/media/images/content/b/0324_Criticizing-Rust-Language-Why-Cpp-Will-Never-Die/image1.png http://www.viva64.com/media/images/content/b/0324_Criticizin...
      - steveklabnik 10y ago
        That chart is extremely old. We are sometimes faster than C in the benchmark games, with the exception of SIMD stuff due to it not being stable yet. (and, it can fluctuate, depending on the specific compiler version, of course.) For example, here's a screenshot I took a few months ago: http://imgur.com/a/Of6XF http://imgur.com/a/Of6XF or today: http://imgur.com/a/U4Xsi http://imgur.com/a/U4Xsi Here's the link for the actual programs: http://benchmarksgame.alioth.debian.org/u64q/rust.html http://benchmarksgame.alioth.debian.org/u64q/rust.html Today, we're faster in C than one program, very close in most, and behind where SIMD matters. > But C has decades of lead time. Remember, Rust uses LLVM as a backend, which it shares with Clang. So all that work that's gone into codegen for making C programs fast also applies to Rust, and all of the work Apple and whomever else is working to improve it further, Rust gets for free.
        SolarNet 10y ago
        I mean true, I'm playing devil's advocate here. I respect the Rust community (heck of all the nu-c languages I respect it the most, I even did a poster on 0.1 of it for my programming languages class), I will be quite impressed if they can pull off (and they are the most likely to be capable of it in my opinion) what so far has been an insurmountable task: beat an old guard language in general purpose performance (Fortran, C, etc.); languages that have every advantage but design foresight. If they do it, it will be a great historical case study on how to build a new programming language. As an aside: As someone who has used LLVM to build a compiler, it doesn't quite work that way, yes rust has access to those gains, but it may not be able to effectively use them (due to differing assumptions and strategies).
- TeMPOraL 10y ago
  > languages are more expressive, safer Not generally, no. Maybe the popular ones become so, but that's mostly by rediscovering the languages of old, which had better safety and more expressive power.
GFK_of_xmaspast 10y ago
Moore's law is just an observation, and the only way chips can actually be made is through sustained, coordinated, and meticulous teamwork.

dkarapetyan 10y ago

How many of those languages were developed in the bazaar style? All the ones I can think of came from a single person designing things from first principles and taking inspiration from other cathedrals around them. Lisp, Scala, Ruby, Smalltalk, Prolog, Typescript, etc. are cathedrals. The one bazaar IDE I can think of is Eclipse and it's terrible. Visual Studio and Visual Studio Code on the other hand are much more sensible and again it's because they're cathedrals.

jdminhbg 10y ago
Another bazaar IDE is Emacs, and I'd say it's not terrible, although YMMV. I'm not sure how you can say Lisp is a cathedral; it's not even "a" anything. Common Lisp, Racket, Clojure, Emacs Lisp, etc., many of which are themselves bazaars. Ruby, for another example, may have started as one person's vision, but now the canonical implementation is a big multisourced effort, and there are other implementations with lots of uptake that aren't directed or blessed by the mainline Ruby.
- TeMPOraL 10y ago
  Cathedral is never built by one person. It's not even entirely designed by one person. But you have people responsible for quality, instead of "anything goes" ad-hoc development. You mentioned Common Lisp - it's a great example of a cathedral. A language carefully designed by a committee, which took into consideration all the previous Lisps that were in popular usage. You can tell there was a lot of thought behind the process. As for Emacs and the bazaar, I think this is a good case study of good and bad aspects of bazaars. On the one hand, you have an incredibly flexible tool, which turns it into a perfect test environment optimizing workflow with text-based tasks. You have people writing Emacs modes for anything including kitchen sink, and it turns out many of those experiments offer superior workflow than standard, dedicated applications (especially when it comes to interoperability and maintaining focus/flow). On the other hand, Emacs often requires you to hot-patch stuff here and there, and its language support is usually worse than that of a cathedral-like IDE dedicated to a particular programming ecosystem. And I say it as an Emacs lover. I still prefer Emacs to IDEs, but that's because of the flexibility benefits, which are unparalleled. But I'm not deluding myself that Emacs has better support for Java than IntelliJ, or better support for PHP than Eclipse, or whatever. For language ecosystems requiring complex tools to back them up, it's a PITA to set up your working environment in Emacs. Hence the negative side of bazaar - you don't get as much focused effort to make something of high quality.

ckastner 10y ago

> The bazaar is messy, but I'm not aware of any solid critiques which show cathedrals are more efficient at the multiples-of-efficiency kind of gains we get from legions of self-interested, self-motivated coders. The article isn't about efficiency, it's about quality. The assertion is "Quality happens only when someone is responsible for it."