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."
...this guy is fucking full of himself.
How exactly is it pronounced? Cause I can already see other language designers claiming "Our language is better than Cx!"
Ezekiel 23:20
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.
> Static code analysis and runtime checking (valgrind) pretty makes C's little issues a non-event now.
Just not true, even if you add in manual security audits as well. For example:
https://lwn.net/Articles/73545...
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.
I looked into Python for scientific/numeric programming, and from what I gather, key value paired lists are at its foundation and everything, including its object class model, is layered on top of that. Java, on the other hand, is based on an object class model from which you construct data structure objects such as key value paired hash lists?
What I like about Java is that it supports dense arrays of numeric values. Its dense-array model is an exception to "everything is a" hash list/object/thingy. It appeared to me that Python implements arrays on top of key value paired lists/hash lists/dictionaries/whatever-you-want-to-call-them. Maybe that works for sparse-array numeric linear algebra, but much numerical programming involves operations on dense numerical arrays where compilers optimize array access in loops to incrementing address registers. Even in Java, which does not allow disabling this safety feature, the compiler will analyze loops to optimize bounds checking.
Python has NumPy to support dense arrays of numeric values in this fashion, but NumPy, at least at the time 10 years ago I looked at it, was this wart on the Python language, in other words, something that sticks out and gives the appearance that it doesn't really belong there. It is straightforward to operate on NumPy arrays in native-code extension modules to Python, but on the Python side, such an array is this "blob" that you can only poke at with native-function calls.
Matlab is the "thing", the expensive, proprietary thing that persons with engineering domain knowledge who cannot be bothered to learn a "real" programming language use. It is for the people who used to use Fortran to perform engineering calculations with one of those Tektronix "vector storage" video displays 40 years ago and now they have Matlab, which combines a goofy scripting language with a GUI with a vast legacy Fortran and C numerical library with a graphical visualization library.
Forget about Matlab; I run Java as my "FORTRAN" in Eclipse and my Java programs output tab-separated columns of numeric data. Java does not have an "immediate mode eval-prompt" like the Matlab command windows, but the incremental syntax checking and compiling allows for much faster edit-build-execute cycles that what Visual Studio offers with C/C++. If my program crashes, I can quickly find the offending line in the Eclipse edit window -- good luck with that in C/C++. The Eclipse console window is a text-mode GUI allowing data exchange with other GUIs -- C++ in Visual Studio does not support such data exchange of numeric console-mode output. My "Tektronix vector storage display" is copy-and-paste to an Excel or Open Office Calc spreadsheet to plot the results.
In my ideal world, there would be 3 layers, scripting/incrementally compiled managed-code/native code. I would like something other than the serious-coin-per-seat sole-source Matlab as the scripting layer (it interfaces well with Java with transparent exchange of dense arrays, in fact, the Matlab GUI is written in Java), but I really like Java for that middle layer.
Could you accomplish what you ask for by coming out with a native-code version of Java? Maybe ditch the GC and replace it with best-practice non-GC memory management "smart pointers"?
Back when Sun Microsystems was the fiercely protective parent of Java, such a thing wouldn't be Java and they would sue your backside if you tried to call it Java.
But are not Rust, Go, and Swift essentially native-code versions of Java? If not rigorously adhering to Java, are they not attempts to ditch the preprocessor, provide a module system and namespaces, properly define behavior and improve safety, in a native-code setting?
They are native code, because if they are managed code, what is the point of not using Java, or if you want a different language, at least adapting it to the JVM (cough, C#, cough)?
(1) Undefined behavior. UB is completely unacceptable in 2017
You'll be sad to find out that your favorite language has undefined behavior as well, unless your favorite language is ML. It's just not worth the effort to fully define the language.
"First they came for the slanderers and i said nothing."
There are no flaws in C that cant be fixed by becoming a better programmer.
at least until machines take the job over.
Machines already have taken the job over, it' just that we call those machines "compilers", and they're really dumb so we have to explain to then what we'd like the software to do really, really precisely and clearly.
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.
That just means you could be better at c. Because there is nothing you can't write in c; c gives you absolute control of everything. The questions are:
o Do you have the time?
o Do you have the skill?
Most people aren't willing to say yes to the first, and most people can't honestly say yes to the second (and that's given us a lot of very bad c code. But it's not c that's the problem. It's the raft of so-so and worse programmers that have built things in it.)
I've fallen off your lawn, and I can't get up.
Yeah, but better languages eliminate whole classes of security bugs that plague C programs, including the bugs that hit dnsmasq.
This is one of the lamest defense of C: "You can't prevent all bugs, so why bother trying to prevent any".
The answer is here: https://bugs.chromium.org/p/ch...
BTW. Probably the most evil thing that C has inflicted upon the world is counting from 0. All pre C languages count from 1, as do children. And then it all changed. And we will live with off by one errors for the rest of time.
Can I just leave this here?. I feel like I need to leave this here for you to read.
Yaz
I don't consider myself to be a programmer by profession, although I have been in the past, with experience spanning quite a range of different language types, including COBOL (74 & 85), FORTRAN 77, BASIC, JAVA, PHP, Visual BASIC (up to 5.0), VBA and Assembler (several different CPUs).
... and, if there are, are they acceptable?
When I started to learn programming languages at high school, the number available was relatively small (compared with today) and the differences between them relatively significant. Each language was specifically designed to solve a reasonably well defined set of problems. If you were working mainly with mathematical problems such as with physics or engineering, you'd use FORTAN. If you were developing applications for business, you'd use COBOL.
Look again at the syntax and structure of these languages and their origins, architecture and design are clear.
I am very (very!) sorry to all those professionals currently working in the field of programming language design if what follows is offensive, but we seemed to have entered an age in which a "fantastic" or "revolutionary" new language is released every few months. The better ones then follow the Gartner Hype Cycle before drifting back into obscurity. The mediocre ones never seem to make it even close to widespread adoption...
We now seem to have reached a point where, instead of designing and developing a programming language to solve a specific business, scientific or technical problem, language designers are simply stealing primitives and ideas from existing languages and throwing them together into a framework before declaring their solution to be "The Next Big Thing (TM)". Of course this is a generalisation - every now and then we see some really remarkable innovation happening in the language space. JAVA for example, with it's aim of "write once, run anywhere" and it's much improved memory handling, would be a valid example.
But in my ignorance I can't help but look at the current state of programming languages and think that too much of what we see today is just different, not necessarily better. Perhaps the most egregious mistake I see us making, as an industry, is that we're losing sight of the fact that programming languages should be designed to be easy. Remember the relevant portion of ESR's own "Art of Unix Programming", the Rule of Representation, which says, "Fold knowledge into data, so program logic can be stupid and robust."
Do we see modern languages with the data handling sophistication of COBOL, for example? No. That's acceptable if the new language has a well-defined set of design goals that don't include data handling, but if not, I think we need to think very carefully about that old maxim, "all progress is change, but not all change is progress"...
So whilst I'm always interested in learning about developments in programming language design, I think it helps if we ask a few fundamental questions of a new language:-
1. What are the specific goals and design requirements of this language? How well does it meet them? Are there any compromises made in doing so
2. Of all existing programming languages that exist today, which one or ones are closes to this new offering in terms of goals and design requirements? Having identified the competition, what are the features and key differentiators of this new language that make the existing language obsolete? Are we certain (for example), that before embarking on an all-new language, that it is impossible to extend the legacy competition with new language primitives?
3. Given that all design decisions are in fact compromises by another name, what is/are the impact(s) of the design decisions taken that differentiate this new language from the competition? [If these yield benefits, then wonderful; if they bring costs, then are we willing to accept them?]
4. What is the learning curve like? Does the new language include weaknesses that yield to commo
A bit like dealing with Wipro, then?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Any developer worth his salt should be very, very wary of any tool or app that comes from google; they have a nasty habit of providing things that eventually disappear.
Circle the wagons and fire inward. Entropy increases without bounds.
C persists because its designers decided to invent a language to express how the world actually is, rather than how faddish humans would like that world to be (in particular, even LISP doesn't entirely pass this test, because—like it or lump it—real computers are state machines).
C is not perfectly fine, though it's perhaps the adequate and (mostly) comfortable marriage we've long had, warts and all.
ESR, I've slowly learned, is generally full of shit. Long ago I was fooled by his giant, noisy he's-one-of-us hat. But over time I came to perceive that he is primarily a noisy propagandist, who almost always wades into a debate to noisily send it down the river in the wrong initial direction.
Here he builds his entire case around the dangerous word "replacement", invoking the metaphorical reasoning processes associated with small, painstakingly divisible pies. What he is simultaneously hiding behind his back is the glove metaphor: that every language has a natural application domain where it excels for some people, at least some of the time (or it will soon wither and die).
What's he's trying to argue is that some other languages now exist that don't instantly disqualify themselves (due to stupid, faddish design decisions) from potentially becoming the next hegemonic ecosystem for all things systems programming-ish (C would remain the size of India for decades to come, even if China ultimately asserts itself as the new, "uncontested" superpower).
[*] Hegemonic thinking and the human predilection for fads are fused together at the hip bone.
He also means that within the next five to ten years, C might develop and increasingly strong legacy body odor (as if your grandfather's shaving cream didn't already have such a smell).
The legacy smell of C is that of a hearty pioneer, after many decades of a life well lived, who ain't dead yet, not by a long shot.
Stewart Brand: Good Old Stuff Sucks (2008)
Brand is a kinder, gentler, less rhetorically clueless ESR, and here he gives us a third metaphor: C as wood. Many an aspiring bullshitter has announced to the world this or that "wood replacement". For a long time, most of those wood "replacements" sucked. That was Brand's middle phase.
Now for many purposes (e.g. window frames, etc. etc. etc.) we have wood replacements that don't suck.
Roll the presses! Wood considered passe.
The thing is, humanity has never really needed a wood replacement. Wood is pretty good at many things. We've been using wood for a long time. I mean—crikey!—Jesus once listed carpentry on his brief CV. But that doesn't mean we shouldn't continue to pursue other materials or not find other great ways to build stuff.
It does mean, however, that wood considered passe is typical ESR weak sauce.
I'd argue that the Nim language is another modern alternative to C.