This video is what I use when countering the myths about how C was designed. It goes to the papers and constraints that led Richards’ team to chop ALOL into BCPL. Then, the modifications from BCPL to B to C. Understanding the context of why C was the way it was might help folks understand why we should upgrade given we’re no longer in those constraints either in hardware or programming features.
I think there is a reasonable argument that C won on its merits. The following is a list of some languages that were available in 1975 and my opinion of why they lost out to C. C is pretty much the only language on this list with a portable implementation that ran on minicomputers.
Algol 60 - call by name is expensive, not really intended for system software
Algol 68 - complex to implement, standard uses an obscure formal semantics, requires a runtime, compilers did not emerge for years
Algol W - first implementation was for IBM mainframes in an infix assembly language, few other implementations
BCPL - untyped, inferior to C in some ways, limited support for byte addressing
BLISS - semantics for assignment are unusual, untyped, no portable compiler, only for DEC architectures
Coral66 - British military standard, may not have had recursion
Fortran 66 - not really suited to system software, although a number of vendors wrote operating systems in an extended Fortran
Forth - different programming model, mostly interpreted
IMP72 - implemented mostly on supercomputers, low level of abstraction (Fortran II), complex (extensible) grammar
Jovial73 - DoD standard, no standard IO
LRLtran - no implementations for minicomputers
MAD - low level of abstraction, implementations ran on mainframes
NELIAC - low level of abstraction
Pascal - weak standard, no separate compilation, Wirth moved on to new languages
PL.8 - internal to IBM, compiler ran on mainframes
PL/I - complicated to implement, early implementations were slow
PL/S - internal to IBM, compiler ran on mainframes
RTL/2 - British language for realtime systems, probably unknown in the US.
Great list. Remember that there’s two parts to this: one is how they designed it; one is what happened later. Your list seems to be what happened later after comparing its design to everything else unmodified. Whereas, mine says they’d have cherry-picked the best of anything on that list modifying it for their situation. In each case, they’d pick whatever was safest or cleanest by default switching to unsafe only where necessary. As hardware improved, the safety and maintainability would improve.
That’s the approach Wirth took with Modula-2 and the rest of his languages. Most others did as well doing languages for safety or programming in the large. It’s now the standard way to do things with many citing an escape from the safety and maintainability problems of C. So, the evidence leans toward Wirth’s choice.
If I wanted to both re-write indent(1) in not-C and continue to distribute it as a part of FreeBSD, NetBSD, OpenBSD - which programming language should I “upgrade” to? What choice do I have?
I’d really appreciate your opinion, since you cited Myrddin, which is my favourite contender for the package system of Jehanne.
I do not really know any of the two (I used Pascal years ago.. but Oberon seem better).
But of all the C alternatives I could decide to integrate in Jehanne (the way Perl was integrated in Unix) these seem the best two candidates for their balance between simplicity and practicality.
Wirth’s Oberon win on simplicity, but Obi’s Myrddin win on practicality (according to my shallow understanding so far… take this with a grain of salt!)
Hi Orib! Yes, you are right! Myrddin is the most practical choice for Jehanne.
Also it provides language features I like, such as ADT and pattern matching, and it already has a practical standard library.
But honestly I haven’t had the time to try your hints: I saved them from my irc log, but… really I didn’t had the time… :-(
Nevertheless I’m also rather fashinated by Oberon-07: Wirth keeps cleaning it, removing redundant features. I know this add pressure to the library and applicative code, but…
I think you can see the affinity with my strive for simplicity in Jehanne.
All of those fall over on portability. Rust is amd64 and i386 only, myrddin is amd64 only, and building the zig compiler requires llvm. nim has the best story with amd64, i386, ppc and arm, which still isn’t enough.
I think you are wrong about rust, there have been plenty of posts of embedded arm and other processors targetted by rust. LLVM has lots of targets and can compile itself, so it is relatively portable, though extremely complex.
Is rust on other architectures done natively or by cross-compiling? I don’t know about the others but OpenBSD requires that the base install can build itself on every architecture.
He is right, the only platforms at the moment able to self-build rust are amd64 & i386. OpenBSD requires much more. You participated in a previous thread so you know that rust in the base system is not likely to happen. Hence rust is not the answer to:
If I wanted to both re-write indent(1) in not-C and continue to distribute it as a part of FreeBSD, NetBSD, OpenBSD - which programming language should I “upgrade” to? What choice do I have?
With the current status quo, the only language fitting the above question I believe is Perl.
The answer is C++. Every architecture that OpenBSD currently supports has a C++ compiler in base (well actually compXX.tgz). I’d imagine the answer is similar for FreeBSD and NetBSD. You may be able to get away with C++11 on the popular architectures but I think the less popular ones you’re stuck with C++03 or even C++98.
The general choice is anything that compiles to C. If they’re picky about coding standards, what you would have then is a cultural argument instead of one on language capabilities. They wouldn’t allow something better. Then, you might be forced to do what folks like Per Brinch Hansen did back when hardware couldn’t run ALGOL: write in one language you can’t share for its benefits with a second version done against that in language you can share. To automate that, I recommended a while back someone make a safe, clean, superset language that’s compatible with C plus exports to readable code in that language. Throw in real macros and REPL for an extra reason to use it.
Then, we don’t have a CVSup-style situation where author uses a safe, maintainable, high-level language for its benefits but people eventually rewrite that stuff in C anyway.
This video is what I use when countering the myths about how C was designed. It goes to the papers and constraints that led Richards’ team to chop ALOL into BCPL. Then, the modifications from BCPL to B to C. Understanding the context of why C was the way it was might help folks understand why we should upgrade given we’re no longer in those constraints either in hardware or programming features.
I think there is a reasonable argument that C won on its merits. The following is a list of some languages that were available in 1975 and my opinion of why they lost out to C. C is pretty much the only language on this list with a portable implementation that ran on minicomputers.
Algol 60 - call by name is expensive, not really intended for system software
Algol 68 - complex to implement, standard uses an obscure formal semantics, requires a runtime, compilers did not emerge for years
Algol W - first implementation was for IBM mainframes in an infix assembly language, few other implementations
BCPL - untyped, inferior to C in some ways, limited support for byte addressing
BLISS - semantics for assignment are unusual, untyped, no portable compiler, only for DEC architectures
Coral66 - British military standard, may not have had recursion
Fortran 66 - not really suited to system software, although a number of vendors wrote operating systems in an extended Fortran
Forth - different programming model, mostly interpreted
IMP72 - implemented mostly on supercomputers, low level of abstraction (Fortran II), complex (extensible) grammar
Jovial73 - DoD standard, no standard IO
LRLtran - no implementations for minicomputers
MAD - low level of abstraction, implementations ran on mainframes
NELIAC - low level of abstraction
Pascal - weak standard, no separate compilation, Wirth moved on to new languages
PL.8 - internal to IBM, compiler ran on mainframes
PL/I - complicated to implement, early implementations were slow
PL/S - internal to IBM, compiler ran on mainframes
RTL/2 - British language for realtime systems, probably unknown in the US.
Simula 67 - uses garbage collection, inventors wanted license fees
Great list. Remember that there’s two parts to this: one is how they designed it; one is what happened later. Your list seems to be what happened later after comparing its design to everything else unmodified. Whereas, mine says they’d have cherry-picked the best of anything on that list modifying it for their situation. In each case, they’d pick whatever was safest or cleanest by default switching to unsafe only where necessary. As hardware improved, the safety and maintainability would improve.
That’s the approach Wirth took with Modula-2 and the rest of his languages. Most others did as well doing languages for safety or programming in the large. It’s now the standard way to do things with many citing an escape from the safety and maintainability problems of C. So, the evidence leans toward Wirth’s choice.
If I wanted to both re-write indent(1) in not-C and continue to distribute it as a part of FreeBSD, NetBSD, OpenBSD - which programming language should I “upgrade” to? What choice do I have?
My top choices for contenders would be rust, zig, myrddin and nim. zig being the closest to C with many fixes.
One issue with rust currently is that building the compiler will dominate compile times until most of the distribution is ported to rust.
What about Wirth’s new Oberon-07?
Recently it has got a new promising little compiler to C, OBNC.
Hadn’t seen that, will check it out.
I’d really appreciate your opinion, since you cited Myrddin, which is my favourite contender for the package system of Jehanne.
I do not really know any of the two (I used Pascal years ago.. but Oberon seem better).
But of all the C alternatives I could decide to integrate in Jehanne (the way Perl was integrated in Unix) these seem the best two candidates for their balance between simplicity and practicality.
Wirth’s Oberon win on simplicity, but Obi’s Myrddin win on practicality (according to my shallow understanding so far… take this with a grain of salt!)
FWIW, Myrddin is probably going to be the easiest to port to Jehanne, since it already runs on Plan 9, and has a very small system abstraction layer.
Hi Orib! Yes, you are right! Myrddin is the most practical choice for Jehanne.
Also it provides language features I like, such as ADT and pattern matching, and it already has a practical standard library.
But honestly I haven’t had the time to try your hints: I saved them from my irc log, but… really I didn’t had the time… :-(
Nevertheless I’m also rather fashinated by Oberon-07: Wirth keeps cleaning it, removing redundant features. I know this add pressure to the library and applicative code, but…
I think you can see the affinity with my strive for simplicity in Jehanne.
All of those fall over on portability. Rust is amd64 and i386 only, myrddin is amd64 only, and building the zig compiler requires llvm. nim has the best story with amd64, i386, ppc and arm, which still isn’t enough.
I think you are wrong about rust, there have been plenty of posts of embedded arm and other processors targetted by rust. LLVM has lots of targets and can compile itself, so it is relatively portable, though extremely complex.
Is rust on other architectures done natively or by cross-compiling? I don’t know about the others but OpenBSD requires that the base install can build itself on every architecture.
https://forge.rust-lang.org/platform-support.html - it seems like rustc can run on at least 5-6 architectures. and the groundwork is there for more.
Zig itself has two stdlibs, one is based on libc so I bet that it could run on more platforms.
He is right, the only platforms at the moment able to self-build rust are amd64 & i386. OpenBSD requires much more. You participated in a previous thread so you know that rust in the base system is not likely to happen. Hence rust is not the answer to:
With the current status quo, the only language fitting the above question I believe is Perl.
https://github.com/Microsoft/checkedc seems to be one of the more practical approaches to upgrading C, though obviously not ready.
Maybe Vala. It compiles to C but has dependency on GObject.
The answer is C++. Every architecture that OpenBSD currently supports has a C++ compiler in base (well actually compXX.tgz). I’d imagine the answer is similar for FreeBSD and NetBSD. You may be able to get away with C++11 on the popular architectures but I think the less popular ones you’re stuck with C++03 or even C++98.
The general choice is anything that compiles to C. If they’re picky about coding standards, what you would have then is a cultural argument instead of one on language capabilities. They wouldn’t allow something better. Then, you might be forced to do what folks like Per Brinch Hansen did back when hardware couldn’t run ALGOL: write in one language you can’t share for its benefits with a second version done against that in language you can share. To automate that, I recommended a while back someone make a safe, clean, superset language that’s compatible with C plus exports to readable code in that language. Throw in real macros and REPL for an extra reason to use it.
Then, we don’t have a CVSup-style situation where author uses a safe, maintainable, high-level language for its benefits but people eventually rewrite that stuff in C anyway.