Cobol Fallacy

Merge with ProgrammingLanguagesShouldNotModelEnglish?

The CobolFallacy is the idea that programming languages are hard because they're not in English; and that if you make a language that looks like EnglishLanguage, it'll be easy.

And is related to the CobolInference.

Similarly, legal writing is (mostly) in English, but that doesn't make it grokable by non lawyers.

The true barrier is that computers don't have any cultural background. CobolLanguage works on some business applications where you can treat everything like a number, but then only the part where the manager is supposed to read and understand the program. I think ObjectOrientedProgramming was meant as a way to provide the computer with the kind of cultural information it lacks. Taking the classic counter class example, once you create an instance of a counter, the computer knows that it can only be incremented. And, of course, UnitTests and other kinds of sanity checks can make a computer realize when things are going wrong. But until a computer can be said to understand things the way a human can, we can't apply human thinking to it. -- NickBensema (see TeachMeToSmoke, I think)

[The manager is supposed to read and understand the program???]

That's right, that was an explicit design goal of COBOL. That's part of its history.

[[No, they just pay you more if they think they can :-) ]]

To further support the COBOL fallacy, consider EnglishLikeFeatures of programming languages.

CobolLanguage was designed for more than just number manipulation. Whether it is easy to use and understand is related to the nature and complexity of the task. Treating everything like a number doesn't imply easiness or suitability for programming in COBOL at all. Perhaps one fallacy is the notion that awkward problems are made easier by use of a very limited language which embodies many arbitrary and inconvenient restrictions. How many programming language manuals bother to explain what the language is not good at doing?

It's not a complete fallacy, though. Consider the relative lack of acceptance of languages like AplLanguage or notations like the Z formal method.

I agree. It is a matter of degree. If you get carried away you have a mess, like CobolLanguage and SqlLanguage. Also, it is a subjective thing. What some people like or "get" faster will vary widely.

For instance: English would make a terrible programming language because of its ambiguity. You can only go so far with the 'make it like English' idea.

> If you get carried away you have a mess, like CobolLanguage and SqlLanguage.

Respectfully, I think such conclusions beg more questions than they answer. Is SQL a mess? Really? I use it every day, and just don't see why it ought to jump out at me that's it's a "mess".

Saying it's a "mess" is a subjective opinion, and negative opinions are often phrased as exaggerations -- but since you're very familiar with SQL, surely you are aware that it has been widely critiqued for not being ideally suited to the task it was designed to address? It certainly isn't perfect; equally obviously, it is extremely widely used successfully to get things done.

When people spend a lot of time talking up one language or denigrating another, I figure it has to be mostly either theology or aesthetics. Carpenters don't waste a lot of time cursing hammers because they're not screwdrivers. But programmers are always doing that with COBOL, or SQL, or pretty much any other language they are not fond of. The set of desirable traits a language can possibly have is always going to be greater than the set of desirable traits is actually has. Fortunately, there is usually a language well suited to one's specific needs. -- AnonymousDonor

Carpenters don't waste time cursing hammers because they all know about hammers and screwdrivers and wrenches and chainsaws and nobody stops them from using the appropriate tool. Do-it-yourselfers frequently do curse screwdrivers when they really need a wrench. And a carpenter would certainly curse if someone made him use a claw hammer instead of a crowbar for a big job.

SqlLanguage is a mess. I use it on a regular basis too, loved it when I first encountered it, and am slowly beginning to despise it. It's a mess because the underlying RelationalAlgebra is so much cleaner. If you've never seen the theory behind it, it'll seem like a useful tool. But if you have seen the theory, you realize that all this programming you'd taken as "necessary" is really just duplicated code.

I can't speak to COBOL as I've never used it. I've heard, from various people who have, that it was also generally a mess but did have some redeeming features.

People who spend a lot of time denigrating a language typically fit into one of two categories:

They haven't used the language and it's way beyond them.
They have used the language and it's way beneath them.

Unfortunately, it's often difficult to tell the two types apart. Usually you just have to go on background or their competency when programming in the language. For example, when RichardGabriel says ObjectsHaveFailed, people believe him because he was one of the prime movers behind the CommonLispObjectSystem and his company sold an early C++ IDE. When TopMind says ObjectsHaveFailed, everybody laughs because he hasn't demonstrated the most basic competency in OOP. When DavidMoon says EssExpressions are the wrong representation for programs (http://www.archub.org/arcsug.txt), people believe him because he invented most of MacLisp and CommonLisp. When <insert random Lisp hater> says EssExpressions are obtuse and hard to read, us SmugLispWeenies laugh because he hasn't even tried.

It's funny how so much of credibility comes down to AdHominem, but there's really no way around it. By definition, one's incapable of judging or recognizing ideas far above one's competency (BlubParadox), so the individual merit of the idea can't stand alone. -- JonathanTang

The Blub Paradox is Ad Hominem in itself -- William Burns

Epistemology is always difficult, it's not limited to this kind of thing. But notice that, if an expert gives a very specific concrete list of both positives and negatives, then ceteris paribus, it tends to indicate more domain expertise and more objective neutrality than when someone claims to know, but lists only negatives, and vague ones at that. As a rule of thumb. And things often aren't equal. LifesaBitchAndThenYouDie?, of course.

As far as "everybody laughs [at me]", a lot of the conflict is that I don't use the academic lingo that academics are used to and expect. Instead, I focus on what some have called "economic arguments" in terms of how is it reducing costs, for example, and how one can measure this. I reject ArgumentByElegance as the primary metric. What's it saving me in terms of mental, finger, and eyeball gymnastics. - top

[Top, I am staggered by the ramifying magnificence of your self-deception. If you merely avoided academic lingo and actually did focus on "economic arguments", then you might be onto something of value. My impression is that you're far more likely to mis-use academic terminology than avoid it, you're far more inclined to engage in meandering quibbling than "focus" on anything, and I don't think I've ever seen you present anything remotely like an "economic argument". Arguments require both evidence and logic, which curiously appear to be exactly the things you've been avoiding rather than academic lingo.]

This is largely because WetWare is the biggest factor in software-engineering, and WetWare is difficult to scientifically test without a huge budget. That's not my fault. I describe my argument the best I can from a WetWare perspective, but in the end it's largely about the human mind, not about math and machines. And your "scientific" performance is also lacking. Where's the scientific or math paper that "proves" that nulls are net bad? That it makes the optimizer's math easier perhaps may be true, but it may also make the code maintainer's job harder. You put too much thought into making the machine's job easier, not the human's. I suspect you are biased toward your pet theorem-proving engines ("God compiler"), and want to trick people into going this route to make your work more in demand. A theorem-proving system requires far more explicitness and BigDesignUpFront than most current practices.

["WetWare is the biggest factor in software-engineering"? Where have you used evidence and logic to support that hypothesis? So far, all you've done is make the claim -- you haven't argued the case. The rest of your post is quarrelsome nonsense.]

I've argued my case before many times. If you disagree, so be it. I don't know what to do about that other than producing a OfficialCertifiedDoubleBlindPeerReviewedPublishedStudy, which ain't gonna happen and you don't have either. Note that others have agreed that WetWare matters. I'm thus not the loner on that. - t

[I agree that "WetWare matters". I debate your assertion that it "is the biggest factor in software-engineering". Such an assertion doesn't even make sense, i.e., "biggest factor" in terms of what? I don't expect you to produce a "double-blind certified peer-reviewed published study" (though it would help), but I do expect you to produce evidence and/or logic. Otherwise, all you're doing is quibbling, which is not presenting or defending an argument. At its essence, it's nowt but repetition of your claim -- a claim that isn't any more convincing the fiftieth time it's made than the first time.]

Out of curiosity, may I ask what you would identify as the biggest factor?

[You may ask, and I'd love to answer. Unfortunately, I don't know what you mean by "biggest factor". It's like speculating on the "biggest factor" in aeronautical engineering. What could you answer? Funding? Manpower? Corporate governance? Technology? Materials? Air?]

Let me try to narrow this a bit for discussion purposes. Suppose your boss asked you for your top 3 suggestions to reduce the cost of aeronautical engineering without hurting quality. (In other words, assume quality level will remain the same.)

[Sorry, still not following. :-(]

Would you actually answer that way to your boss? I pity your performance review.

[I do answer that way to my boss, and have done so on several occasions, when I haven't understood what he's on about. In return, he appreciates my honesty and unwillingness to answer until I'm asked a reasonable question.]

To me it seems like a reasonable question. It's as if you cannot think "in the large", but rather can only answer and think in terms of very specific questions like those found on a school exam. Balancing myriad trade-offs is the hard part of our biz, and you are not helping there.

[Dude, I've been paid to help define corporate IT strategy for my clients, which is about as "in the large" as it gets, and I understand "balancing myriad trade-offs" and doing cost-benefit and risk analyses very well. I still have no idea what you're on about, and it seems that instead of re-phrasing or explaining your question, you've resorted to insults.]

Okay, I apologize. Maybe I'll take a vacation from this topic and come back to it some later time to see if I can reword the question.