Indeed !

AKA: We want to be the only ones who can spy on *our* citizens - and these bozos will not sign a reciprocity of data collection with us (5 eyes and all).

COBOL is not your average Algol deriviative !

I'll grant the the 80-20% rule likely applies..

But things like Sequential vs Relative vs Indexed I/O, BCD (packed & zoned), multi-return option on PERFORM, etc...

I'd be more comfortable saying 'mediocre' instead of 'proficient'

Obviously a disgruntled and inexperienced mainframe user - sorry :-(

And yes, for a customer, I rewrote (from a hex dump) an old ASM routine that they'd lost the source for - simply so I could make it 64bit safe.

However, one does not need to go through CICS to compile a COBOL program - though your shop may have created a CICS transaction to do compiles.

As for IDEs, if you don't have ISPF and plugins for most of that, complain to your management! My first IDE was emacs (BSD 4.2) with functions to compile and point me at all the compiler messages.

As far as Java/AJAX/REST/XML/... yes there are still some rough edges - after all, these are, by and large, bolted on very old (and stable) code.

You owe me a new monitor :-)

APL/SV VS/APL, APL/2, or the new fangled ASCII keyboard friendly J ?

If you're game, I'll do the RTE hookup (I/O, BCD, ...)

I wrote the APL/SV -> APL/2 )MCOPY command ... ah the joys of EXCP level I/O :-)

Program by contract, anyone ?

That was supposed to be ADA but, at the time, compiler technology was not upto snuff - so things like:
* Loop pre-conditions
* Loop invariants
* Loop pst-conditions

Just were not validated.

But yeah, you obviously have never tried to reconstruct the logic of a 65K+ line long COBOL program :-(

(ftfy).

I learned Assembly fairly early on, and I would agree that, once knowing how the machine operates, it is much easier to express what you want in any higher level language (neglecting things like synchronization points) - even OO constructs often boil down to simple things - calling by pointer. I still write vastly more C than C++ code.

I have read more hex dumps than many extant programmers (long before IPCS), and can still read many opcodes (ld, st, ...) - but I would not recommend starting at that level. Assembly and/or (restricted) C code fulfill the requisite learning objectives nicely enough.

However, this is not a path to a feature rich resume (lacking in super models).

Well, when was the last time you spent some quality time perusing the micro-fiche PL/X listings for MVS (doubt they still exist for z/OS) ?
The barrier for entry is quite high here... for the nonce !

Joe random hacker isn't going to easily get access to a z/OS (or z/VM) image to start inspecting object files for issues

> I've had to resort to using FORTRAN to C converters several times, mainly to turn code written by scientists into something useful in a product. It was ALWAYS worth the effort!

Really ? Do you not understand the largest difference in FORTAN and all other current languages ?

In many applications, the difference may not be noticable, but in many mathematical cores, the transformation is fatal !

FORTRAN stores arrays in Column major order, whereas nearly everyone else stores them in Row major order.

This difference can be the difference betwixt high order page/cache/tlb misses, and running/scaling smoothly

Patently false... Last I checked there were still more lines of COBOL in business and government than all the other languages, combined.

I'll grant the fact that new comers don't want to get their hands dirty... they want something that enhances the resume for the next job... Something we see with all the 'legacy languages'.

I played vanguard during the stupid Y2K false apocalypse - writing superviser level code to track storage from a date field all the way through a program, in order to generate a report saying 'This field is a data, or is based upon a date value'.

I don't plan on doing updating that code for the Y2038 issue, but I fully expect COBOL & PL/I to still be in wide use at that time

See comment above wrt ANDF

It is simply not practical in the normative case, especially if you're looking for a resultant code suite that &language_du_jour jockey can read and maintain.

Full agreement, on most all accounts !

As noted above (AC, sorry - fscked up), modern COBOL has many of the flaws of other major languages (even pointers, &diety forbid).

The control flow of old COBOL programs is horrendous (I've seen > 65K line, monolithic programs), where a C++ guy would do a metric crap-tonne of 20+ line functions.

COBOL PERFORM flow is covered by a (5, maybe 4) way return function - optimization under patent. It drives optimizer folk bat-shit crazy (as if they weren't already there) :-)

I have also seen an inordinate amount of old and new programmers who fail to grasp the power of the COBOL I/O system - and pay dearly in runtime costs because they chose the wrong file organization...

Really, have we learned nothing from ANDF (https://en.wikipedia.org/wiki/Architecture_Neutral_Distribution_Format) ?

I actually started down this path, but got side tracked by earning a living wage.

The idea was to take a PL/I and Ada basis as an IL, and provide language based decoder/encoder - so one could achieve idiomatic code in any Source->Source translation.

Interesting yes, lucrative - kinda... There are companies that make their living doing this... but the bugaboo is in the details, especially with PL/I deriviatives and the macro processor.

Yes, according identity relationships, n / n == 1.

But, as I mentioned above, APL is the only language I am aware of that got this correct.

Please don't forget that dividing by zero is *not* always zero (or, simply, undefined) !

Anything divided by itself is one - something most everything but APL gets incorrect :-(

That is a very good question. The quest for an UNCOL (http://en.wikipedia.org/wiki/UNCOL) goes back to the mid 1950s.

A terse, but readable history/background upto and including early ANDF (http://homepage.ntlworld.com/michael.harley/uncol.html) This paper seems to argue that a change in relative costs betwixt machines and programmers changed the landscape to where the complexity was not worth doing a true UNCOL.

Things changed from complexity to business politics, much like we see now with cell carriers (and lockin), customers wanted to be able to move work from one vendor to another, and up sprang another organization to guide that - the OSF (http://en.wikipedia.org/wiki/Open_Software_Foundation)

A changing playing field (enter MS and Apple) and business politics seemed to doom OSF and most of its work - as it turned to 'every man for himself' until Linux came into being and pretty much changed everything... How many vendors still have their own Unix ?

I've been playing in this industry since the mid 1970s, professionally since the early 1980s - most all with a bent towards compilers and operating systems.

My reading of the tea leaves entails a re-birth of the UNCOL idea - and again, due to changing relative man/machine costs, and the prevalence of the IoT.

I believe we actually wind up with the ANDF variant of UNCOL
* You compile language du-jour (with whatever optimization, say to SSA, you can do at a high level), and generate a distribution package (apk, deb, rpm) that includes the UNCOL instead of binaries.
* At install time, the UNCOL is compiled to native (for some definition of native) code... This too, should be optimized

This is where Android is already moving - ART vs Davlik. On smaller devices, you don't want the interpretation overhead unless you have a scheme to handle JiT and building up a native application as the various codepaths are exercised.

Today, we have fewer architectures to contend with (x64, arm, ppc), a better battering ram (open source/crowd source & funding) - ie, driving from the correct side.

This still requires effort by the hardware business to create the UNCOL->Native binary