> The fastest processing language... for what?

It seems pretty clear from context that it means for doing report generation and accounting things that COBOL is known for, not for LINPACK.

> it's never going to be faster than assembly on the same machine.

You are being unhelpfully pedantic. It is not insightful to say an optimal assembly program is going to be at least as fast as a compiler for a higher level language.

I reckon the guy in the article was referring to COBOL basically having fixed sized data structures. Having all your data structures of a fixed size does allow for alot of optimizations that would otherwise not be available. However, you can make fixed size data structures in any language, and the benefits of this is somewhat moot with the large caches and fast CPUs (compared to IO) of modern computer systems.

Actually it's very insightful since there are a lot of people who believe that a modern compiler can beat hand-written assembler code. Raising awareness about assembler and how the machine actually works equates to better working conditions for everyone, as we'll have more competent and knowledgeable colleagues then.

Modern compilers can often beat hand-written assembler code in practice. Theoretically they can't, but we don't live in the theoretical world. The common belief is true because most people understand the distinction.

How can that happen? One reason is choice of algorithms -- the same reason why two programmers using the same language to complete the same task can produce remarkably different results.

Another reason is profile-driven optimization -- in theory the assembly language programmer can do this too, but the effort of restructuring lots of handwritten code is too painful. Yes, it is done sometimes (eg, different inner loops for video codecs for different versions of x86 cpus).

Likewise, optimizers and superoptimizers understand the pipeline quirks of specific processors better than most people writing assembly language for x86-type processors and can produce better results.

Case in point. What you belive is a myth. It's not true. A compiler will never be able to beat a human at writing assembler code. Read any tutorial at constructing compilers to understand why.

It's bizarre and alarming that this fairly reasonable and well-informed (if somewhat hyperbolic) comment is downvoted into the deep grey.

Not a downvoted, but tempted.

The question ‘fastest at what’ is right there in the original quote - processing. Assembly isn’t commonly considered a ‘processing language’ and in the context processing is a term of art for the kind of batch processing tasks cobol was designed for.

Even that aside, we all ‘know’ assembly is the fastest. It’s a given. Nitpicking comments like that betrays a hostile attitude and lack of generosity of spirit. We shouldn’t have to post pages if caveats and justifications and hedging for a comment like that.

Attacks like this come across as intellectual grandstanding and aren’t actually contributing anything of value.

I agree all the indignation is a bit much. The B in COBOL stands for Business, so, surprise, it's good at business stuff. It's right there on the label.

I am not familiar with this sense of the term “processing”, so perhaps it's less widely understood than you think. I assumed that in the context it meant the kind of processing the Central Processing Unit and Graphics Processing Unit in my hand computer does, which is pretty broad.

So I thought it was a reasonable criticism of an overly broad or at least very ambiguous assertion, regardless of its motivation. It’s quite common for the best arguments against an argument to come from people who are hostile to it for whatever reason. More carefully defining the scope of things where we would expect COBOL to get top performance marks would make the conversation far more informative and productive.

As for assembly, there is now a broad class of problems for which CPU assembly is far from the fastest solution, because GPUs are faster. Even on the CPU, there is a widespread (but usually false) belief that compilers beat expert assembly programming. So perhaps to you it's a vacuously true statement that adds no useful information, I read it as rebutting a belief many readers may really have (though, unfortunately, only as a bare assertion.)

If you don't know, look it up or ask a question. Launching into argumentative nitpicky screeds that are actually it turns out irrelevant to the point in discussion is just annoying.

I think it's unreasonable to expect every comment about every bit of technology, old or new, discussed on HN to come with pages of preamble, caveats and definitions of terms.

As I said, I think you are mistaken about how widespread that definition is, so looking it up wouldn't have helped.