* Answering an Ada/COBOL Question
@ 1999-11-12 0:00 Richard D Riehle
1999-11-13 0:00 ` Brian Rogoff
1999-11-15 0:00 ` Joseph P Vlietstra
0 siblings, 2 replies; 30+ messages in thread
From: Richard D Riehle @ 1999-11-12 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Answering an Ada/COBOL Question 1999-11-12 0:00 Answering an Ada/COBOL Question Richard D Riehle @ 1999-11-13 0:00 ` Brian Rogoff 1999-11-14 0:00 ` Robert Dewar 1999-11-15 0:00 ` Joseph P Vlietstra 1 sibling, 1 reply; 30+ messages in thread From: Brian Rogoff @ 1999-11-13 0:00 UTC (permalink / raw) 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 ;-) ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Answering an Ada/COBOL Question 1999-11-13 0:00 ` Brian Rogoff @ 1999-11-14 0:00 ` Robert Dewar 1999-11-13 0:00 ` Brian Rogoff 0 siblings, 1 reply; 30+ messages in thread From: Robert Dewar @ 1999-11-14 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Answering an Ada/COBOL Question 1999-11-14 0:00 ` Robert Dewar @ 1999-11-13 0:00 ` Brian Rogoff 1999-11-14 0:00 ` Robert Dewar 0 siblings, 1 reply; 30+ messages in thread From: Brian Rogoff @ 1999-11-13 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Answering an Ada/COBOL Question 1999-11-13 0:00 ` Brian Rogoff @ 1999-11-14 0:00 ` Robert Dewar 1999-11-14 0:00 ` Brian Rogoff 0 siblings, 1 reply; 30+ messages in thread From: Robert Dewar @ 1999-11-14 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Answering an Ada/COBOL Question 1999-11-14 0:00 ` Robert Dewar @ 1999-11-14 0:00 ` Brian Rogoff 1999-11-15 0:00 ` Richard D Riehle 0 siblings, 1 reply; 30+ messages in thread From: Brian Rogoff @ 1999-11-14 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Answering an Ada/COBOL Question 1999-11-14 0:00 ` Brian Rogoff @ 1999-11-15 0:00 ` Richard D Riehle 1999-11-15 0:00 ` Brian Rogoff 1999-11-16 0:00 ` Robert Dewar 0 siblings, 2 replies; 30+ messages in thread From: Richard D Riehle @ 1999-11-15 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Answering an Ada/COBOL Question 1999-11-15 0:00 ` Richard D Riehle @ 1999-11-15 0:00 ` Brian Rogoff 1999-11-16 0:00 ` Erlang (Was Re: Answering an Ada/COBOL Question) Vladimir Olensky 1999-11-16 0:00 ` Answering an Ada/COBOL Question Robert Dewar 1999-11-16 0:00 ` Robert Dewar 1 sibling, 2 replies; 30+ messages in thread From: Brian Rogoff @ 1999-11-15 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Erlang (Was Re: Answering an Ada/COBOL Question) 1999-11-15 0:00 ` Brian Rogoff @ 1999-11-16 0:00 ` Vladimir Olensky 1999-11-16 0:00 ` Vladimir Olensky 1999-11-17 0:00 ` Samuel Tardieu 1999-11-16 0:00 ` Answering an Ada/COBOL Question Robert Dewar 1 sibling, 2 replies; 30+ messages in thread From: Vladimir Olensky @ 1999-11-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Erlang (Was Re: Answering an Ada/COBOL Question) 1999-11-16 0:00 ` Erlang (Was Re: Answering an Ada/COBOL Question) Vladimir Olensky @ 1999-11-16 0:00 ` Vladimir Olensky 1999-11-17 0:00 ` Samuel Tardieu 1999-11-17 0:00 ` Samuel Tardieu 1 sibling, 1 reply; 30+ messages in thread From: Vladimir Olensky @ 1999-11-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Erlang (Was Re: Answering an Ada/COBOL Question) 1999-11-16 0:00 ` Vladimir Olensky @ 1999-11-17 0:00 ` Samuel Tardieu 1999-11-19 0:00 ` Robert Dewar 0 siblings, 1 reply; 30+ messages in thread From: Samuel Tardieu @ 1999-11-17 0:00 UTC (permalink / raw) >>>>> "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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Erlang (Was Re: Answering an Ada/COBOL Question) 1999-11-17 0:00 ` Samuel Tardieu @ 1999-11-19 0:00 ` Robert Dewar 1999-11-22 0:00 ` Samuel Tardieu 0 siblings, 1 reply; 30+ messages in thread From: Robert Dewar @ 1999-11-19 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Erlang (Was Re: Answering an Ada/COBOL Question) 1999-11-19 0:00 ` Robert Dewar @ 1999-11-22 0:00 ` Samuel Tardieu 1999-11-22 0:00 ` Brian Rogoff 0 siblings, 1 reply; 30+ messages in thread From: Samuel Tardieu @ 1999-11-22 0:00 UTC (permalink / raw) >>>>> "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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Erlang (Was Re: Answering an Ada/COBOL Question) 1999-11-22 0:00 ` Samuel Tardieu @ 1999-11-22 0:00 ` Brian Rogoff 0 siblings, 0 replies; 30+ messages in thread From: Brian Rogoff @ 1999-11-22 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Erlang (Was Re: Answering an Ada/COBOL Question) 1999-11-16 0:00 ` Erlang (Was Re: Answering an Ada/COBOL Question) Vladimir Olensky 1999-11-16 0:00 ` Vladimir Olensky @ 1999-11-17 0:00 ` Samuel Tardieu 1999-11-18 0:00 ` Robert Dewar 1999-11-19 0:00 ` Vladimir Olensky 1 sibling, 2 replies; 30+ messages in thread From: Samuel Tardieu @ 1999-11-17 0:00 UTC (permalink / raw) >>>>> "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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Erlang (Was Re: Answering an Ada/COBOL Question) 1999-11-17 0:00 ` Samuel Tardieu @ 1999-11-18 0:00 ` Robert Dewar 1999-11-19 0:00 ` Vladimir Olensky 1999-11-19 0:00 ` Vladimir Olensky 1 sibling, 1 reply; 30+ messages in thread From: Robert Dewar @ 1999-11-18 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Erlang (Was Re: Answering an Ada/COBOL Question) 1999-11-18 0:00 ` Robert Dewar @ 1999-11-19 0:00 ` Vladimir Olensky 0 siblings, 0 replies; 30+ messages in thread From: Vladimir Olensky @ 1999-11-19 0:00 UTC (permalink / raw) >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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Erlang (Was Re: Answering an Ada/COBOL Question) 1999-11-17 0:00 ` Samuel Tardieu 1999-11-18 0:00 ` Robert Dewar @ 1999-11-19 0:00 ` Vladimir Olensky 1 sibling, 0 replies; 30+ messages in thread From: Vladimir Olensky @ 1999-11-19 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Answering an Ada/COBOL Question 1999-11-15 0:00 ` Brian Rogoff 1999-11-16 0:00 ` Erlang (Was Re: Answering an Ada/COBOL Question) Vladimir Olensky @ 1999-11-16 0:00 ` Robert Dewar 1 sibling, 0 replies; 30+ messages in thread From: Robert Dewar @ 1999-11-16 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Answering an Ada/COBOL Question 1999-11-15 0:00 ` Richard D Riehle 1999-11-15 0:00 ` Brian Rogoff @ 1999-11-16 0:00 ` Robert Dewar 1999-11-16 0:00 ` Richard D Riehle 1 sibling, 1 reply; 30+ messages in thread From: Robert Dewar @ 1999-11-16 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Answering an Ada/COBOL Question 1999-11-16 0:00 ` Robert Dewar @ 1999-11-16 0:00 ` Richard D Riehle 1999-11-18 0:00 ` Robert Dewar 0 siblings, 1 reply; 30+ messages in thread From: Richard D Riehle @ 1999-11-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Answering an Ada/COBOL Question 1999-11-16 0:00 ` Richard D Riehle @ 1999-11-18 0:00 ` Robert Dewar 1999-11-18 0:00 ` tmoran 1999-11-18 0:00 ` Marin Condic 0 siblings, 2 replies; 30+ messages in thread From: Robert Dewar @ 1999-11-18 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Answering an Ada/COBOL Question 1999-11-18 0:00 ` Robert Dewar @ 1999-11-18 0:00 ` tmoran 1999-11-19 0:00 ` Robert I. Eachus 1999-11-18 0:00 ` Marin Condic 1 sibling, 1 reply; 30+ messages in thread From: tmoran @ 1999-11-18 0:00 UTC (permalink / raw) >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. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Answering an Ada/COBOL Question 1999-11-18 0:00 ` tmoran @ 1999-11-19 0:00 ` Robert I. Eachus 0 siblings, 0 replies; 30+ messages in thread From: Robert I. Eachus @ 1999-11-19 0:00 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Answering an Ada/COBOL Question 1999-11-18 0:00 ` Robert Dewar 1999-11-18 0:00 ` tmoran @ 1999-11-18 0:00 ` Marin Condic 1999-11-19 0:00 ` Robert Dewar 1 sibling, 1 reply; 30+ messages in thread From: Marin Condic @ 1999-11-18 0:00 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Answering an Ada/COBOL Question 1999-11-18 0:00 ` Marin Condic @ 1999-11-19 0:00 ` Robert Dewar 1999-11-19 0:00 ` Marin Condic 0 siblings, 1 reply; 30+ messages in thread From: Robert Dewar @ 1999-11-19 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Answering an Ada/COBOL Question 1999-11-19 0:00 ` Robert Dewar @ 1999-11-19 0:00 ` Marin Condic 1999-11-19 0:00 ` Robert Dewar 0 siblings, 1 reply; 30+ messages in thread From: Marin Condic @ 1999-11-19 0:00 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Answering an Ada/COBOL Question 1999-11-19 0:00 ` Marin Condic @ 1999-11-19 0:00 ` Robert Dewar 0 siblings, 0 replies; 30+ messages in thread From: Robert Dewar @ 1999-11-19 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Answering an Ada/COBOL Question 1999-11-12 0:00 Answering an Ada/COBOL Question Richard D Riehle 1999-11-13 0:00 ` Brian Rogoff @ 1999-11-15 0:00 ` Joseph P Vlietstra 1999-11-15 0:00 ` Robert Dewar 1 sibling, 1 reply; 30+ messages in thread From: Joseph P Vlietstra @ 1999-11-15 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Answering an Ada/COBOL Question 1999-11-15 0:00 ` Joseph P Vlietstra @ 1999-11-15 0:00 ` Robert Dewar 0 siblings, 0 replies; 30+ messages in thread From: Robert Dewar @ 1999-11-15 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~1999-11-22 0:00 UTC | newest] Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-11-12 0:00 Answering an Ada/COBOL Question Richard D Riehle 1999-11-13 0:00 ` Brian Rogoff 1999-11-14 0:00 ` Robert Dewar 1999-11-13 0:00 ` Brian Rogoff 1999-11-14 0:00 ` Robert Dewar 1999-11-14 0:00 ` Brian Rogoff 1999-11-15 0:00 ` Richard D Riehle 1999-11-15 0:00 ` Brian Rogoff 1999-11-16 0:00 ` Erlang (Was Re: Answering an Ada/COBOL Question) Vladimir Olensky 1999-11-16 0:00 ` Vladimir Olensky 1999-11-17 0:00 ` Samuel Tardieu 1999-11-19 0:00 ` Robert Dewar 1999-11-22 0:00 ` Samuel Tardieu 1999-11-22 0:00 ` Brian Rogoff 1999-11-17 0:00 ` Samuel Tardieu 1999-11-18 0:00 ` Robert Dewar 1999-11-19 0:00 ` Vladimir Olensky 1999-11-19 0:00 ` Vladimir Olensky 1999-11-16 0:00 ` Answering an Ada/COBOL Question Robert Dewar 1999-11-16 0:00 ` Robert Dewar 1999-11-16 0:00 ` Richard D Riehle 1999-11-18 0:00 ` Robert Dewar 1999-11-18 0:00 ` tmoran 1999-11-19 0:00 ` Robert I. Eachus 1999-11-18 0:00 ` Marin Condic 1999-11-19 0:00 ` Robert Dewar 1999-11-19 0:00 ` Marin Condic 1999-11-19 0:00 ` Robert Dewar 1999-11-15 0:00 ` Joseph P Vlietstra 1999-11-15 0:00 ` Robert Dewar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox