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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no 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: Brian Rogoff Subject: Re: Answering an Ada/COBOL Question Date: 1999/11/15 Message-ID: #1/1 X-Deja-AN: 549139160 References: <80hr16$5q2$1@nntp5.atl.mindspring.net> <80leu1$k3l$1@nnrp1.deja.com> <80mc1j$6fo$1@nnrp1.deja.com> <80piek$rd3$1@nntp1.atl.mindspring.net> Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: nntp1.ba.best.com 942727118 233 bpr@206.184.139.136 MIME-Version: 1.0 Newsgroups: comp.lang.ada Date: 1999-11-15T00:00:00+00:00 List-Id: On Mon, 15 Nov 1999, Richard D Riehle wrote: > 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. 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