Pondering. Computer Business. How serious this gets will be dependent on comments.

[btiffin]

Hello,

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,
Blue