> A lot! Garbage collection, no unsafe pointer arithmetic, type specification different from variable use (varname: type)

Hmm, I'll give you the last one, although they left out the colon. The others are common to basically all high-level languages, so I don't really think of them as due to Wirth's influence. To my eye, the interesting aspects of Golang are interfaces, slices, and goroutines, none of which are present or even hinted at in Oberon. Interfaces were kind of anticipated in OCaml, slices in D, and goroutines in a family of CSP-derived languages going back to 1980.

> > ALGOL-60 doesn't have bitwise operations

> It was just not standard only because CPU instruction sets were not standard enough. [ALGOL-68]

Well, on one hand, it wouldn't be very useful to try to do bitwise AND on a decimal machine. But the original claim is that, prior to C, general-purpose (i.e. not purely numerical!) programs gained so much speed by being written nonportably that portable versions could not compete, and C enabled high-performance programs to be written portably. Your original rebuttal, as I read it, was that 10 years prior to C (i.e. in 1963) ALGOL had already achieved this.

We can stipulate, I hope, that bitwise operations are crucial for the inner loops of a lot of important algorithms.

Now, it appears that you're saying that not only had ALGOL not achieved this in 1963, but that it was impossible for any language to achieve it in 1963 because CPUs were too disparate, but that ALGOL-68, whose first usable implementations were concurrent with the first usable implementations of C, still didn't standardize those operations, so you still couldn't write portable programs that used them! (Although you could write programs for one or another ALGOL compiler that used them.)

I think you have proved the point of the original article rather than rebutting it.

> FORTRAN had [more than one precision of floating-point], C didn't care initially. And FORTRAN remained faster for long.

For numerical code, yes. But I was talking about the inadequacies of ALGOL-60, not Fortran (which is still faster, as you alluded to earlier). C's limited support for single-precision floating point was a sore point for decades, but not supporting it at all, as standard ALGOL-60 didn't, is much worse. It doubles the size of all your arrays! That's much worse than simply doubling or quadrupling your run-time, as C could; you can almost always run the program for twice as long, but you can only rarely double the core at its disposal.

> sorry, "lite" "closer to the system" language was even before Pascal and obviously before C, it was a bootstrap language for ALGOL W in sixties, see sources:

> http://bitsavers.org/pdf/stanford/listing/Algol_W_Listing_No...

That code is written in PL360, and although, yes, it has bitwise operations in it, nearly every line of it contains assumptions that it's running on a 32-bit computer (such as the 360) and about which CPU instructions set which CPU flags, with gems like "R0 := FLAGS(I) AND #80000000; IF ¬= THEN ...". It's pretty strong evidence that, in 1966, even Niklaus Wirth thought he had to write nonportable code — essentially assembly language with ALGOL syntax — in order to get acceptable performance.

He explicitly rejected FORTRAN, and he claims he didn't have an ALGOL-60 compiler available.

> And then Pascal was also written in Pascal after it was bootstrapped once.

I've certainly seen Pascal compilers written in Pascal, but the ones I've seen were concurrent with the development of C or later. I don't suppose you have one in mind?

๛

See also:

http://news.ycombinator.com/item?id=1624481

> It's pretty strong evidence that, in 1966, even Niklaus Wirth thought he had to write nonportable code — essentially assembly language with ALGOL syntax — in order to get acceptable performance.

I'd however say that that 1966 code is not at all so far away from C. Today I can also use registers in my big C compiler, heck, I have to for really serious optimization. Just like then. C is also not automatically portable unless active care is done to test it on another platforms and rewrite the parts of it -- if you claim the opposite I have for you some 2 million lines of code I maintain after at least 40 people worked on it -- it's not an exception, more a typical example.

Yeah, you're right, PL360 is pretty similar to C, but it failed to achieve what C achieved: providing just enough of an abstraction from the concrete machine to make efficient portable software possible, and in fact even practical.

As far as register optimization in modern C, I think there's a world of difference between saying "register long a, b, c, d, e;" and saying "WHILE W ¬= #1 DO BEGIN R1 := MEM(W); R0 := R1 SHRL 24 SHLL 12 + T; MEM(W) := R0; W := R1 and #FFFFFF; END". But maybe you were talking about inline assembly.

My experience with C portability agrees with yours, although it sounds like yours is deeper.