Re: Mono and GNOME. The long reply.

[Drazen Kacar <dave arsdigita com>]

Miguel de Icaza wrote:

> * The CIL and the promise of language independence:

[...]

> 	So no longer should a software engineer pick Fortran, because
>     that is the only language where his math libraries are available:
>     he can now pick the right language for the problem at hand.

I do not think this will be such a great advance, at least not for
closed source software.

Consider: you're building some software. Regardless of the actual number
of programmers involved, the teams which do the job (or well-defined
parts) should be managable, so I doubt it will be more than 10 developers
on the single team and even that's a bit too much.

So these 10 people are working on something. The majority is using a
language with which everybody are familiar, but one guy is using Xyzzy,
this great new (or old) language. Nobody else knows anything about it.
Nobody else wants to know anything about it. But our Xyzzy guy is
productive, his code works well and all is fine.

Yeah, well, what happens when Xyzzy guy leaves the team? The schedule
slips. Badly. If the manager tries to get more people on the team, it will
slip even worse. (cf. The Mythical Man-Month).

Having one such person (or even two) on a team is a pretty high risk and
it would take a lot of management courage to start development with
that model. And finding management courage is even harder than finding
good software architects. I'd say a lot harder, but my experience is
limited. And I do not think it would be reasonable to take this risk,
so I'd tend to use the term lunacy instead of courage.

Having a lot of high-quality developers who could pull the trick of
developing in multi-language, multi-GUI or multi-whatever environment
makes the problem disappear, but it seems to me that the premise (a lot of
high-quality developers) is utterly unrealistic. Especially over a
prolonged period of time.

Now, language independence is great if you're going to take off the shelf
closed source component. No argument there.

I'm not entirely sure how it would fare with open source components.
Those are usually taken with much less scrutiny than the closed source
counterparts because, well, you can change something if you don't like
it. But if it's in a language with which you're not familiar (not our core
competense, in management speak), you get the same problems as in the
development model. If you change something, you probably get to maintain
it. Especially in closed source world, with all of its unrealistic
schedules and dubious quality control.

The time needed to make reusable component for something from the debugged
source which does that something (but is not a reusable component) is
huge. It's usually known as integration & debugging costs (yeah, you get
to debug it again if you change it to become something else). And there
are quality control issues and the time needed for that. Basicaly, changing
software takes time and that costs money. Trying to do it in when you're
not too familiar with the thing is rather risky.

For free software the idea fares much better if the gods of probability
are on your side. That is, if there is a large enough community around
something, so you can reasonably assume that somebody else will take to
work on a piece of software in case the original developer leaves.

I think the companies which are excited with the language independence can
be categorized in two groups:

  1. Those whose core competence is a non-mainstream language
  2. Those who don't have enough experience with Unix.

And there is the free software world, which can only benefit from
something like this. But that doesn't necessarily include free software
companies.

-- 
 .-.   .-.    I don't think for my employer.
(_  \ /  _)
     |        dave willfork com
     |