Or, "4. ALGOL60 [4] had many nice features of languages today but was too theoretical: only existed on paper." Yet its reference 4, at https://en.wikipedia.org/wiki/ALGOL_60#ALGOL_60_implementati... , lists a number of ALGOL60 implementations even in the 1960s.
https://youtu.be/6v4Juzn10gM?t=3m41s
Can you imagine trying to make a robust, fast compiler for such a weak machine in tape batches on that weak machine? I could understand them giving up with BCPL as a useful result on that machine. The cost-benefit analysis of using a PDP-11 like an EDSAC is opposite. Wirth et al showed you could do better. C inventors just liked BCPL. I'd understand if they used BCPL to bootstrap a Modula-2 or other ALGOL subset with good design. Instead, they kept trying to force BCPL to do something it wasn't designed for... wait, it wasn't designed period lol. It was just what compiled on a 1940's calculating device.
It's bad foundations vs others' good foundations. Might have worked for them sure. Today, though, we need to know why they did it that way and why we definitely shouldn't if we don't absolutely have to. That's the point of the essay. Plus, to clear up associated misinformation.
In one sense, that's almost tautologically impossible. I presume you mean "like the other Algols", which makes it a non-absurd statement, but... could you expand or clarify what you mean here?
If so, I don't believe it's a good joke.
The joke is that the syntax of Algol didn't actually look all that much like what people mean when they say "Algol-like syntax". No curly braces anywhere to be seen.
Likely you have just been lucky :)
I had first started out in C, hacked around for a while, even made a few simple programs. But I wasn't ever able to get very far with it. My first Java app had me doing GUI programming right away and I was making things a lot faster than I could have ever done in C.
The problem was, there are two things a beginner needs to learn: how to solve problems with programming, and the particular programming language they are using. So I think it's best to keep one of those things very, very simple. And you tend to lose a lot of people from boredom if that thing is the types of problems you're solving. So we have to default to the language being simple.
Pointers and memory management are an implementation detail. They are important, but they aren't the job. The job is fulfilling requirements. Some days the requirements might be "fit inside this tiny box of memory", but it's far more likely to be "so, like, when I click on the link, the screen flickers. <you mean a new page loads?> Yeah, whatever, just make it stop flickering."
On the other hand: In my opinion, C is a good language to show beginning programmers how memory management is done. Basically, it could be a third learned language, after a scrip language (like python) and an OOP language (Java or C++).