6 ms·

I worked with COBOL near the end of my last contract and found aspects of it fascinating compared to today's languages. Everything is about structures that map

I worked with COBOL near the end of my last contract and found aspects of it fascinating compared to today's languages. Everything is about structures that map directly to the bits on disk, with fine grain control on precision and data types. But then the language reads as a series of macros where you don't have to remember the low level details: do this to this, put this here, if this do that. It's also a terribly difficult language to parse because it was designed for ease of use by humans. This was at a time when programmers were thought of as translators that mainly converted human language to binary. There is an element of independence to COBOL that I wasn't expecting, and I imagine there was some resistance to it when it was first introduced. I didn't know Grace Hopper was behind COBOL until I was actually using it, but I wonder sometimes if the challenges she faced as a woman at that time influenced its design. It's probably the first language to really confront dogma in computer science. I personally really enjoy learning about languages like Erlang and Lisp but they have an achilles heal that everybody is in real denial about. They are very difficult to read once they've been written. So most programmers scrap what they've written and start over. COBOL isn't like that. Even someone unfamiliar with computer science (all those business types who don't have time for this stuff) could read it and get a general understanding of what it's doing. The only other language I've used that surpasses COBOL in readability is Hypertalk, invented by Bill Atkinson in the 1980s. I look at some of the top languages and methodologies today, say Ruby and Angular.js and I wonder if we're racing down a rabbit hole. Conceptually what they are trying to do is admirable but they are starting to feel like dogma to me. How do they help the average person accomplish what they are trying to do? I've only seen the one interview with Grace Hopper on David Letterman but I have to wonder if she was a hacker in today's world what she would think of the current state of things.

jadyoyster 13y ago
I've always wondered what people mean when they say Lisp & co are hard to read. I'd think having great powers of abstraction would produce code that reads more easily. Of course you have to figure out what the abstractions do, but is that really worse than having to reverse engineer low-level non-abstractions on the fly even if they're in a "human readable" language?
- skybrian 13y ago
  This depends on the kind of abstraction. The closer programming is to math, the less likely it is that anyone other than mathematicians can read it, because they're not familiar with the abstractions you're using and they're hard to learn. (And even simple mathematical abstractions are hard because there's no domain-specific content to them; it just looks like abstract nonsense.) It's also possible to use abstraction to get closer to how your customers think, but only if you use abstractions that they already know from the target domain.
jerf 13y ago
It's not dogma anymore. It may have been dogma at the time of COBOL, but now we know plain-English programming general purpose programming languages are a bad idea, because we've tried any number of times, and in general if you don't produce an atrocity, you're doing well above average. You end up with a language that is still every bit as complex as a normal programming language, and you add the ambiguity of English to the problem. Instead of it being a win, you lose, badly. You can do better if you rigidly constrain your DSL's domain, but I'd argue that in many cases you're still looking at "spending" some design juice on a "plain English" interface and it's not at all clear that you've produced something that is improved by the "plain English" so much as produced something that had enough design budget left to absorb the penalty without being destroyed. It's 2013 now, not 1970. Any time you're tempted to go "My goodness, programming would just be so easy if we did X", go out and look. Odds approach 100% that we've done X, many, many times, and the reason you've never heard about it is that it didn't work well enough to be talked about. See also "fully visual programming language" and any number of "business logic" initiatives over the years. (To which the typical next cognitive reaction is to believe that it would work if we just poured more effort into it. That may be true, but it's worth pointing out you're entering into unprovable territory. And in many cases, part of the idea really is that X is just so obvious and great that even a partial implementation ought to show its promise immediately.)
- zeckalpha 13y ago
  I think you need to watch Bret Victor's talk at DBX. http://vimeo.com/71278954 http://vimeo.com/71278954
  - jessedhillon 13y ago
    Yeah everyone's seen that talk. Any technology can look cool for 5 minutes. He really neglects to observe that all of the ideas he presented were thoroughly explored during their time -- and repeatedly in the decades since. The conclusion continues to be that such systems are inferior to our current ways. That may be because nobody has pushed hard enough, but it's not because those systems, as implemented, were good enough if only someone would just pay attention.
- 13y ago
cafard 13y ago
Having had to deal with a little COBOL now and then, I wonder whether English words are really what makes for readability. I am reminded of something that Jacques Barzun wrote long ago about English, that it is the density of the thought, not the length of the words, that makes for difficulty in reading.
- cam_l 13y ago
  To enlarge on your (really good) point.. We also have the capacity in english to substantially reduce the overhead of thought density. We do this by using symbols or signifiers (words or phrases) which refer to oft repeated concepts, allowing us to build more complex meanings without having to consciously process every part. This idea of density of thought can be expressed more specifically as both uniqueness and complexity of thought. Conceptually, programming is communication, and all communication is essentially semantic. Though not being a programmer, I reckon the broader conceptual difficulties with programming are in the need for context, and with the necessity for specificity. Which, by the way, english is not that brilliant at either (just more flexible). It is instructive in the context of this discussion to remember that semantics rely as much on the experience and understanding of the listener, as on the speaker / writer.
- jloughry 13y ago
  I did something like that once for a truly awful machine-language-like system I had to work with at a bank: 8607,,,1 11547,15475,22002,22002 1316,1629,1,1649 3001,1316,3,30078 11528,22052,22002,22002 9301,0,1528,1528 31568,10001,800,107 8560,,,1568 8550,210,, 3001,,, 3100,1316,3,30089 11547,15475,22002,22002 3001,1316,3,30089 3001,1317,3,10000 8400,,, 8550,700,801, 3001,,, 9301,0,522,522 3000,1284,3,10001 8500,,3, 8500,,5, 1547,,1,-2301 Through the translator, the result looked like this: https://github.com/jloughry/BANCStar/blob/master/README.md https://github.com/jloughry/BANCStar/blob/master/README.md The arrows in the margin duplicated the handwritten notation developed by programmers to deal with the numeric machine code. If a colour printer had been available at the time, it would have duplicated the highlighter pens those programmers used too; instead I used boldface, italics, underlining, and condensed characters to accomplish the same thing.

jadyoyster 13y ago

I've always wondered what people mean when they say Lisp & co are hard to read. I'd think having great powers of abstraction would produce code that reads more easily. Of course you have to figure out what the abstractions do, but is that really worse than having to reverse engineer low-level non-abstractions on the fly even if they're in a "human readable" language?

skybrian 13y ago
This depends on the kind of abstraction. The closer programming is to math, the less likely it is that anyone other than mathematicians can read it, because they're not familiar with the abstractions you're using and they're hard to learn. (And even simple mathematical abstractions are hard because there's no domain-specific content to them; it just looks like abstract nonsense.) It's also possible to use abstraction to get closer to how your customers think, but only if you use abstractions that they already know from the target domain.

jerf 13y ago

It's not dogma anymore. It may have been dogma at the time of COBOL, but now we know plain-English programming general purpose programming languages are a bad idea, because we've tried any number of times, and in general if you don't produce an atrocity, you're doing well above average. You end up with a language that is still every bit as complex as a normal programming language, and you add the ambiguity of English to the problem. Instead of it being a win, you lose, badly. You can do better if you rigidly constrain your DSL's domain, but I'd argue that in many cases you're still looking at "spending" some design juice on a "plain English" interface and it's not at all clear that you've produced something that is improved by the "plain English" so much as produced something that had enough design budget left to absorb the penalty without being destroyed. It's 2013 now, not 1970. Any time you're tempted to go "My goodness, programming would just be so easy if we did X", go out and look. Odds approach 100% that we've done X, many, many times, and the reason you've never heard about it is that it didn't work well enough to be talked about. See also "fully visual programming language" and any number of "business logic" initiatives over the years. (To which the typical next cognitive reaction is to believe that it would work if we just poured more effort into it. That may be true, but it's worth pointing out you're entering into unprovable territory. And in many cases, part of the idea really is that X is just so obvious and great that even a partial implementation ought to show its promise immediately.)

zeckalpha 13y ago
I think you need to watch Bret Victor's talk at DBX. http://vimeo.com/71278954 http://vimeo.com/71278954
- jessedhillon 13y ago
  Yeah everyone's seen that talk. Any technology can look cool for 5 minutes. He really neglects to observe that all of the ideas he presented were thoroughly explored during their time -- and repeatedly in the decades since. The conclusion continues to be that such systems are inferior to our current ways. That may be because nobody has pushed hard enough, but it's not because those systems, as implemented, were good enough if only someone would just pay attention.
13y ago

cafard 13y ago

Having had to deal with a little COBOL now and then, I wonder whether English words are really what makes for readability. I am reminded of something that Jacques Barzun wrote long ago about English, that it is the density of the thought, not the length of the words, that makes for difficulty in reading.

cam_l 13y ago
To enlarge on your (really good) point.. We also have the capacity in english to substantially reduce the overhead of thought density. We do this by using symbols or signifiers (words or phrases) which refer to oft repeated concepts, allowing us to build more complex meanings without having to consciously process every part. This idea of density of thought can be expressed more specifically as both uniqueness and complexity of thought. Conceptually, programming is communication, and all communication is essentially semantic. Though not being a programmer, I reckon the broader conceptual difficulties with programming are in the need for context, and with the necessity for specificity. Which, by the way, english is not that brilliant at either (just more flexible). It is instructive in the context of this discussion to remember that semantics rely as much on the experience and understanding of the listener, as on the speaker / writer.
jloughry 13y ago
I did something like that once for a truly awful machine-language-like system I had to work with at a bank: 8607,,,1 11547,15475,22002,22002 1316,1629,1,1649 3001,1316,3,30078 11528,22052,22002,22002 9301,0,1528,1528 31568,10001,800,107 8560,,,1568 8550,210,, 3001,,, 3100,1316,3,30089 11547,15475,22002,22002 3001,1316,3,30089 3001,1317,3,10000 8400,,, 8550,700,801, 3001,,, 9301,0,522,522 3000,1284,3,10001 8500,,3, 8500,,5, 1547,,1,-2301 Through the translator, the result looked like this: https://github.com/jloughry/BANCStar/blob/master/README.md https://github.com/jloughry/BANCStar/blob/master/README.md The arrows in the margin duplicated the handwritten notation developed by programmers to deal with the numeric machine code. If a colour printer had been available at the time, it would have duplicated the highlighter pens those programmers used too; instead I used boldface, italics, underlining, and condensed characters to accomplish the same thing.