4 ms·

I disagree there pretty heavily. There are a lot of C implementations out there -- gcc, clang, msc, icc, keil, cscript, tcc, pcc, etcetc. The big reason C hasn'

I disagree there pretty heavily. There are a lot of C implementations out there -- gcc, clang, msc, icc, keil, cscript, tcc, pcc, etcetc. The big reason C hasn't turned into a similar Tower of Babel is that the various stakeholders in C recognize that it's a living language, and get together regularly to help work out methods that aren't useful anymore and add features to the specification to reflect what modern programmers want. If C had stopped standardization when ANSI C was released, you'd see a similar number of variants.

nickpsecurity 11y ago
The prior point still stands if you compare the number of LISP modifications... basically every program with macros + interpreters + compilers... to the few things you've cited which were often a lot of work and hard to change. GCC particularly. I agree the C crowd is more unified and that has huge impact. I'd go further to suggest that the legacy effect of UNIX and all the C libraries keep thing compatible. The C crowd is always sort of in maintenance mode for their language to keep everything working. While the LISP crowd rarely keeps anything and is often developing forms of the language. A subset are more practical with something long-term for real world use but most aren't. This difference between C use cases and LISP is worth exploring in answering these questions.
- lisper 11y ago
  > I agree the C crowd is more unified and that has huge impact. That's true, but it's important to understand which way the causality runs: the C crowd is unified because it's simply not possible to productive any other way. So C weeds out non-team-players in a way that Lisp doesn't.
  - nickpsecurity 11y ago
    That's a good point. Many suggested LISP needed that and would get more traction. Two example in that direction, Racket and Clojure, are kicking butt with one even mainstreaming. So, maybe major Schemes and CL's need to do that just a tad more.
    - deleted 11y ago
      [deleted]

nickpsecurity 11y ago

The prior point still stands if you compare the number of LISP modifications... basically every program with macros + interpreters + compilers... to the few things you've cited which were often a lot of work and hard to change. GCC particularly. I agree the C crowd is more unified and that has huge impact. I'd go further to suggest that the legacy effect of UNIX and all the C libraries keep thing compatible. The C crowd is always sort of in maintenance mode for their language to keep everything working. While the LISP crowd rarely keeps anything and is often developing forms of the language. A subset are more practical with something long-term for real world use but most aren't. This difference between C use cases and LISP is worth exploring in answering these questions.

lisper 11y ago
> I agree the C crowd is more unified and that has huge impact. That's true, but it's important to understand which way the causality runs: the C crowd is unified because it's simply not possible to productive any other way. So C weeds out non-team-players in a way that Lisp doesn't.
- nickpsecurity 11y ago
  That's a good point. Many suggested LISP needed that and would get more traction. Two example in that direction, Racket and Clojure, are kicking butt with one even mainstreaming. So, maybe major Schemes and CL's need to do that just a tad more.
  - deleted 11y ago
    [deleted]