From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,30df5a909ff1af4 X-Google-Attributes: gid103376,public From: Richard D Riehle Subject: Re: Answering an Ada/COBOL Question Date: 1999/11/15 Message-ID: <80piek$rd3$1@nntp1.atl.mindspring.net> X-Deja-AN: 548918821 References: <80hr16$5q2$1@nntp5.atl.mindspring.net> <80leu1$k3l$1@nnrp1.deja.com> <80mc1j$6fo$1@nnrp1.deja.com> Organization: MindSpring Enterprises X-Server-Date: 15 Nov 1999 18:12:36 GMT Newsgroups: comp.lang.ada Date: 1999-11-15T18:12:36+00:00 List-Id: In article , Brian Rogoff wrote: >On Sun, 14 Nov 1999, Robert Dewar wrote: >> In article >> , >> Brian Rogoff 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