4 ms·

I once had the pleasure to meet a young person (~30 years old at the time) who had learned to program at a bank, so I had to ask her about COBOL. Her reply was

by krylon 10y ago

I once had the pleasure to meet a young person (~30 years old at the time) who had learned to program at a bank, so I had to ask her about COBOL. Her reply was interesting, if I looked at it as a general-purpose language like C++/C#/Java, then, yes, it sucks really hard. But if you look at COBOL as a DSL for building specific business applications, it does not look all that bad. Having never used COBOL beyond a simple HELLO-WORLD, I am not sure I can judge it either way. But her reply sounded surprisingly pragmatic to me.

mikestew 10y ago
if I looked at it as a general-purpose language like C++/C#/Java, then, yes, it sucks really hard. Plenty of people get by swinging a hammer all day and not a Swiss army knife. COBOL is one person's hammer. For me, at one point, it was RPG. You think COBOL is "domain specific"? RPG has the DSL right in the name: "Report Program Generator". Yuppers, RPG is a report writer. And when you're writing banking software or the like, which is just inputs munged into outputs, RPG did the job. Why use a language with shitty, dangerous string handling, no syntactic sugar for the task at hand, whose output keyword consists of "printf", dragging along a runtime with crap I'll never use, and other "general purpose" language problems when you can use a language crafted specifically for what you're trying to do? I made plenty of money back in the day writing FoxPro. FoxPro sucks for embedded systems and writing an operating system. But ya know what it doesn't suck at? Taking some data, transforming it, do a little munging, and print some output. Which was precisely what customers were paying me to do at the time, and not writing a Windows competitor.
- pjmlp 10y ago
  FoxPro! :) I was in the other side of xBase languages, did some dBase III Plus stuff, Clipper Summer '87 followed by OOP with Clipper 5.x, hurray! High level programming in MS-DOS and were just perfect for crushing out database frontends.
  - marktangotango 10y ago
    I'm continually surprised there's not a widely adopted, xBase variant for the web. It seems so obvious? Maybe there is and I'm just not aware of it.
  - krylon 10y ago
    In my first job after my training, I had a boss who had practically written a couple of bespoke line-of-business applications for customers using FoxPro. Three years ago I had to do some maintenance on an old-ish C++ application (also a one-of-a-kind-thing) that used a dBase backend for storage. I was lucky, though, the code was very well-written and, let's say, humble - it avoided unneccessary complexities whenever possible, and even without comments or any other documentation, I was able to figure out how it worked (at least the part that I was supposed to modify). Part of the fun was getting a development environment to work with an ancient version of Visual Studio, but the second fun part was accessing that dBase database. I tried a couple of programs, none of them overly helpful, until I realized that ____ing Excel could open them. I don't know how well Excel supports interacting with these, but it worked well enough for inspection. ;-)
    - mikestew 10y ago
      Excel should have worked just fine. The DBF format is not hard to understand, and it was documented in the manual that came with (IIRC) both dBase and FoxPro (I can still picture the page in my head from the FoxBase+ manual). Just a header with a record count and some field definitions, then the data. I haven't tried, but I bet with the docs in front of me I could write a parser in any number of languages in about 30 minutes, 30 minutes more to write to the DBF without corrupting it. You're on your own for indices, I never had to crack that nut. :-)
      - pjmlp 10y ago
        Yes, sometime around 1992 I got a Turbo Pascal unit as shareware, that could handle them. Indexes were some form of B+ Trees. Back in those days I toyed with the idea of porting it to Turbo Pascal for Windows, but then never got to do it actually.
- krylon 10y ago
  That is what that programmer told me, isn't it? COBOL was designed for a specific purpose, and according to her, having used it for that exact purpose, it gets the job done. COBOL seems to be the language hackers love to hate, but there is a reason it is still around. During my training I once had a supervisor who spent years writing reports in RPG on an AS/400. She had interesting stories to tell, but unfortunately, she was always far too busy to actually tell them. :-(
kpil 10y ago
I don't buy the DSL argument, as it's not more suitable for any domain than any other language unless shuffling COBOL specific data structures from a DL/1 database counts as a domain. Interestingly, Lisp is (slightly) older than COBOL and is actually truly living up to the DSL thing - at least nowadays. Both languages are actually centered around data structures - kind of, but while COBOL is massively built on fixed structures and boilerplate, lisp is built around dynamic structures of lists (and pairs - or CONS) . It's interesting that they were invented more or less at the same time, as COBOL feels as dated as anything can be, and Lisp feels rather ok. Scheme (a dialect) is more than 40 years old and is actually rather fun to program in, and feels modern in more or less every sense.
- groovy2shoes 10y ago
  The Scheme of today is extremely different from the Scheme of 40 years ago. Comparing the language of R0RS and R1RS with R5RS, you'll see just how different they are. I'd say that "modern" Scheme is due more to Clinger than to Sussman & Steele! My point is that, yes, Scheme as a concept originated in the mid 70s, but it has been updated many times over the years. The Scheme of today isn't 40 years old.
- kazinator 10y ago
  Lisp source code is built around structures of lists built on cons pairs (and numbers, symbols, string literals, other kinds of literals, ...). (COBOL source code is just characters.) Lisp data structures are varied. CLOS objects, multi-dimensional arrays, hash tables, strings, bit fields, ...
andrewbinstock 10y ago
Indeed, it's an excellent language for what it was designed for: mainline data processing, consisting primarily of reading databases and creating reports.

by krylon 10y ago

mikestew 10y ago

if I looked at it as a general-purpose language like C++/C#/Java, then, yes, it sucks really hard. Plenty of people get by swinging a hammer all day and not a Swiss army knife. COBOL is one person's hammer. For me, at one point, it was RPG. You think COBOL is "domain specific"? RPG has the DSL right in the name: "Report Program Generator". Yuppers, RPG is a report writer. And when you're writing banking software or the like, which is just inputs munged into outputs, RPG did the job. Why use a language with shitty, dangerous string handling, no syntactic sugar for the task at hand, whose output keyword consists of "printf", dragging along a runtime with crap I'll never use, and other "general purpose" language problems when you can use a language crafted specifically for what you're trying to do? I made plenty of money back in the day writing FoxPro. FoxPro sucks for embedded systems and writing an operating system. But ya know what it doesn't suck at? Taking some data, transforming it, do a little munging, and print some output. Which was precisely what customers were paying me to do at the time, and not writing a Windows competitor.

pjmlp 10y ago
FoxPro! :) I was in the other side of xBase languages, did some dBase III Plus stuff, Clipper Summer '87 followed by OOP with Clipper 5.x, hurray! High level programming in MS-DOS and were just perfect for crushing out database frontends.
- marktangotango 10y ago
  I'm continually surprised there's not a widely adopted, xBase variant for the web. It seems so obvious? Maybe there is and I'm just not aware of it.
- krylon 10y ago
  In my first job after my training, I had a boss who had practically written a couple of bespoke line-of-business applications for customers using FoxPro. Three years ago I had to do some maintenance on an old-ish C++ application (also a one-of-a-kind-thing) that used a dBase backend for storage. I was lucky, though, the code was very well-written and, let's say, humble - it avoided unneccessary complexities whenever possible, and even without comments or any other documentation, I was able to figure out how it worked (at least the part that I was supposed to modify). Part of the fun was getting a development environment to work with an ancient version of Visual Studio, but the second fun part was accessing that dBase database. I tried a couple of programs, none of them overly helpful, until I realized that ____ing Excel could open them. I don't know how well Excel supports interacting with these, but it worked well enough for inspection. ;-)
  - mikestew 10y ago
    Excel should have worked just fine. The DBF format is not hard to understand, and it was documented in the manual that came with (IIRC) both dBase and FoxPro (I can still picture the page in my head from the FoxBase+ manual). Just a header with a record count and some field definitions, then the data. I haven't tried, but I bet with the docs in front of me I could write a parser in any number of languages in about 30 minutes, 30 minutes more to write to the DBF without corrupting it. You're on your own for indices, I never had to crack that nut. :-)
    - pjmlp 10y ago
      Yes, sometime around 1992 I got a Turbo Pascal unit as shareware, that could handle them. Indexes were some form of B+ Trees. Back in those days I toyed with the idea of porting it to Turbo Pascal for Windows, but then never got to do it actually.
krylon 10y ago
That is what that programmer told me, isn't it? COBOL was designed for a specific purpose, and according to her, having used it for that exact purpose, it gets the job done. COBOL seems to be the language hackers love to hate, but there is a reason it is still around. During my training I once had a supervisor who spent years writing reports in RPG on an AS/400. She had interesting stories to tell, but unfortunately, she was always far too busy to actually tell them. :-(

kpil 10y ago

I don't buy the DSL argument, as it's not more suitable for any domain than any other language unless shuffling COBOL specific data structures from a DL/1 database counts as a domain. Interestingly, Lisp is (slightly) older than COBOL and is actually truly living up to the DSL thing - at least nowadays. Both languages are actually centered around data structures - kind of, but while COBOL is massively built on fixed structures and boilerplate, lisp is built around dynamic structures of lists (and pairs - or CONS) . It's interesting that they were invented more or less at the same time, as COBOL feels as dated as anything can be, and Lisp feels rather ok. Scheme (a dialect) is more than 40 years old and is actually rather fun to program in, and feels modern in more or less every sense.

groovy2shoes 10y ago
The Scheme of today is extremely different from the Scheme of 40 years ago. Comparing the language of R0RS and R1RS with R5RS, you'll see just how different they are. I'd say that "modern" Scheme is due more to Clinger than to Sussman & Steele! My point is that, yes, Scheme as a concept originated in the mid 70s, but it has been updated many times over the years. The Scheme of today isn't 40 years old.
kazinator 10y ago
Lisp source code is built around structures of lists built on cons pairs (and numbers, symbols, string literals, other kinds of literals, ...). (COBOL source code is just characters.) Lisp data structures are varied. CLOS objects, multi-dimensional arrays, hash tables, strings, bit fields, ...

andrewbinstock 10y ago

Indeed, it's an excellent language for what it was designed for: mainline data processing, consisting primarily of reading databases and creating reports.