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=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:a5e:8d06:: with SMTP id m6-v6mr18217686ioj.6.1539734988357; Tue, 16 Oct 2018 17:09:48 -0700 (PDT) X-Received: by 2002:aca:c656:: with SMTP id w83-v6mr416762oif.2.1539734988044; Tue, 16 Oct 2018 17:09:48 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.gegeweb.eu!gegeweb.org!usenet-fr.net!proxad.net!feeder1-2.proxad.net!209.85.166.216.MISMATCH!x98-v6no117149ita.0!news-out.google.com!n199-v6ni139itn.0!nntp.google.com!z5-v6no116230ite.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 16 Oct 2018 17:09:47 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=2607:f2c0:f200:1405:440f:d5c3:e46b:1699; posting-account=cUi90woAAADTaOISowbbHM8GUD0-opJO NNTP-Posting-Host: 2607:f2c0:f200:1405:440f:d5c3:e46b:1699 References: <75787881-026d-498f-b934-e9359b9f5cf0@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Least Dangerous Way to Do This ? From: patrick@spellingbeewinnars.org Injection-Date: Wed, 17 Oct 2018 00:09:48 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:54610 Date: 2018-10-16T17:09:47-07:00 List-Id: Hi Shark8 I am actually pretty familiar with the interface to cobol package. I actual= ly don't trust it. I am thinking about trying to improve it but in it's cur= rent condition, it could be a liability. So Ada83 was pretty cool already but if we had Ada68 or Ada78 they would ha= ve sucked large. COBOL68 and COBOL73 suck and the language is still haunted= by criticism from this time. When I first started with GnuCOBOL(called Open-Cobol at the time) I thought= it was awesome and that the critics must all be insane and then I saw code= from 68 and 73 revisions. One program(like a procedure) was almost 10000 l= ines long. All identifiers were limited to 8 characters. There was not a si= ngle comment in it. So yes old COBOL is terrible. The thing is that the int= erfaces cobol package appears to be for this old code and not the current s= tuff. In COBOL we have pointers, procedures(called programs) and functions. The s= pec file in the interfaces cobol package makes all kinds of false statement= s. GnuCOBOL generates intermediate C, so I can inspect it and see what is happ= ening. At the moment I am better off with the interfaces C package. I have wondered the same thing. People can write very reliable COBOL code b= ut there are some topics related to calling other procedures(programs) that= could be a concern for the most critical portions, this is where Ada would= really shine in banking, yet it doesn't. Ada has much better facilities for organizing huge amounts of code yet COBO= L likely has far larger code bases. I think one bank has something like 130= million lines of COBOL, I could borrow the library book I read this in, to= get the exact amount if your interested but the point is that organizing t= his much code in COBOL is very hard. I hope you don't mind a bit of a rant but I think Ada has serious-serious a= dvocacy issues. Adacore has done a horrible job and we could improve more a= s a community too. Catering to existing Adacore customers does not move the= language forward. Adacore did not move to microcontrollers for the longest= time and it has staff that go around telling people not to use Ada for web= servers or telephony systems when this would actually be good things to do = and so on. People using Ada for fun like on AVRs and on the Raspberry Pi are doing goo= d work. We really need to show people what can be done with it and done wit= h it for fun. Books are terrible. You can read hundreds and hundreds of pages were all th= at is being demonstrated is some language feature you are never going to us= e and text_io displaying something. I have 53lbs of Ada books(and counting)= and in all this I think I have 2 or 3 pages that deal with interfacing wit= h real hardware and there is next to no information about interfacing with = other languages. How many new application these days are going to be in pur= e Ada, it's crazy to cover features from Ada2005 and Ada2012 and not provid= ing any examples of interfacing with other languages. What are you actually= going to do with interfaces in a new code base that has no contact with ot= her languages ? isn't it more important to understand procedures, function = and packages and how to use Ada with other languages? Today is a special day for me. I realized something super-awesome about Ada= that no one told me about and that I did not read about and this really sh= ould not have happened. It's so simple in hindsight but I didn't realize th= at you could use Ada packages with other languages without "with"ing them i= nto an Ada program. I patched byteswap with pragma export and called it fro= m COBOL. I can now use an Ada library directly from COBOL without writing a= ny Ada code. Fortran and C people could do the same, with some simple patch= ing. So I can't verify that any of this is true but according to MicroFocus, a c= ompany with a vested interest in COBOL(and that sued a city here in Canada = for having too many copies of their software) the cost to replace COBOL in = the USA would be over 1 trillion. They say that there is hundreds of billio= ns of lines of code in use. Others have said that there is more COBOL code = than all other languages combined. Again, I am not saying that all of this = is true, it could be fanboy propaganda but certainly there is mountains of = it. Please see this site(it is a lot of material on one page and can be slow to= load): https://open-cobol.sourceforge.io/faq/index.html This will give a good overview of the language. There is a small part that = touches on Ada. However look at this code, it's almost all using C librarie= s. GnuCOBOL has lots of facilities for interfacing with C, especially match= ing types but we still have to jump though some hoops such as appending nul= bytes and so on. Ada and COBOL are much closer then COBOL and C and Ada has tons of faciliti= es for working with other languages, such as it's type system and strings.f= ixed to match COBOL's and so on, they are just poorly documented. I am planning on patching as many Ada libraries as I can so that they can b= e used from GnuCOBOL. There is so much functionality that we don't have in = our community. Imagine if this ends up being used by existing COBOL code ba= ses... Maybe even banks will see the value if I can do this, I write up lot= s of documentation and I can actually try to promote these concepts. If one company is entrusted to promote Ada and all they want to do is servi= ce existing customers, the language will die out when there old customers f= inally switch to C++/Java etc.. There is so much to promote and so much value to be had but Ada instruction= books and Adacore are not going to get the word out, we need to !