New old guy. I'm a programmer by trade, and a COBOL programmer by hobby. Working with the ISO committee on the next COBOL 202x Standard. This pondering will meander a bit.
I'm of the opinion that there are three major branches of programming. Computer Science, Computer Engineering and Computer Business. COBOL (and a rare few others) takes up the entire Computer Business slice of the programming language pie. Languages like FOCAL slot into a Computer Engineering slice. All the other programming languages are Computer Science languages.
How would the D team feel if someone came by with a module for base 10 decimal arithmetic? Bankers like decimal math, and still lean heavily on COBOL for counting up the fractional pennies.
How would the D team feel if someone came up with a module for block IO? Mainframes are block and record IO machines. Byte streams are usually layered on block IO. This implies a lot of "fixed length" fields. Again, a COBOL strength, and auditors seem to appreciate bounded, predictable data.
How would the D team feel if someone pressed for EBCDIC support? Perhaps not internal, but as an option.
D is firmly in the Computer Science slice of the pie. All good. A highly competitive market. I'd put language counts at 1 to 10 in Computer Business, 10 to 100 in Computer Engineering, and 1000 to 10,000 in Computer Science.
Would discussing Computer Business features be welcomed by team D, ignored, or actively railed against as an unwanted distraction? If the answer is welcomed (or ignored) I might take a stab at writing some code. If it'd be an unwelcome distraction at this point in time, then it would be best to just let the beast lie.
Not the complete picture, but at the core, Computer Business needs/wants Decimal Math, Block IO, EBCDIC, and at least a nod to mainframe idioms, and historic input/output mechanisms ala 80 column Card Punch and fixed 132 column print widths.
Please note: I am not a lawyer. This impression is from internet rumour and activity, and not from any legally binding legal advice
A nifty thing about modern times, mainframes are not as inaccessible as they used to be. There is a Hercules s/390 emulator, and s/370 mode. That s/370 mode runs way old (but still relevant) Operating Systems for frames that have been deemed Public Domain. MVS 3.8j and VM/370 R6 from the 1970s and early 1980s. Hobbyists have extended these sources to tackle some quality of life issues, and new releases are being worked on, as I type this. Along with GCC v4 C compilation. Much to be learned from this. The hobby kits actually put you in charge of a frame OS. System administration lore of mainframes is usually on an as-needed basis, but the hobby kits are wide open for exploring those pieces of technarcana that most developers would never get a chance to be exposed to.
So, would adding features of Computer Business help or hurt D at this point? *As a carrot, and again this is wide eyed pondering, not yet based in any realities. I might be able to convince the standards team to open an Appendix in the COBOL Standard for D interoperability, much like the Ada Appendix B documentation. At this point in time, the little bits of interoperability in the COBOL specs are usually Java centric. D can do (or should do) Enterprise just as well as Java, but can anyone see D with Business saddles?
Have good, make well,