SoylentNews is people
SoylentNews
Submitted via IRC for Bytram
COBOL turns 60: Why it will outlive us all
I cut my programming teeth on IBM 360 Assembler. This shouldn't be anyone's first language. In computing's early years, the only languages were machine and assembler. In those days, computing science really was "science." Clearly, there needed to be an easier language for programming those hulking early mainframes. That language, named in September 1959, became Common Business-Oriented Language (COBOL).
The credit for coming up with the basic idea goes not to Grace Hopper, although she contributed to the language and promoted it, but to Mary Hawes. She was a Burroughs Corporation programmer who saw a need for a computer language. In March 1959, Hawes proposed that a new computer language be created. It would have an English-like vocabulary that could be used across different computers to perform basic business tasks.
Hawes talked Hopper and others into creating a vendor-neutral interoperable computer language. Hopper suggested they approach the Department of Defense (DoD) for funding and as a potential customer for the unnamed language. Business IT experts agreed, and in May 1959, 41 computer users and manufacturers met at the Pentagon. There, they formed the Short Range Committee of the Conference on Data Systems Languages (CODASYL).
Drawing on earlier business computer languages such as Remington Rand UNIVAC's FLOW-MATIC, which was largely the work of Grace Hopper, and IBM's Commercial Translator, the committee established that COBOL-written programs should resemble ordinary English.
But, even with the support of the DoD, IBM, and UNIVAC, COBOL's path forward wasn't clear. Honeywell proposed its own language, FACT, as the business programming language of the future. For a brief time, it appeared the earlier business developers would be FACT rather than COBOL programmers, but the hardware of the day couldn't support FACT. So, COBOL once more took the lead.
By that September, COBOL's basic syntax was nailed down, and COBOL programs were running by the summer of 1960. In December 1960, COBOL programs proved to be truly interoperable by running on computers from two different vendors. COBOL was on its way to becoming the first truly commercial programming language.
It would still be the business language of choice until well into the 1980s. And it's not done yet.
"While market sizing is difficult to specify with any accuracy, we do know the number of organizations running COBOL systems today is in the tens of thousands. It is impossible to estimate the tens of millions of end users who interface with COBOL-based applications on a daily basis, but the language's reliance is clearly seen with its use in 70 percent of global transaction processing systems."
(Score: 3, Insightful) by mobydisk on Friday September 06 2019, @06:02PM (5 children)
No. The answer is to escape them. Almost every format in existence has delimiter characters and escape sequences for them. CSV, JSON, XML, HTML, SGML, ASTM, HL7 and well as every programming language ever made. CSV was finally written as RFC 4180 back in 2005. That spec merely codifies the practices we used for the 20 years prior to that.
There's no excuse for not handling commas and quotes in CSV files correctly.
Which has the exact same problem, but with pipes instead of commas. One cannot design a format under the assumption that there is some magical character that is never used.
(Score: 0) by Anonymous Coward on Friday September 06 2019, @06:39PM
Different AC, but one thing we did when we had to pass weird Unicode data and large text values, we used a control character as our delimiter.
(Score: 0) by Anonymous Coward on Friday September 06 2019, @07:30PM
there is no excuse for using CSV if you have a choice.
ftfy.
(Score: 0) by Anonymous Coward on Friday September 06 2019, @11:53PM
Same exact problem? I don't think so.
I can easily have entire data sets without any pipe chars in them by definition. Try that with the ubiquitous comma.
(Score: 3, Informative) by jb on Saturday September 07 2019, @05:10AM
Yes one can, so long as one accepts the (usually far less problematic) assumption that those data are plain text (not arbitrary binary data).
That use case is exactly what the ASCII unit separator (US, 0x1f) and EBCDIC field separator (FS, 0x22) characters are meant for.
EBCDIC predates COBOL; ASCII came soon after. The much earlier (5- or 6-bit) Baudot code did not have an equivalent character (it did have an "FS", but that stood for "figure shift", which meant something quite different).
The primary reason for fixed-width fields in CODASYL, as many others have pointed out, was the limited number of columns on cards, which were still the most common I/O medium at the time, not any supposed superiority of fixed-width fields over field delimiters.
(Score: 2) by acid andy on Saturday September 07 2019, @02:50PM
My favorite is the XML escape sequence:
<![CDATA[...]]>
I don't know the exact origin of the syntax (something from SGML) but I just love the clunky way it seems to approach the problem by just throwing as many different characters at it as possible, reducing the likelihood the sequence will appear in the data.
If a cat has kittens, does a rat have rittens, a bat bittens and a mat mittens?