Re: Answering an Ada/COBOL Question

[Richard D Riehle <laoXhai@ix.netcom.com>]

In article <Pine.BSF.4.10.9911141057210.7241-100000@shell5.ba.best.com>,
	Brian Rogoff <bpr@shell5.ba.best.com> wrote:

>On Sun, 14 Nov 1999, Robert Dewar wrote:
>> In article
>> <Pine.BSF.4.10.9911132308290.27448-100000@shell5.ba.best.com>,
>>   Brian Rogoff <bpr@shell5.ba.best.com> wrote:
>> > I also found the ML version of the case syntactically much
>> > nicer. Also, pattern matching works on more than just
>> > sequences of booleans. Note that I am not commenting at all on
>> > the suitableness of FPs for
>> > fiscal programming, just on the claim of "most elegant case
>> > design" for  COBOL.

Sorry, Brian.  I sometimes resort to hyperbole in my zeal to make
a point.  When considering the difference between _expressible_
versus _expressive_, the functional languages do serve an important
role.  Unfortunately, they are not adopted as widely as might be
appropriate.  That being said, functional languages are probably
not as expressive of business data processing problems as COBOL. 

>> These are not simply Booleans in COBOL, they are conditions,
>> which are rather different in COBOL than other languages.

Yes. For those not accustomed to thinking in COBOL, this does not
jump out at you.  Then again, COBOL programmers are typically not
adept at thinking in terms of pattern matching. 

>> Make sure you really know the COBOL facility well (don't just
>> rely on Richard's quick example) before deciding that the ML
>> syntax is better for dealing with decision tables. Knowing and
>> having used both languages, I definitely agree with Richard here
>> and disagree with Brian. Yes the ML facility is general and
>> powerful, No, it is not nearly as syntactically friendly and
>> convenient as COBOL.

Thank you, Robert.  I realize my example was rather concise.  My
original intent was to illustrate a point with regard to 
_expressiveness_ versus _expressibility_ in response to some 
comment made regarding Ada, et al.  

>That's fine, I respect your opinion, and readily acknowledge that I don't 
>know COBOL, and hence, have no opinion on COBOL per se. A quick example or 
>sequence of examples showing where COBOL is superior to ML or Haskell
>would be appreciated. Since you know ML, you know that the pattern
>matching facility does work over data types, and in the Caml dialects
>there are niceties like pattern guards, range patterns, and stream
>patterns.

"He convinced against his will, is of the same opinion still."  It is
not my goal to persuade anyone that COBOL is superior to ML. It isn't;
not productive to claim that Ada is superior to COBOL or vice versa. 
My original posting was an rather oblique illustration of the folly of
making such comparisons.   Each programming language permits some unique
approach to expressing the solution to some category of problems.  Each
has its strengths and weaknesses.  COBOL has some powerful features for
dealing with some kinds of problems and is pathetically weak when one
used it for others.  Ada allows some powerful _expressiveness_ for a
large class of solutions, but it falls short in some places, when 
compared to the _expressiveness_ of other languages.  

>It should be mentioned that there is a language used to program soft
>real-time and distributed systems called Erlang. This language was
>designed at Ericsson with a lot of "human engineering" effort, and one 
>of the things its designers insist on as being responsible for its success
>is its pattern matching syntax.

Erlang?   Clearly someone _expressiveness_ for ideas that could not
be conveniently expressed in the languages they already knew.

>> (too many competent
>> programming language experts are sure COBOL is junk and the fact
>> that they have never looked at it does not deter them from this
>> strongly held opinion). A little anecdote there. In academic
>> programming language circles, it is almost required that people
>>
>> a) not know COBOL
>> b) know that it is junk

One of the real tragedies is that so much software that ought to be
developed in the current version of COBOL is being developed in C.
In part, this is the fault of the compiler publishers.  One popular
COBOL compiler publisher, used by a colleague of mine here in Silicon
Valley, has been notoriously unresponsive in its support.  One thing
about programming in C.  You do not have to rely as much on your 
compiler publisher for support.  The same can be said for assembler.

>I don't hold that view. Many people (inside *and* outside academia) hold
>this view of Ada. I'd suspect that if you polled Silicon Valley more than 
>90% of the programmers just know that Ada sucks. 

I suspect the percentage is slightly higher.  When I attend a function
here, wearing a badge that says, "AdaWorks," I can count on getting
questions such as, "I thought that language died a long time ago." Ada
is considered to be the COBOL of the 80's by many programmers in this
neighborhood. "It is big, slow, obsolete, and not worth much consideration.  
On top of that, it is a military language, designed by committee so it
can't be any good for commercial programming."  

Fortunately, we are seeing some change in that view.  Robert would be
amused to learn that some of those who are adopting a positive view 
of Ada are not adopting Ada.  Instead, they are programming in GNAT.

Richard Riehle
http://www.adaworks.com