Re: Why don't large companies use Ada?

Kursten Schuetz (kschuetz_at_vnet.ibm.com) writes:
>The main argument was that the Ada vs. other development languages
>for business purposes is a moot point. Ada is a general purpose
>programming language.

So then it can't be used for business, is that what you are trying say? Funny, I never found business that special-purpose.

>An all Ada solution will do more to hurt such development than help it.
>The reason is that Ada is not an information manipulation tool.
>Databases such as Sybase, Oracle, and others are such tools.

I don't know which argument you are trying to counter here, but I think no one in his right mind would suggest replacing the DB DB Engine with an Ada solution. It would be like trying to replace  the bus with the elevator.

>In fact, you will lose performance, simplicity, and features by
>having to perform translations between an implementation of static
>SQL and an external 3GL. This is why companies such as Sybase and
>Oracle have developed their own 4GLs.

I don't know about Oracle's efforts, but I do know about Sybase's, and that is for sure, if we are to compare what Sybase brought on the market this far, that is APT, there is no doubt which offers you the best solution. APT gives you built-in primitives for handling the form, and some built-ins to talk with DB-library. But the rest is a primitive programming language, which offers very bad support for data abstraction. You don't have exception handling. You don't have generics. You don't have packages. You don't even have symbolic constants. You don't even have value parameters, so you pass a literal in a procedure call without putting it in a variable first. And the implementation is not very effective, and not very reliable.

That's two advantages, against a whole range of disadvantages. And of the advantages the DB-library encapsulation is not more difficult than that a skilled engineer could write in a week's work or less. So left is getting a form handler.

>The argument that a general-purpose language is more mature when it
>comes to data abstraction is false. The issue is declarative vs.
>procedural semantics of your DML. For relational structures, I've
>written the same programs in Transact-SQL, C, and Smalltalk. Not
>even Smalltalk approaches the power and elegance of SQL with Sybase's
>extensions for accessing and manipulating relational data structures.

Again, I don't understand what you are trying to counter. I'm not suggesting that you should replace your SQL code with Ada. Ada lends itself better to data abstraction and modularization than T-SQL - if nothing else, because it has higher type safety - but that is irrelevant. If you are dealing with data which belongs to the server, then deal with it there, as long as you, can send the clients the results when you are ready, unless you want your system to crawl.

>So, since Ada does not provide any advantages for DBMS systems, its
>use in a business environment is limited to front-end development
>and possibly some specialized calculation engines (from my previous
>post).

Of course, in a client-server system, where the server is a DB engine, there could be talk of using Ada in the client, but I've never claimed anything else.

-- 
Erland Sommarskog, sommar_at_enea.se, Stockholm
Pour qui est-ce qui vous croyez que je parle?