On Jun 7, 2006, at 6:25, Francis Cianfrocca wrote:

> Large problems: you're playing word games with me. "Large" has many
> meanings. Two that are germane to my point are: information systems  
> with an
> extremely long anticipated lifetime (meaning that it's unwise to  
> expect the
> original developers to stay committed to it), and systems that cut  
> across a
> large number of knowledge domains in a single organization (meaning  
> you
> can't leverage the expertise of a world full of developers). A lot of
> resources go into solving problems that are understood along these  
> lines,
> and a lot of those resources get wasted. THAT is a problem that's  
> worth
> solving. Ruby could be part of the solution, if more of the  
> community were
> interested in the problem.

I think it's important to remember that you're talking about a  
distinct class of businesses; businesses that are too big and varied  
to buy off-the-shelf software, but who aren't involved in full-time  
software development (and either staff-up or contract-out as needed  
on a project-by-project basis).  It's a very large class of  
businesses, I admit, quite likely it's the large majority of the  
available market for programmers, but it's not all businesses, which  
will be important later on.


In any case, it's interesting that you think these are problems which  
are solvable via language design (or by a particular language).  If  
you ask me, they're problems of management; I'll split up my analysis  
below.

1: long lifetimes.

For small values of "long" (say, 5-10 years, though this will vary by  
domain) the language will have some impact - languages which  
encourage self-documentation will have a slight advantage over  
languages which don't, given similar standards and practices within  
the organisation, but it's those standards and practices which will  
have the largest impact.  This is a problem of management and  
engineering, the realm of specifications and documentation and  
requirements; it's essentially language-agnostic.

For medium values of long, your implementation is going to become  
obsolescent, especially if you don't periodically renovate/ 
reimplement it.  I expect this to be less of an issue between now and  
2030 than it was, say, between 1975 and Y2K, but I believe there's a  
very solid economic reason to that obsolescence is the norm (which  
I'll briefly discuss below), regardless of your choice of language.

For big values of long - your guess is likely as good as mine, but  
I'd pick Lisp.  Four decades and still going strong.

2: organisation-specific knowledge.

Again, this is primarily an issue of management; it includes system  
design and specification, organisational history, and also the  
retention of those individuals who incorporate that knowledge.  If  
those processes fail, there's little that the choice of language can  
do to compensate for that.

> Advocacy: you make a compelling point that the advocacy around Ruby  
> is part
> of the more general enthusiasm for agile development and dynamic  
> languages.
> Well and good, so long as your focus is on computer programs as
> beautifully-crafted artifacts. But this advocacy is largely  
> meaningless
> several steps higher, where decisions are made about which computer  
> programs
> to fund the development of. A different kind of advocacy is  
> required there,
> and it's becoming clear to me that Ruby advocacy probably doesn't  
> belong at
> that level.

And there's the big disconnect: management decisions are made for  
economic reasons, not purely technical ones, and there are big  
economic factors throwing their weight around:

First: [Freely-available] Computer languages and their associated  
libraries approximate public goods (I am aware of theoretical nits  
that might be picked with this assertion).  From a business  
perspective, they represent a positive externality; businesses  
benefit from the production of these goods ("language design") while  
contributing little to it.  Typical profit-motivated businesses  
either can't afford or wouldn't be willing to fund language design  
simply to support their own projects, they instead rely on  
individuals with significantly different economic motivations to  
design these languages and libraries.

The catch is that unlike typical examples of beneficial externalities  
in business (e.g. the road network), languages can change at a pace  
faster than or comparable to the business itself.  This is one reason  
why projects tend towards obsolescence: current languages evolve,  
their libraries change, deprecation ensues (Java), some fall out of  
fashion (COBOL, Fortran), new languages are created (Perl, Python,  
Ruby), some come back into fashion (Lisp), and so on.  In the  
maintenance phase of its life-cycle, your system is essentially  
static with respect to this churn.  Without a direct involvement in  
the process of language design - which the typical business doesn't  
pursue - the odds are very much higher that your system will be left  
behind.


The second big economic gorilla is the fact that for a certain type  
of production - into which most 'enterprise' software falls - profit  
is maximised at the expense of efficiency.  If someone using  
technically-sophisticated methods to accomplish a project should  
leave, the cost of replacing them (basically, the time it takes to  
find someone with equivalent knowledge + the time it takes the  
replacement to get up to speed with the existing work/start over) is  
quite high, but such methods are more efficient and will get the job  
done faster.  On the other hand, it's easier to replace people  
working using less sophisticated methods, but such methods are less  
efficient and the project will take longer.

Accounting for this risk/efficiency trade-off, profit ends up getting  
maximised somewhere in the middle of the efficiency spectrum - a  
middle currently occupied quite comfortably by Java and .NET.   
"Business acceptance" in this regard is highly correlated to 'dumbing- 
down' the language to make it more suitable for less-skilled (rather,  
de-skilled) labour.



> The original topic of this thread was Ruby's future. It may be
> that Ruby's future is all about projects that are undertaken for  
> love, not
> money. And there's nothing wrong with that.

You may be right, but I'm willing to bet that you're only right  
insofar as you mean *your* money.

The economic motivations of businesses mentioned above are often  
contrary to the economic interests of the programmers they employ.   
Where businesses have a motivation *not* to invest in the production  
of public goods such as languages and libraries, programmers do have  
such motivation; both in a higher value on non-monetary reward  
(typical in particular of language developers), and as a method of  
ensuring that they don't have to pay to practice their trade[1].   
Where businesses have a motivation towards average, simple systems,  
programmers (on the whole) would prefer working on interesting and  
sophisticated ones, again both for monetary reasons (better pay or  
the strong likelihood of better pay in the future) and non-monetary  
ones (intellectual stimulation and less chance of terminal ennui in  
the future).

Recent changes in the programming industry have meant that  
programmers can now pursue their own economic interests more freely,  
instead of relying upon "business acceptance" for economic security  
(and the associated compromise of their own interests).

Opportunities to pursue technically-sophisticated projects have grown  
enormously: from Google's Summer of Code to a few paid hours a week  
at your usual job to contribute to an open-source project, to grants  
and full-time employment on open source projects.  In the private  
sector, Google, Microsoft, NTL, and IBM all have well-funded and  
diverse research divisions.  I'd say that even academic opportunities  
are improving (this is harder to quantify, since it occurs over  
longer periods, though certainly industry-associated funding is  
rising).  It's feasible to say that this class of businesses has  
benefited from aligning their interests with the programmer's  
interests, rather than forcing it the other way around.

And as a result, "business acceptance" in its traditional sense is  
becoming less relevant to language design because typical businesses  
are contributing less to language design; essentially nothing in  
direct terms, and even their marginal contribution of providing jobs  
to direct contributors (i.e. jobs not involving those contributions)  
is proportionally lower than it ever has been.


matthew smillie.



[1] Take the hypothetical situation where a company requires as part  
of their license terms that everyone programming with their language  
and/or library holds a certification (which only they provide).