Re: How come Ada isn't more popular?

[Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de>]

Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:

> I admit I'm not completely sure how all that fits together. But the
> perception that it is C vs. Ada is IMHO wrong. That particular fight

To complement that: My impression (which I've already expressed in one
those mails that went into the black hole), is, that a number of
protagonists arguing for Ada here in this thread, argue as if Ada was
the famous silver bullet of software engineering.

But as we all know (or should), that is not true:

 - There is no silver bullet.

 - The development process has a lot of influence on the quality of
   code produced.

 - You cannot just compare languages: You need to compare the language
   in the context of existing culture / community and the market of
   tools provided for that language and the quality of thos tools.

 - There is no way to get really high quality code w/o a formal code
   review.


So now, that the pressure is of to take Ada under every circumstance
and we have recognized that Ada is just one of many factors
contributing to quality and competitiveness of a project, we are
perhaps open to see why some project might decide (have decided)
against Ada or for that against any "exotic" language for purely
economic reasons.

Just one more consideration: It might be true that Ada avoids costs in
the long run. This doesn't help if the project has a limited budget
and the primary consideration need to be to get the initial up front
costs (tools, training) below a certain limit.

We have to scenarios:

  1. Aim for high quality, spent a lot of money at the beginning for tools and
    training, but after longish preparations bring a product into the
    market which has hardly any bugs and doesn't cost much maintaining.

    Now you can have 

       (a) Success: All customers buy your product, install it and
           finally forget you, since the product works flawlessly.

       (b) Failure: Product doesn't fly. The users don't like
           it. You've lost lots of money.


  2. Aim for acceptable quality (how ever low that is). Spent some money
   for tools and hire programmers for a mainstream language. Some are
   not really good and have to be trained, but you can either fire
   them in time or train them. At least you don't have to train them
   much. Then push the product to the market as fast as possible.

   Now you can have 

       (a) Failure: You lost money, but not as much as in 1.a. 

       (b) Success: Customers like your product. Unfortunately they
           have to patch it now and then, but that makes you look good
           actually: You provide a service for your customers and they
           remember you because they have an on-going relation to your
           company.

           Eventually they buy / have to buy new versions, so become
           customers a second time (if you don't annoy them too much,
           that is just the definition of "acceptable quality").

           Of course the overall costs are higher, they have to be
           financed from the sales of the software. But that is money
           you now have.


And now pretend you're an investor: Which approach would you like
best? (1) or (2)? Note that the success is mostly dependent on wether
the customer likes your product or not -- basically the same in with
acceptable and outstanding code quality (like means: makes a good
impression at the first look). So in (1) the risk*money is higher than
in (2).

Furthermore consider now you don't have the money to pull through
(1). You can only go for (2) now. That of course costs in the long run,
but then you spent money later that you have later and don't try to
spent money now you don't have (and perhaps won't get from an
investor).

I think that is basically what has been happening in the PC software
industry for the last 20 years. Many software engineers cannot
understand why one would not ensure quality as early as possible in
the development process, since fixing bugs later costs much more than
fixing them early. But this way to look upon things assumes that the
product succeeds. If you think in terms of risk or sometimes only in
terms of liquid assets the perspective changes.

No, I certainly don't like it very much. But I suggest one should take
these factors into consideration before wondering that Ada is not more
popular then C and attributing everything to the presumed fact that
those people that make the other decision are just morons.

 - There are other languages than C around. The success of C has been
   largely the result of historical circumstances.

 - It is not technical merit alone on which languages succeed (wether
   generally or wether in single projects).

Hope this text isn't too disjoint.


Regards -- Markus