Hacker News Reader

Comment by crdoconnor | Hacker News Reader

I find DSLs (especially turing complete DSLs) which try to emulate written English to be grating.

This was what COBOL attempted to do, and far from having the intended effect (allowing non-specialists to program), it actually just created new breeds of specialists who could understand this new and really rather bad programming language.

Capybara's isn't that bad, although trying to make a more human readable DSL that uses XPath is a little ironic. The robot framework is probably the language that does this that I hate the most because it's turing complete and, IMO, actually less readable and usable than the language it was built upon.

View on HN

COBOL was created 1959. Singly it out as an example of a DSL in this context is a bit like arguing against cars by pointing out the faults of the Model T Ford compared with a Tesla. It just isn't a very good or fair place to start the argument.

I'm not arguing, of course, that we should go back to using COBOL. But lets get the facts straight. By 1997, according to Wikipedia, "there were a total of 200 billion lines of COBOL in existence, which ran 80% of all business programs." It was, in other words, a massive success. How does that prove that DSL's are no good?

It's a little hard to wrap our heads around the state of computing in 1959. I'll just say that at the time it was a difficult even for academics at big universities to get good access to computers. Most of the readers of this site weren't even born yet. Yes, of course, COBOL's out of date. If it weren't that would be a miracle.

DSL's may or may not be a good thing, but bringing up COBOL is perhaps not the most effective way to reach a valid judgment on the subject.

>COBOL was created 1959. Singly it out as an example of a DSL in this context is a bit like arguing against cars by pointing out the faults of the Model T Ford compared with a Tesla.

It doesn't stack up well compared to FORTRAN or LISP, which were both its contemporaries, neither of which were actually really designed with readability in mind, whereas COBOL was.

>DSL's may or may not be a good thing

This wasn't about DSLs in general. It is about the anti-pattern (dating back to 1959) of using as much pseudo-English as possible in a language in a vain attempt to make it readable, and actually making it more unreadable.

> It doesn't stack up well compared to FORTRAN or LISP, which were both its contemporaries, neither of which were actually really designed with readability in mind, whereas COBOL was.

I dunno that I'd say that without substantial qualifications. Much as I hate COBOL, and little as I've used either, from what I remember of each I'd probably still prefer COBOL to Fortran for a large business application, if those were the only two choices I had.

I wouldn't want to use COBOL over Fortran for scientific computing, and I prefer Lisp over either for most things.

COBOL was a massive success. It is deployed everywhere and runs everything.

COBOL was a massive failure. It had a goal of producing a language that business people could use directly with no intervening programmers by being "English-like" and friendly. This totally and utterly failed.

These things are not contradictions.

Further, everything I know that was designed to be "English-like", cut out the programmers, and let the business people program directly has been a total and utter failure, on that metric. By contrast, there's a number of things that business people directly use all the time without programmers, like Excel macros, that aren't trying to attain friendliness through "being like English". Maybe there's something out there that has done both, but I've not heard of it.

I don't criticize COBOL for trying. It was an experiment that had to be tried, and I have strong opinions about it precisely because COBOL and others provide me the data points with which to have an opinion. But its popularity among programmers doesn't establish that it was successful in letting business people code directly.

> Further, everything I know that was designed to be "English-like", cut out the programmers, and let the business people program directly has been a total and utter failure, on that metric.

I would agree, though in many cases (SQL particularly is a strong example) that's often more a failure of the organizations using the technology than the technology itself.

It doesn't matter if you have business-side analysts that can use SQL if you by policy don't let anyone outside of the IT side of an organization have access and tools that allow the user to use SQL directly against the database.

The IT-as-high-priesthood cult in organizations is strong, and resistant to any application of technology that challenges the priesthood. And this is, IME, especially true in organizations where the IT organization (and particularly its leadership) isn't particularly technically strong to start with.

As do I, for semantic clarity reasons. One example is SQL, which is written in a different order than it is executed. Humans can reason quite well about many things that are expressed out of order, but instructions have never been one of those things. Ideally it shouldn't matter, as SQL is supposed to be declarative, but each step transforms the data in some way such that you need to know the order.

Datalog is interesting because there is no statement order...it is pure declarative. Every transformation has an output that is bound to a unique identifier, which makes reasoning about order sequential even if the words on the screen are not. As great as SQL is, it would be better if we could go back to the foundings of relational databases and make Datalog the default query engine.

The thing with SQL is that it was indeed written to allow English-like statements and to be an "easy to understand" language. If you take only the simplest SQL statements then it is easy to understand but with any complexity it indeed becomes hard.

Despite this, SQL is the most successful logic/declarative language in the world. I think it's been argued that Prolog and logic programming stalled because SQL is good enough for the largest domain that logic programming is useful for.

Ultimately, I don't think it's any missing feature in SQL that makes it hard to understand large statements - it's just that large logic statements are hard. Maybe some way to make expressions more modular - incrementally constructing "adjectives" for use where clauses for example. But much as we all like our pet improvement to logic expression, I don't think that's the problem.

I worked in COBOL in the early 80s and despite its bad reputation, I found it was well-suited for the tasks I was asked to perform with it. (Compared to the other languages I knew at the time: C, BASIC, Fortran and Pascal)

Interestingly, the thing I liked best about COBOL was the PIC clause, which was actually a notation for formatted output. It beat the hell out of printf, that's for sure.

Reply on news.ycombinator.com