The Joel on Software Discussion Group

Joel> there are three and a half platforms (C#, Java, PHP, and a half Python)

HAHAHAHAHA~! I loved that!

But it really is so true!

Why would you take risks?

Joel - You've got a great sense of humor!

It's a risk where the payoff could be larger than you would achieve otherwise.

Consider investing.  You can invest in a Money Market, a CD, or US Treasury bonds.  Great.  Standard and solid choices.  No one ever got fired for picking CDs.

Of course, investing in a Hedge Fund is considerably riskier.  But if you take that risk, you can end up with a return 4-10 times greater than your safe, standard options.

The question should be - do any languages/platforms provide enough added upside that the risk is worth evaluating.

>>The question should be - do any languages/platforms provide enough added upside that the risk is worth evaluating.<<

That's the big question and the problem with it is that it is a huge catch 22. You don't really know if there is enough upside until you do the evaluation. In most large coporations that is compounded by two other problems.

1) If you have legacy stuff you still need to run, you at the very least need to interface with that. You can't ever really start from scratch. Any new thing you think about evaluating has to work within that context. If it doesn't, no matter how good it is, you can't use it.

2) The people picking the languages and platforms may not have any reason for choosing anything other than the safe alternative because they may not really know enough about technology to contemplate any other choices in the first place.

The Dabble DB people thought so, or maybe they didn't evaluate at all. Dabble DB is written in Smalltalk with Seaside, which is probably even less 'mainstream' than doing web development in Common Lisp.

I'm really not sure that a company that wrote their own VBScript-to-PHP converter (setting aside the Wasabi thing...) really needs worry that they won't be able to make do with a given obscure language.

There is no huge relative upside to any language.  That's the point of Joel's article, as I understand it.  It's not like in investing, where if you take a big risk you might hit it out of the park.  At best, you are rewarded with small incremental improvements over predecessors, PLUS all the cost of switching to a new language.

We're talking about modern, interpreted languages, not comparing Ruby with Assembly or something absurd like that.  Realistically, you might go from 20 LOC/day to 25 LOC/day, not some order of magnitude increase.

Has anyone ever measured the productivity increase from switching to a new language?  It would probably be pretty hard to remove all the other variables and come to a real meaningful conclusion.  Your observations might even defy expectations: without an existing community, lots of tools, and existing code to reuse, switching to the latest language could, in many cases, be a step *backwards* in terms of productivity, at least until the language becomes "mature."  Then we can start the cycle all over again. :)

"Realistically, you might go from 20 LOC/day to 25 LOC/day, not some order of magnitude increase."

I have 201 Principles Of Software Development sitting here...

No, I don't. I took it home. Shoot...

There's a principle in there saying (based on research from the 80's or earlier, AFAIK) that speed of coding seems to be about constant by lines of code, across all languages.

This is surprising, but it does mean that (on average) productivity scales with the kind of code brevity offered by a language.

Don't confuse productivity with the speed of coding.  The ability to write reams of code in the blink of an eye is meaningless if nobody else can then read and understand it.

This is why abstraction is more important than abbreviation.

I won't speak for Jesse, but I don't believe he made any statements about abbreviations. It seems to me he was talking about expressiveness of each line of code. C, Perl, and JavaScript tend to be more expressive per line than COBOL, Ada, and RPG. They do more for the same number of lines because of the language design, not because people writing Perl sometimes abuse the brevity of some built-in variables.

It's true that readability is more important than the raw character count. A program which has its source in fewer lines of clearly written code is easier to understand than a program which has soruce in more lines of clearly written code. A program which sacrifices clarity for brevity may lose that advantage, and often they do.