Answering an Ada/COBOL Question

Answering an Ada/COBOL Question

[Richard D Riehle]

David Glessner wrote:

Richard D Riehle wrote:
> Yes, indeed. The COBOL version of a case statement is still the
> most elegant design of multiway selection I have seen in any
> language.  Also, COBOL has adopted some ideas from Ada, although
> the COBOL users don' realize it.

Care to elaborate for us non-COBOL-aware folks?

As briefly as possible, here goes:

COBOL uses the word "Evaluate" instead of "case".  There are several
variations in syntax.  I will not cover all of them.  Instead, the one
that is interesting to me is the "decision table" version.  Also, I will
code this in a format that does not include some of COBOL's syntactic
sugar so it is easy to read.

      Evaluate A also B also C
         when True also True also True
              Perform ... end-perform
         when True also True also False
              Perform ... end-perform
         when False also True also False
              Perform ... end-perform
         when others
              Perform ... end-perform
      End-Evaluate

Note the ease with which one can map a decision table directly to
the code.  One can argue that this _can_ be expressed just as well
in some other language, perhaps Ada.  However, the question is never
"Is it _expressible_ ?" The real issue is whether how well it can be
expressed.  It is _expressiveness_ rather than _expressibility_.   

For the kinds of business data processing problems COBOL is intended to
solve, for reducing the communication gap between the client and the
programmer, the invention of the Evaluate statement and its variations has
improved the level of expressiveness.  

I once challenged some Ada programmers to come up with an Ada design 
that would be as expressive as the Evaluate statement.  None of the
solutions was satisfactory.  If you think you have a solution that is
as expressive as that in COBOL, be sure you cover all the variations
possible, not simply the one I just demonstrated.  

Richard Riehle
http://www.adaworks.com

Re: Answering an Ada/COBOL Question

[Brian Rogoff]

On Fri, 12 Nov 1999, Richard D Riehle wrote:
> David Glessner wrote:
> 
> Richard D Riehle wrote:
> > Yes, indeed. The COBOL version of a case statement is still the
> > most elegant design of multiway selection I have seen in any
> > language.  Also, COBOL has adopted some ideas from Ada, although
> > the COBOL users don' realize it.
> 
> Care to elaborate for us non-COBOL-aware folks?
> 
> As briefly as possible, here goes:
> 
> COBOL uses the word "Evaluate" instead of "case".  There are several
> variations in syntax.  I will not cover all of them.  Instead, the one
> that is interesting to me is the "decision table" version.  Also, I will
> code this in a format that does not include some of COBOL's syntactic
> sugar so it is easy to read.
> 
>       Evaluate A also B also C
>          when True also True also True
>               Perform ... end-perform
>          when True also True also False
>               Perform ... end-perform
>          when False also True also False
>               Perform ... end-perform
>          when others
>               Perform ... end-perform
>       End-Evaluate

I don't want to rain on your parade, but how is this nicer than the
pattern matching capability that all modern functional programming 
languages have? Not only can they match on product types, like your 
bool * bool * bool tuple, but they can match on lists, records, 
and sum types. That seems far more elegant than the COBOL snippet above.
Am I missing something?

> Note the ease with which one can map a decision table directly to
> the code.  One can argue that this _can_ be expressed just as well
> in some other language, perhaps Ada.  However, the question is never
> "Is it _expressible_ ?" The real issue is whether how well it can be
> expressed.  It is _expressiveness_ rather than _expressibility_.   

match(a,b,c) with 
  (true,true,true)  -> foo
| (true,true,false) -> bar
| (true,false,false) -> baz
| (_,_,_)            -> default

seems perfect to me, but I don't know COBOL. Is there some other aspect of 
COBOL's conditional that gives it more expressiveness than what you've 
shown?

-- Brian (OCaml fan, and Ada fan too ;-)

Re: Answering an Ada/COBOL Question

[Robert Dewar]

In article
<Pine.BSF.4.10.9911131710530.16406-100000@shell5.ba.best.com>,
> I don't want to rain on your parade, but how is this nicer
> than the pattern matching capability that all modern
> functional programming
> languages have?

Sure, these pattern matching facilities handle this capability
fine, though often not with such convenient syntax. But that's
besides the point given that none of these "modern functional
programming languages" are even vaguely suitable for fiscal
programming.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Answering an Ada/COBOL Question

[Brian Rogoff]

On Sun, 14 Nov 1999, Robert Dewar wrote:
> In article
> <Pine.BSF.4.10.9911131710530.16406-100000@shell5.ba.best.com>,
> > I don't want to rain on your parade, but how is this nicer
> > than the pattern matching capability that all modern
> > functional programming
> > languages have?
> 
> Sure, these pattern matching facilities handle this capability
> fine, though often not with such convenient syntax. But that's
> besides the point given that none of these "modern functional
> programming languages" are even vaguely suitable for fiscal
> programming.

Let me put back in a quote you snipped to remind you of what the point
I commented on is 

> Richard D Riehle wrote:
> > Yes, indeed. The COBOL version of a case statement is still the
> > most elegant design of multiway selection I have seen in any
> > language.  

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.

-- Brian

Re: Answering an Ada/COBOL Question

[Robert Dewar]

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.

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

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.

A little interesting history here. When the Steelman
requirements were finalized, one of the first steps was to do a
careful comparison against existing languages. One of the
languages was COBOL, and in fact COBOL came very close to
satisfying many of the requirements, closer in many regards
than say C or Pascal. I believe [though I may be remembering
wrong here] that Jean Sammet was involved in this review. But
the general feeling was that COBOL was not a serious contender
as a language base for non-technical reasons (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

I advised a PhD student in the early 70's (Carma McClure, who is
now married to James Martin) whose thesis topic was the design
of structured approaches for COBOL programming, and more
interestingly, a theoretical and experimental analysis of
the effect of using a structured approach. She attended one
of the Codasyl conferences at the time, the only academic
person attending, and everyone kept asking "what are you
doing here? no one from academia ever comes here!"

Robert Dewar



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Answering an Ada/COBOL Question

[Brian Rogoff]

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.
> 
> These are not simply Booleans in COBOL, they are conditions,
> which are rather different in COBOL than other languages.
> 
> 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.

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.

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.

> (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

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. 

-- Brian

Re: Answering an Ada/COBOL Question

[Richard D Riehle]

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

Re: Answering an Ada/COBOL Question

[Brian Rogoff]

On Mon, 15 Nov 1999, Richard D Riehle wrote:
> 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.

No apologies necessary.

> >> 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. 

What is the difference?

> >> 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."  

That doesn't apply here. I'm easily convinced, if you're right. So far, 
I haven't seen a demonstration of the power of COBOLs case statement that 
makes me think it isn't a degenerate case of pattern matching on a boolean 
tuple. Robert asserted that it is better for programming decision tables,
but based on your short example, I think ML is superior. Does anyone who
knows both languages feel like posting some convincing code snippets?

> It is
> not my goal to persuade anyone that COBOL is superior to ML. 

The case I was thinking about ;-) was simply the COBOL conditional versus 
ML style pattern matching, not ML vs COBOL in general. 

> >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.

See www.erlang.org. If you can find the paper on the development of the
language, it makes for interesting reading.

-- Brian

Erlang (Was Re: Answering an Ada/COBOL Question)

[Vladimir Olensky]

Brian Rogoff wrote in message ...

>> Erlang?   Clearly someone _expressiveness_ for ideas that could not
>> be conveniently expressed in the languages they already knew.
>
>See www.erlang.org. If you can find the paper on the development of the
>language, it makes for interesting reading.
>
>-- Brian


Extremely  interesting.
And the name itself reflects the fact that it was created as
software platform for real-time telecom applications.
Erlang is a unit to measure phone traffic.

Taking into account the whole set of tools and libraries for
telecom apps as well as gigabit telecom equipment (scalable
ATM switches) where Erlang was used successfully as software
platform I may take an assumption that it could be a serious
competitor to Ada in this domain.
Erlang (the same as Ada) was created  as real language
for real-time application and real things.

Among examples there is even small OS written in Erlang.
Probably it even may be useful for N.R. Ada OS project :)

Regards,
Vladimir

Re: Erlang (Was Re: Answering an Ada/COBOL Question)

[Vladimir Olensky]

Vladimir Olensky wrote in message ...

>Erlang is a unit to measure phone traffic.


This unit of traffic measure was named in honor
of Agner Krarup Erlang (1878 -1929)  who was a Danish
mathematician who developed a theory of stochastic processes
in statistical equilibrium  widely used in the telecommunications
industry.

So the same as in Ada case the Erlang language was named after
famous person.

It is interesting to note that it's syntax is close to that used in Prolog.

Regards,
Vladimir Olensky

Re: Erlang (Was Re: Answering an Ada/COBOL Question)

[Samuel Tardieu]

>>>>> "Vladimir" == Vladimir Olensky <vladimir_olensky@yahoo.com> writes:

Vladimir> It is interesting to note that it's syntax is close to that
Vladimir> used in Prolog.

Right, but once must note that one strength of Prolog have been
(purposely) removed: backtracking. I would qualify Erlang as a mix of
Prolog and CAML, since latest releases can manipulate functions as
objects, and those objects contain the whole closure of the function.

This lets you do funny things that are not easily done in Ada:

% adder (X) -> fun (Y) -> X + Y end.
% Adder3 = adder (3).
% Adder5 = adder (5).
% Adder3 (10).
13
% Adder5 (10).
15

If you add that this language supports concurrency, that
distribution is transparent for the programmer, that you can pass
functions as objects between nodes, you get immediate code migration
capabilities.

  Sam
-- 
Samuel Tardieu -- sam@ada.eu.org

Re: Erlang (Was Re: Answering an Ada/COBOL Question)

[Robert Dewar]

In article <873du5ik0b.fsf@antinea.enst.fr>,
  Samuel Tardieu <sam@ada.eu.org> wrote:
> >>>>> "Vladimir" == Vladimir Olensky
<vladimir_olensky@yahoo.com> writes:

> Right, but once must note that one strength of Prolog have
> been (purposely) removed: backtracking.

This is sort of like saying that something is like Ada except
that strong typing has been removed :-)

The only interesting thing about Prolog is the pattern matching
and backtracking!


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Erlang (Was Re: Answering an Ada/COBOL Question)

[Samuel Tardieu]

>>>>> "Robert" == Robert Dewar <robert_dewar@my-deja.com> writes:

Robert> The only interesting thing about Prolog is the pattern
Robert> matching and backtracking!

pattern matching has been kept in Erlang.

  Sam
-- 
Samuel Tardieu -- sam@ada.eu.org

Re: Erlang (Was Re: Answering an Ada/COBOL Question)

[Brian Rogoff]

On 22 Nov 1999, Samuel Tardieu wrote:
> >>>>> "Robert" == Robert Dewar <robert_dewar@my-deja.com> writes:
> 
> Robert> The only interesting thing about Prolog is the pattern
> Robert> matching and backtracking!
> 
> pattern matching has been kept in Erlang.
> 
>   Sam
> -- 
> Samuel Tardieu -- sam@ada.eu.org

Yes, interestingly, for the functional programming language community,
pattern matching was seen as the important feature in the design of 
Erlang. Erlang is dynamically typed, and originally,as Samuel noted, did 
not have higher order functions, which are kind of a litmus test for 
being a "functional" programming language in common meaning (*). A new 
version added HOFs and list comprehensions, but the dynamic type system is 
still offensive to some in the academic programming language community,
who favor implicit static typing.

-- Brian

(*) One may correctly argue that the expression is as silly as "object
    oriented programming language". You can program in a functional style
    in Ada too, but I wouldn't list Ada as an FP. It could enable that 
    style a bit better with a few small extensions.

Re: Erlang (Was Re: Answering an Ada/COBOL Question)

[Samuel Tardieu]

>>>>> "Vladimir" == Vladimir Olensky <vladimir_olensky@yahoo.com> writes:

Vladimir> Taking into account the whole set of tools and libraries for
Vladimir> telecom apps as well as gigabit telecom equipment (scalable
Vladimir> ATM switches) where Erlang was used successfully as software
Vladimir> platform I may take an assumption that it could be a serious
Vladimir> competitor to Ada in this domain.  Erlang (the same as Ada)
Vladimir> was created as real language for real-time application and
Vladimir> real things.

Being an Erlang fan, I must admit that this is a nice language. But it
has not been designed for hard real time programs, only soft real time
ones.

Its main advantage over Ada is, IMO, the ability to replace running
code. Ericsson reports a near-100% uptime (the rest being hardware
upgrades) in several products. I played with this when developing an
IRC robot in Erlang: once the robot was able to connect to the IRC
server and dialog using the IRC protocol, it has never been
disconnected in one day while I was making heavy development on it. I
added all the functionalities one by one, fixed bugs one by one,
without ever stopping the program which was still talking with the
server.

  Sam
-- 
Samuel Tardieu -- sam@ada.eu.org

Re: Erlang (Was Re: Answering an Ada/COBOL Question)

[Robert Dewar]

In article <877ljhikgt.fsf@antinea.enst.fr>,
  Samuel Tardieu <sam@ada.eu.org> wrote:
> >>>>> "Vladimir" == Vladimir Olensky
<vladimir_olensky@yahoo.com> writes:
>
> Its main advantage over Ada is, IMO, the ability to replace
> running code.

Since this was a COBOL thread originally, it is appropriate
to point out that COBOL has always had this capability, it is
quite normal to extend the functionality of a COBOL program
and add modules to a running program without stopping it. This
is facilitated by the fact that calls to subroutines (called
PROGRAM's in COBOLese, a program is a RUN UNIT) are dynamically
bound at run time, rather than statically resolved at link
time in COBOL.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Erlang (Was Re: Answering an Ada/COBOL Question)

[Vladimir Olensky]

>Robert Dewar wrote in message <80vgad$mb6$1@nnrp1.deja.com>...

>>  Samuel Tardieu <sam@ada.eu.org> wrote:

>> Its main advantage over Ada is, IMO, the ability to replace
>> running code.
>
>Since this was a COBOL thread originally, it is appropriate
>to point out that COBOL has always had this capability, it is
>quite normal to extend the functionality of a COBOL program
>and add modules to a running program without stopping it.

In addition to Erlang and COBOL I would like to mention here
Oberon BlackBox framework based on Component Pascal
which also has this capability to install and remove software
modules without stopping the whole system.
I understand this as a trend in software industry that  could
become a MUST in some future.

"Hot-swap" capability is a very important one in making
system maintenance, upgrades  and troubleshooting much
easier.  In reality it is much more often used in hardware than
in software.

I wonder why this COBOL experience (it seems that it was
the first in this area ???) was not implemented till recently in
other languages that were intended for reliable systems ?


Regards,
Vladimir Olensky

Re: Erlang (Was Re: Answering an Ada/COBOL Question)

[Vladimir Olensky]

Samuel Tardieu wrote in message <877ljhikgt.fsf@antinea.enst.fr>...
>
>Being an Erlang fan, I must admit that this is a nice language.

After reading through it's documentation and playing a little bit
with it I could not resist either :-)
A lot of interesting ideas.
The most important thing is that it has everything that could be
needed for building TELECOM applications.

Now I think that it is even more serious competitor to Ada in this
area then I thought at the beginning.

Regards,
Vladimir Olensky

Re: Answering an Ada/COBOL Question

[Robert Dewar]

In article > That doesn't apply here. I'm easily convinced, if
> you're right. So far,  I haven't seen a demonstration of the
> power of COBOLs case statement that
> makes me think it isn't a degenerate case of pattern matching
> on a boolean  tuple.

Really you just need to spend some effort learning COBOL and
make up your own mind. If you don't want to spend this effort,
then why bother. In my experience it is wasted effort to produce
examples in a case like this unless people have an overall
understanding of the language context.

> Robert asserted that it is better for programming decision
> tables, but based on your short example, I think ML is
> superior.

You cannot base an opinion on a short example written in a
language you do not understand. For example, if you do not
know what a CONDITION is in COBOL, you probably don't really
understand the example.

I don't particularly have any great desire to convince the
world that COBOL is an interesting language with lots of
interesting features that are worth knowing (a lot of the
world knows this already :-) People have to decide for
themselves whether they will take the effort to learn a
language to find out for themselves what is interesting.

>  Does anyone who
> knows both languages feel like posting some convincing code
> snippets?

I know both languages, but decline the invitation, since I don't
think a useful argument can be made with "code snippets" in
languages that people do not know.



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Answering an Ada/COBOL Question

[Robert Dewar]

In article <80piek$rd3$1@nntp1.atl.mindspring.net>,
  Richard D Riehle <laoXhai@ix.netcom.com> wrote:
> 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.

Actually I think this is a rather small section of the market,
I don't often run into C or C++ in COBOL type environments
(smalltalk is for example more popular in this environment).

The notion that COBOL is dead is another remarkable myth that
you fine. About a year ago, I talked to a very high up official
in the DoD who was in a position of considerable influence
regarding DoD fiscal applications.

He presented as received knowledge the idea that only the DoD
was still using COBOL, and that all commercial companies had
abandoned COBOL long ago. I was too taken aback to have any
idea how to react to this absolutely amazing point of view.

When we developed Realia COBOL in the 1980's for the PC, we
expected the market to be offloaded maintenance of existing
COBOL applications on mainframes. We were surprised to find
that the major market was (and still is by the way) development
of new COBOL applications to be deployed on PC's (it is possible
these days to run JCL, BAL, CICS, etc on PC's, so the entire
mainframe environment can be replicated).


> 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
>
>


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Answering an Ada/COBOL Question

[Richard D Riehle]

In article <80qk9s$6h5$1@nnrp1.deja.com>,
	Robert Dewar <robert_dewar@my-deja.com> wrote:

>Actually I think this 

       [ C++ and C instead of COBOL ]

>is a rather small section of the market,
>I don't often run into C or C++ in COBOL type environments
>(smalltalk is for example more popular in this environment).

I suppose Silicon Valley is a little different from the rest 
of the world.  C and C++ are lingua franca of computing in
this neighborhood.   Java is making a lot of headway and some
even claim to have completed projects in it.  Now and then
someone will bravely attempt some other language.  For example,
a bunch of engineers at HP used Eiffel for the embedded software
on one of the printers.  

>The notion that COBOL is dead is another remarkable myth that
>you fine. About a year ago, I talked to a very high up official
>in the DoD who was in a position of considerable influence
>regarding DoD fiscal applications.

Software management and decision-making within the DoD has become
a national disgrace.  I guess I am into hyperbole again.  :-)


So much energy is being devoted to ideas that simply cloak 
the deeper problems that one can only wonder how we will 
survive any future conflict.  Granted, there are a few 
intelligent people still making good decisions.  The downturn 
started with Bill Perry's notion of COTS for everything, 
extended itself into the folly of adopting, "industry best 
practices," and culminated in  a decision to abandon Ada.  
Yes, I know.  That is not how the  decision was worded.  
But that is how it is being interpreted.

>He presented as received knowledge the idea that only the DoD
>was still using COBOL, and that all commercial companies had
>abandoned COBOL long ago. I was too taken aback to have any
>idea how to react to this absolutely amazing point of view.

This idiotic notion of "industry best practices" illustrates that
DoD officials have no clue of just how bad industry software is.
The DoD has, for a long time, been building much better software
than that in the commercial sector.  Next thing you know, someone
will be using NT for an embedded weapon system.  Heaven help us!

>When we developed Realia COBOL in the 1980's for the PC, we
>expected the market to be offloaded maintenance of existing
>COBOL applications on mainframes. We were surprised to find
>that the major market was (and still is by the way) development
>of new COBOL applications to be deployed on PC's (it is possible
>these days to run JCL, BAL, CICS, etc on PC's, so the entire
>mainframe environment can be replicated).

Ada has certainly evolved as a beter option for most applications
than COBOL.  But COBOL is far from dead.  The rash of advertising
for C++ and Java programmers simply indicates the immaturity of 
those markets.  The COBOL programmers are just going to work each
day and doing their job.  Those who judge the success of a language
on the basis of the number of ads for jobs, is like someone who 
judges the success of the automobile by counting the road kill.

Richard Riehle
http://www.adaworks.com

 

Re: Answering an Ada/COBOL Question

[Robert Dewar]

In article <80sfrb$1o0$1@nntp3.atl.mindspring.net>,
  Richard D Riehle <laoXhai@ix.netcom.com> wrote:

> I suppose Silicon Valley is a little different from the rest
> of the world.  C and C++ are lingua franca of computing in
> this neighborhood.

Yes, but Silicon Valley is hardly the place to find typical
fiscal programming going on. Back in Realia COBOL days, we
had thousands of customers, I don't think one of them came
from the valley :-)

I bet that visual basic is used more than you think, and that
goes for the valley as well.

> So much energy is being devoted to ideas that simply cloak
> the deeper problems that one can only wonder how we will
> survive any future conflict.  Granted, there are a few
> intelligent people still making good decisions.  The downturn
> started with Bill Perry's notion of COTS for everything,
> extended itself into the folly of adopting, "industry best
> practices," and culminated in  a decision to abandon Ada.
> Yes, I know.  That is not how the  decision was worded.
> But that is how it is being interpreted.

by some, but not by others. And after all the mandate was
ignored by some, and not by others. We see our Ada market
growing, including a number of brand new projects starting
out using Ada.

> This idiotic notion of "industry best practices" illustrates
> that DoD officials have no clue of just how bad industry
> software is. The DoD has, for a long time, been building much
> better software than that in the commercial sector.

You will probably get flamed for that, but I happen to agree.
I attended a Y2K seminar in the DoD, and very much the feeling
that was projected was that DoD was in much worse shape, and
had far worse problems. My reaction was that the situation was
certainly no worse than the commercial sector, and in some
ways better (it is less usual in DoD environments for instance
to have entirely lost the sources to your software).

> Ada has certainly evolved as a beter option for most
> applications than COBOL.

That's true, but I am afraid this potential is so far
unrealized. The COBOL sector in general regards C and C++
as hacker languages unsuitable for fiscal programming, But
they simply don't know about Ada as an alternative.



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Answering an Ada/COBOL Question

[tmoran]

>I attended a Y2K seminar in the DoD, and very much the feeling
>that was projected was that DoD was in much worse shape, and
  Perhaps some people will be surprised at what sectors, using
what languages and "software engineering" methods, turn out to
have substantial Y2K problems.  January will be interesting.

Re: Answering an Ada/COBOL Question

[Robert I. Eachus]

   Robert Dewar wrote:
 
>I attended a Y2K seminar in the DoD, and very much the feeling
>that was projected was that DoD was in much worse shape, and...

    I think that the DoD is in much better shape than the commercial
sector wrt Y2K.  However, the military does in fact have a much worse
problem.  Not only do many of their systems have to work on Jan. 1,
2000, they have to worry about contingency planning for all sorts of
eventualities encountered in the private, public, and government
sectors, plus overseas.   In other words, even if all DoD systems are
fine, and there are only isolated problems around the world, planning
groups may have a very busy night figuring out where help is needed and
can be provided.  (Such as potable water, portable generators, etc., the
normal hurricane or flood drill...)
 
-- 

                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Answering an Ada/COBOL Question

[Marin Condic]

Robert Dewar wrote:

> That's true, but I am afraid this potential is so far
> unrealized. The COBOL sector in general regards C and C++
> as hacker languages unsuitable for fiscal programming, But
> they simply don't know about Ada as an alternative.

I've wondered why it is that the perception exists that C/C++ would be
unsuitable for financial software? They are, after all, "general
purpose" languages. They may lack some of the convenient I/O that COBOL
has and the support for decimal arithmetic, but one could probably build
up some libraries to support that. Is the perception just a matter of
someone slapping a label on the language? Someone says "COBOL =
Business" or "Java = Internet" and otherwise intelligent people just
assume that C/C++/Ada/Whatever can't do the same thing? (I can
understand that for non-technical types but why do technically trained
people swollow this?)

Not that I'm advocating C/C++ here. Ada would clearly provide better
support for financial software (I've got a bunch of financial packages
on my web page that do lots of useful computations!) and in general
doesn't have the boobytraps & shortcomings of C/C++. But I have in the
past built software that was serving business/financial functions in C,
so I know that it can be done.

MDC
--
Marin David Condic
If you hurry you can, for a short time only, still find me at:
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.mcondic.com/

Re: Answering an Ada/COBOL Question

[Robert Dewar]

In article <38341CB6.AF2A5895@pwfl.com>,
  condicma@pwflcom wrote:
> Robert Dewar wrote:
>
> > That's true, but I am afraid this potential is so far
> > unrealized. The COBOL sector in general regards C and C++
> > as hacker languages unsuitable for fiscal programming, But
> > they simply don't know about Ada as an alternative.
>
> I've wondered why it is that the perception exists that C/C++
would be
> unsuitable for financial software? They are, after all,
"general
> purpose" languages. They may lack some of the convenient I/O
that COBOL
> has and the support for decimal arithmetic, but one could
probably build
> up some libraries to support that.

These libraries will tend to be very inefficient, and the lack
of literals and convenient notations is a serious one. Just
try writing typical bond yield programs in C++, and see if
you find it a pleasing experience :-)

The data declaration style in COBOL is also very convenient
for file related data.

Typically this kind of comment comes from people who don't
have experience writing fiscal programs in COBOL or any other
language :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Answering an Ada/COBOL Question

[Marin Condic]

Robert Dewar wrote:

> Typically this kind of comment comes from people who don't
> have experience writing fiscal programs in COBOL or any other
> language :-)

Not entirely fair. In another life, I developed lots of financial
applications in COBOL for the City of Chicago. I'll grant that COBOL has

facilities that make this sort of thing easier - especially with file
handling, decimal numbers, output formatting, etc. My only point was
that otherwise intelligent people conclude that because COBOL has some
superior features for a specific application domain that means the
application domain can't be addressed by other languages which may not
have all those spiffy domain specific features. I've also done financial

applications in C. It's more work in some areas, but it is not at all
impossible - or even necessarily difficult. I think that with Ada's data

processing annex, it provides most of the tools needed to do the job -
if not exactly as easily, at least well enough that it would be a viable

choice for financial software alongside COBOL. (And let's be fair about
COBOL: What it may make easier in some areas it often makes more
difficult in others, so it may just be a wash.)

Now how I went from business data processing to embedded realtime engine

controls is a long story, but I've never been tempted to try writing a
realtime executive in COBOL! ;-)

MDC
--
Marin David Condic
If you hurry you can, for a short time only, still find me at:
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.mcondic.com/

Re: Answering an Ada/COBOL Question

[Robert Dewar]

In article <3835B58B.9A24C3EB@pwfl.com>,
  condicma@pwflcom wrote:
> Not entirely fair. In another life, I developed lots of
> financial applications in COBOL for the City of Chicago.

I would be willing to bet that this was COBOL-75, which is
really not a sensible point of comparison at this stage.


> I'll
> grant that COBOL has
>
> facilities that make this sort of thing easier - especially
> with file
> handling, decimal numbers, output formatting, etc. My only
point was
> that otherwise intelligent people conclude that because COBOL
> has some
> superior features for a specific application domain that means
> the
> application domain can't be addressed by other languages which
> may not
> have all those spiffy domain specific features. I've also done
> financial
>
> applications in C. It's more work in some areas, but it is not
> at all
> impossible - or even necessarily difficult.

It is definitely dificult to write efficient 18-digit decimal
computational stuff in C with proper rounding and truncation
options. And furthermore it is junky to use because of not
having proper literals.

Sure you can do anything in any language, I personally would
be much happier addressing a lot of traditional C domains in
COBOL than the other way round (e.g. the Realia COBOL compiler
was written 100% in COBOL, and this proved to be a quite
reasonable environment, I would chose COBOL over C for writing
a compiler any day).

> I think that with
> Ada's data
> processing annex, it provides most of the tools needed to do
> the job -
> if not exactly as easily, at least well enough that it would
> be a viable
> choice for financial software alongside COBOL.

Well it was designed by people who know COBOL very well (Robert
Dewar, Ben Brosgol, Ken Fussichen), and we think we succeeded
far better than that and that for many of the traditional
COBOL tasks, Ada is better than COBOL. Note we did not put
file/io features in, because no one would use COBOL FILE
stuff any more, it is considered the assembly language of
IO, everyone uses data bases these days (Marin's reference
to file processing in COBOL is another reminder of ancient
bygone days in the COBOL world).

> (And let's be fair about
> COBOL: What it may make easier in some areas it often makes
> more difficult in others, so it may just be a wash.)

If you want to be fair, let's have some examples, and make sure
they are up to date with the current version of COBOL!

> Now how I went from business data processing to embedded
> realtime engine controls is a long story, but I've never been
> tempted to try writing a realtime executive in COBOL! ;-)

There is nothing inherently unreasonable about such a notion.
COBOL does suffer from insufficiently strong typing, I would
say it is on a par with C here, but on the other hand, the
object oriented support in COBOL is very sophisticated (if
anything it is too complex, it is certainly much more powerful
than corresponding features in C++ and Ada).



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Answering an Ada/COBOL Question

[Joseph P Vlietstra]

Richard D Riehle wrote:

> I once challenged some Ada programmers to come up with an Ada design
> that would be as expressive as the Evaluate statement.  None of the
> solutions was satisfactory.  If you think you have a solution that is
> as expressive as that in COBOL, be sure you cover all the variations
> possible, not simply the one I just demonstrated.

Back in the good old days when Fortran was FORTRAN, we designed a sonar
simulator strictly using decision tables.  While we couldn't directly express
the
decision table in FORTRAN, we could incorporate the decision table in
comments.
(In fact, this was required item that was checked in the peer reviews.)
Using comments to document the decision table works in any language!

We no longer try to use decision tables for everything.  But when decision
tables
are used for design, we still follow these rules:
-- decision table is in canonical format ("major" decisions first)
-- decision table appears in comments above implementing code
-- predicates are evaluated in same order as they appear in decision table

In my experience, many decision tables contain "don't care" entries.
For example, if Marital_Status = Single then Age_Of_Spouse is a don't care.
When a decision table is ordered correctly (don't cares entries in upper
right)
the implementation drops out.  (See "Decision Tables in Software Engineering"

or CODASYL publication on decision tables -- I'm at home so I can't grab the
exact title from the bookshelf.)

For example, the following decision table:
        A    B    C
        T    X    X    Action_1
        F    T    X    Action_2
        F    F    T    Action_3
        F    F    F    Action_4
can be implemented as:
        if A then
            Action_1;
        elsif B then
             Action_2;
        elsif C then
            Action_3;
        else
            Action_4;
        end if;
Yes, this example is extreme, but I rarely see a decision table design that
doesn't
have some don't care entries.

Also, in my obsolete COBOL experience, I never implemented an Evaluate
statement to test several conditions.  It always seemed cleaner to break the
logic into nested If and Evaluate statements.

Re: Answering an Ada/COBOL Question

[Robert Dewar]

In article <382FA652.A72E4150@concentric.net>,
  Joseph P Vlietstra <joevl@concentric.net> wrote:
> For example, the following decision table:
>         A    B    C
>         T    X    X    Action_1
>         F    T    X    Action_2
>         F    F    T    Action_3
>         F    F    F    Action_4
> can be implemented as:
>         if A then
>             Action_1;
>         elsif B then
>              Action_2;
>         elsif C then
>             Action_3;
>         else
>             Action_4;
>         end if;

But this is a poor implementation because it overspecifies,
precisely by not clearly indicating exactly what the don't
care conditions are. One very serious problem with the
elsif structure is precisely that you don't know if the
ordering is critical or not. When it comes to modifying
the conditions, this lack of information can be problematical.

When we deal with conditions that are not exclusive, this
problem always arises, and is one of the reasons that complex
condiitonals are so hard to deal with in maintenance
programming.


Sent via Deja.com http://www.deja.com/
Before you buy.