Re: Least Dangerous Way to Do This ?

[Shark8 <onewingedshark@gmail.com>]

On Tuesday, October 16, 2018 at 6:09:49 PM UTC-6, pat...@spellingbeewinnars.org wrote:
> Hi Shark8
> 
> I am actually pretty familiar with the interface to cobol package. I actually don't trust it. I am thinking about trying to improve it but in it's current condition, it could be a liability.
> 
> So Ada83 was pretty cool already but if we had Ada68 or Ada78 they would have 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 lines long. All identifiers were limited to 8 characters. There was not a single comment in it. So yes old COBOL is terrible. The thing is that the interfaces cobol package appears to be for this old code and not the current stuff.

Interesting.

> 
> In COBOL we have pointers, procedures(called programs) and functions. The spec file in the interfaces cobol package makes all kinds of false statements.

I'm rather looking forward to seeing your improved COBOL interface.
(We might even be able to replace Interfaces.COBOL, or perhaps add a new child-package like Interfaces.COBOL.ISO_1989_2014.)

> 
> GnuCOBOL generates intermediate C, so I can inspect it and see what is happening. At the moment I am better off with the interfaces C package.

Hm, are you going to use that as a bit of a feedback-loop in your design of a [new] COBOL interfacing package?
 
> I have wondered the same thing. People can write very reliable COBOL code but 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 COBOL 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 this much code in COBOL is very hard.

Indeed, and code-organization is one area that Ada really shines [IMO].

> 
> I hope you don't mind a bit of a rant but I think Ada has serious-serious advocacy issues. Adacore has done a horrible job and we could improve more as 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 webservers or telephony systems when this would actually be good things to do and so on.

I'm not bothered by your rant -- it actually mirrors a lot of the criticisms the Ada-community as-a-whole has. While I'm glad that AdaCore has interests in Ada, and does some good work, there are some big problems that "only one [viable, opensource] implementation" entails which isn't good for the language as-a-whole.

> 
> Books are terrible. You can read hundreds and hundreds of pages were all that is being demonstrated is some language feature you are never going to use 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 with 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 pure Ada, it's crazy to cover features from Ada2005 and Ada2012 and not providing 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 other languages ? isn't it more important to understand procedures, function and packages and how to use Ada with other languages?

Interesting critique.
I've heard it said that the problem is that there's no "entry/introductory level" books, rather than books as-a-whole.

> 
> 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 should not have happened. It's so simple in hindsight but I didn't realize that you could use Ada packages with other languages without "with"ing them into an Ada program. I patched byteswap with pragma export and called it from COBOL. I can now use an Ada library directly from COBOL without writing any Ada code. Fortran and C people could do the same, with some simple patching.

Hm?
Are you referring to simply compiling a package and linking to the resultant OBJ file? Or am I misunderstanding you?

> 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 libraries. GnuCOBOL has lots of facilities for interfacing with C, especially matching types but we still have to jump though some hoops such as appending nul bytes and so on.

Interesting, I'll take a look.

> 
> I am planning on patching as many Ada libraries as I can so that they can be 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 bases... Maybe even banks will see the value if I can do this, I write up lots of documentation and I can actually try to promote these concepts.
> 

I, for one, would love to see this.
There's a lot of value to be had here: keeping your main-system organized, proven (where possible), and ensuring that your main reporting/processing isn't being handed garbage is a big win.

> If one company is entrusted to promote Ada and all they want to do is service existing customers, the language will die out when there old customers finally switch to C++/Java etc..

Yep.
This is a big problem, in part because existing customers develop work-arounds for flaws and issues that they never voice (that's just how things are), whereas new customers will have different needs and ideas [and expectations] which often at least shed some light on issues.

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

I try.