Common Lisp would probably be the best counter-example to "language design by committee doesn't work." Despite being developed by a committee over an almost 15 year period and the standard document being over 1000 pages long and full of functions that are there just for backwards compatibility, the language manages to be both more consistent and feature rich than Ruby or Python.

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.

Common Lisp, C and C++ did not contribute to the field in the enormous way that Scheme, Haskell and Smalltalk did. They're sheeple languages (made with the worker in mind) to control employees, and not languages to empower and liberate the programmer (like Forth, another great example of an experimental language by Chuck Moore).

My point stands.

> They're sheeple languages (made with the worker in mind) to control employees,

Total nonsense.

> and not languages to empower and liberate the programmer

Also nonsense.

If you want to refute you will have to do better than just show up; you could start by explaining why do we have so many shops using Java and .Net and now Rails (which makes it possible for Ruby programmers to be fungible for managers) and so few using Scheme and Smalltalk etc.

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

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

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.