That's just talk. Dynamic language usage will continue to grow, regardless of what this guy thinks; the boosts in productivity will make sure of that. If a powerful language is a dangerous tools, I find it hard to explain the plethora of software written in the C language, which is definitly more dangerous than Ruby.

"it's all about just how much productivity you are willing to sacrifice in the name of presumed safety"
It's all about presumption: presumed productivity, presumed safety, presumed cause (static/dynamic whatever we presume that means).

A decade ago Richard Gabriel reined in his presumptions

"Only some aspects of programming languages will matter for productivity but not by more than 30% better or worse. My experience with C++ development started with a group just learning C++ and ended with quite an expert group. At the start I estimated the productivity advantage of Lisp/CLOS over C/C++ at a factor of three to four; at the end I set it at 30%.
p128 Patterns of Software (1.2 mb pdf)

Vincent That's just talk
Saying "the boosts in productivity will make sure of that" is just talk!
David Buck's latest post is just talk!

There's no attempt to show that X really is more productive than Y for some task Z (let alone demonstrate that the presumed productivity results from absence of explicit type declarations rather than presence of higher level constructs or IDE functionality or reusable frameworks).

hard to explain... C language, which is definitly more dangerous
It's simple enough: YOU may be good enough to be disciplined enough to keep the rules of your C in your head... A C programmer might say 'C provides power that most people just can't handle' or 'it's all about just how much programmer freedom you are willing to sacrifice in the name of presumed safety' - programmer ego trumps program quality.

Comment by James Robertson

Isaac - a 30% productivity loss by moving to C++ is significant all by itself. Try reading what you write.

James Try reading what you write
Insulting other people just makes you look bad.

As VW product manager I had hoped you might understand that there are many many C++ projects and only a few Smalltalk projects, and the goal is to increase the number of Smalltalk projects.

The problem has always been that a 30% productivity gain isn't enough to promote change from C++ to Smalltalk, because that gain is swallowed by initial training and the reduced productivity of Smalltalk novices compared to C++ experts.

Comment by James Robertson

My point there was that a 30% productivity drop demonstrates that the move from Lisp to C++ was a mistake.

James a mistake
From the quotation we do not know

• that there was a switch from Lisp to C++
• the motivation for using C++

As the reason for using C++ is unknown, claiming it was a mistake is just more baseless presumption.

Comment by Michael Lucas-Smith

Isaac it isn't a baseless assumption. It's an opinion.

Michael, I'm unsure what particularly you are referring to by "it". I am sure that the grounds for an opinion can be baseless assumption.

Comment by James Robertson

Apparently, only other people's opinions can be based on baseless assumptions.

James, please move beyond ad-hominem innuendo and make a specific criticism.

Comment by James Robertson

I seem to recall that it was my opinion that was labeled a "baseless assumption".

"a 30% productivity drop demonstrates that the move from Lisp to C++ was a mistake"
What basis do you have for your opinion that the project moved from Lisp to C++?
What basis do you have for your opinion that "a 30% productivity drop demonstrates that... was a mistake" (Do you know whether the project goals were achieved?)

Comment by James Robertson

Seeing as how 30% is significant, IMHO, I call the migration a mistake. That's what's called an opinion. Yours differs, but that doesn't make mine baseless. It makes it different

but that doesn't make mine baseless
This isn't about a difference of opinion about a project, it's about being able to show what an opinion is based on - it's about being able to show that an opinion is based on information rather than assumption.

You've given an opinion about a project.
I've repeatedly claimed that the snippet of information about the project isn't enough to support that opinion, and repeatedly challenged you to show the connection between that opinion and the information - so far, you have not tried to show a connection.

If your opinion is based on the quoted information then you will have no difficulty pointing out where Richard Gabriel states that the project migrated from Lisp to C++, and where he states that the project was a failure (or would have been more successful if Lisp had been used instead of C++).

Comment by James Robertson

Which part of "30% less productive" is hard for you to follow?

Comment by David Buck

Richard Gabriel didn't talk about any migration. He talked about working with a team of LISP developers learning C++.There didn't seem to be a migration discussed (unless I missed it).

Here's a quote:

The Lisp guys who were turned into C++ developers suffered about a factor of three decline in productivity for about the first six months to a year, which improved to only about a 30% loss in the steady state.

James Which part of "30% less productive" is hard for you to follow?
Richard Gabriel gave an estimate that the productivity advantage of Lisp/CLOS over C/C++ was 30% - so far so good - whether that is significant is another matter (see October 05, 2005 16:14:21 EDT)

James My point there was that a 30% productivity drop demonstrates that the move from Lisp to C++ was a mistake.
There was no project migration from Lisp to C++ he's writing about Lisp programmers who were offered work on a C++ project.
As there was no move, "the move" cannot have been "a mistake".
Baseless assumptions: "the move" and 'the mistake'.

The real mistake was the company trying to jump on the C++ bandwagon and build a C++ development environment. Maybe they weren't doing so well with Lisp at AI winter time, but they burned up the capital trying to build what couldn't be built (a lisp machine in C++ for C++)

Well, if we introduce a single anecdote and try to extract broad meaning from it, we're definitely going to involve a bunch of presumptions.

Gabriel was starting with a team that already knew Lisp and CLOS. There's a big presumption I'm surprised everybody missed above: the presumption that that's anything close to a typical team.

I know for sure that my knowledge of other (less painful) languages has made me a better C++ developer. Perhaps, in the most extreme case, the team in question figured out a way to get around the annoying static type-checking, in which case the anecdote (which is still not the singular of data) is completely irrelevant.

In short, James should really never have brought up the Gabriel anecdote, since it doesn't shed much light on things unless you make some very questionable presumptions. Oh, wait....