Hacker News new | past | comments | ask | show | jobs | submit login

I'm not mistaken, only you appear not to have experience with FORTRAN and Pascal.

> There was no such thing as a general-purpose program that was both portable across a variety of hardware and also efficient enough to compete with custom code written for just that hardware.

Of course ALGOL easily matches this claim. Proof: Knuth's TeX was written in Pascal.

Not to mention everything that was written in FORTRAN.

> I still occasionally run programs originally written in 1981 for a single-processor 16-bit PDP-11 with 64k of RAM per program, and they're still efficient

Try to check when most of the FORTRAN libraries still used today were written. Some -- decades before 1980.

See also how long FORTRAN compilers generated faster scientific code than C -- for decades after C appeared. You can also find why:

http://en.wikipedia.org/wiki/Pointer_aliasing

> "Why Pascal is Not My Favorite Programming Language"

The paper, as far as I remember, doesn't claim impossibility of writing useful software, mainly laments for the lack of return, break, continue constructs, which are convenient to have but not real show-stoppers. Note also that Pascal standard features are just to be a "learner's language" not a "system language" -- for which there were working compilers and uses before C.

> You couldn't run the Burroughs 5000 Master Control Program on a PDP-11, as far as I know, at all, and certainly not efficiently.

You'd also have to port Unix the same way you had to port MCP -- you can think of MCP as Unix in which drivers are part of the kernel -- but "integer" in ALGOL is certainly as portable as "int" in Unix -- they both fit the "hardware word."

Nicer pointer arithmetics in C is a good point. Though note that Wirth also had "Pascal lite" with pointers and which was closer to assembly for OS-level stuff just as Burroughs had ALGOL lite for OS-level stuff. The concepts of "closer to assembly" but higher-level languages existed certainly well before C. The idea to separate kernel and drivers is something else, and I don't know who achieved that first and when.

Finally, see Google's go -- it's more or less acceptance of Wirth's directions, mixed with terser notation of C. (Now, finally, why are you still on my lawn?)

> The C abstract model of computation is an increasingly poor fit to modern hardware

No, you can observe C (as well as more or less all ALGOL descendants) as a higher level representation acceptably close to assembly, so as long as there are CPU's which execute machine code and we need to care about details (see http://news.ycombinator.com/item?id=3068513) we'll need something like that to have efficient and not too low level representation.




(Note: I continued writing my original comment after you posted yours.)

I don't have much experience with Fortran and Pascal. But the original article also talks about how C was different from Fortran: "Fortran did okay for array-oriented number-crunching code, but nobody could do it for general-purpose code such as what you’d use to build just about anything down to, oh, say, an operating system."

And that covers most of the FORTRAN libraries still used today.

Both Fortran and Pascal came close — ADVENTURE may be one of Fortran's greatest triumphs — but they were not really usable by themselves. Software Tools was written in Ratfor (as I said, C's sibling) and TeX was written in WEB, rather than Pascal. (Writing a text-processing program in a strongly-typed language without a string type is an exercise in frustration.)

> you can think of MCP as Unix in which drivers are part of the kernel

I'm not sure what you're trying to say here. Drivers are part of the kernel in Unix too.

> but "integer" in ALGOL is certainly as portable as "int" in Unix -- they both fit the "hardware word."

But ALGOL-60 doesn't have bitwise operations, bit shifts, unsigned arithmetic, char, or more than one precision of floating-point. Instead you get ↑, exponentiation. So many algorithms that can be expressed efficiently in C cannot be expressed efficiently in ALGOL-60.

> Wirth also had "Pascal lite" with pointers

Where can I learn more? Googling [Pascal lite] is not helpful.

> The concepts of "closer to assembly" but higher-level languages existed certainly well before C.

Certainly true — BCPL could be described as one of them. But BCPL didn't quite get it right.

> Finally, see Google's go -- it's more or less acceptance of Wirth's directions

What does Golang have in common with Oberon (?) that it doesn't have with C?


> What does Golang have in common with Oberon (?) that it doesn't have with C?

http://en.wikipedia.org/wiki/Oberon_(programming_language)

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

> ALGOL-60 doesn't have bitwise operations

Ah.... That's like saying that Unix IV didn't have driver for your network card. It was just not standard only because CPU instruction sets were not standard enough. Real-life compilers had it:

http://rosettacode.org/wiki/Bitwise_operations#ALGOL_68

> more than one precision of floating-point

FORTRAN had it, C didn't care initially. And FORTRAN remained faster for long.

> Where can I learn more?

Actually, my bad, 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...

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


> 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.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: