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).
···
On Jun 7, 2006, at 6:25, Francis Cianfrocca wrote:
