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 is totally wrong. The runtime and compiler models for Rust are pretty much exactly the same as for C. People are running Rust code on 8-bit microcontrollers: https://github.com/avr-rust/ar.... You can write kernels and device drivers in Rust and people are.
This is all less true about Go because it needs a garbage collector.
They're only equivalent in 12-tone equal temperament, or on a keyboard instrument that only has 12 notes per octave (equally spaced or not). Western music also maps unambiguously (though not always pleasantly) onto 19- and 31-tone equal temperament, where a double sharp is most definitely not the same as the next whole tone up because a "whole tone" might be 5 minimum increments (this is the case in 31-ET, the better-sounding of the two in most cases), and a semitone just two. This would leave Cx a full 1/31 of an octave flatter than D natural. (And this is why we even have double sharps and double flats, to keep the theory clean because we haven't always mapped everything onto 12-ET and may not always do so in the future.)
How is the Riemann zeta function like Trump rallies? Both have an endless number of trivial zeros.
Python makes programmers more efficient than any other language. It will win out eventually, once people get over their irrational fear of whitespace.
It hurts me that most programmers will go through their entire career without being able to learn or write microcode.
Obviously, that gets you much closer to what the CPU actually does, and all of the details of its various units, the instruction pipeline and its stages and timing, and the I/O pipeline and its timing.
Writing bit-slice microcode for the old Pixar image computer, I once a whole day to get the last tick out of a loop. All of the code fit on the termial screen, but there was a lot of parallel timing going on. I did that for one relatively general loop, and someone else at Pixar wrote an entire compositing system out of versions of that loop.
Bruce Perens.
I think it was P.J. Plauger who pointed out that all programs are real-time. A system which computes the monthly payroll is useless if it takes three months to run.
More to the point, though, "speed" in this case is a proxy for other kinds of efficiency. A program which uses the system resources more efficiently requires less battery, less hardware, less air conditioning, and so on.
Just a thought: What do you suppose the worldwide carbon footprint of DRM is?
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
There are no flaws in C that cant be fixed by becoming a better programmer.
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
Same can be said for PHP and webcoders who keep writing their own SQL code and input sanitizers from scratch. They can make money, so it's not a critical problem for them. Just for society as a whole.
As Marcus Ranum once said : "Not only do we still have buffer overflows, I think it's safe to say there has not been a single category of vulnerabilities definitively eradicated."
Thanks to people like you.
Linus isn't irrationally afraid of C++, he's rationally afraid of the state of C++ 20 years ago. I completely agree with him that C++ was a terrible language 20 years ago. He just hasn't bothered to reevaluate his opinions based on more recent versions of both the standards and compiler ABI stability.
Oh, and you missed the horrible non-typesafe macros (look at the list and queue macros, for example), that provide a crappy version of C++ templates, with all of the disadvantages and a few of the advantages.
I am TheRaven on Soylent News
If you are continuing to have trouble with the language, then I would submit that you are probably not a very good programmer, and the behavior of the language (which requires you to have a good grasp on how computers actually work), is probably mysterious to you, but each and every behavior of C++ is there for a very good reason.
Seriously, this level of fanboi-ism gets modded up? To shoot fish in a barrel the zero-terminated C strings was made to save one length-prefix byte and has cost the world a bazillion times more than the Y2K problem and every non-C programming language has abandoned it. But okay, that's an inherited problem. My biggest gripe with C++ is that it's an OOP language without an object oriented memory model, unless you religiously follow RAII as a pattern or trace every execution path when the code changes you will have crazy leaks all over as you create and destroy objects. Why? Because it was originally just a razor thin convenience layer on top of C and for a long time there was no smart pointers or they were in the Boost library and not part of the language itself.
Part of this is that it's not explicit when any library is processing its own data that it'll clean up and when it's returning a new object to me that it expects I'll clean up. Read the documentation, I suppose but an explicit passing of ownership not just reference would be so much better. My second biggest gripe is that there's no safer and easier object oriented communication protocol than using pointers everywhere, which very easily leads to a dangling reference somewhere and leads to much tighter class integration than a publisher/subscriber system. I've written C++ but mainly using the Qt library which is much, much closer to what my ideal OOP language would be like because one mismatched signal-slot doesn't bring the house down, even though the macros and the meta-object compiler (MOC) seemed like a hack around C++'s limitations.
I have the feeling C++ is in no man's land. New mid-level code is written in C#/Java/Swift, high level in Javascript/Perl/Python/PHP/R and so on, low level code in C/assembler. There are a lot of huge, existing C++ code bases so it's not like you'd run out of work but I don't really see who'd start a new project from scratch in C++ today. Particularly since there's no major platform pushing it, on Windows it's C#, on Mac/iOS it's Swift and in the enterprise and on Android it's Java, the embedded market is C and the web is pushing Javascript everywhere: But who's pushing for more C++? Almost nobody, as far as I can see. It's just a complex mix of low-level and high-level concepts thrown in a blender which in theory lets you do many things but in practice is unwieldy for almost anyone.
I suppose you could call that an expert's tool. But sometimes I feel it's like crossing a canyon on a tightrope. The C/assembler guy brought rock climbing gear, he's got a long and tedious climb up and down ahead of him but he's chiseling out steps and building a series of bolts to climb by. The mid/high end guy starts looking for a bridge. What the C++ guy does is difficult and impressive, yet not very productive for anyone else and the next guy also needs to be an expert tightrope walker. You say it's a language for experts, who can afford an expert for every change? How do you become an expert, if a junior C++ developer will fail spectacularly? What I'm saying is that just because it's challenging doesn't mean you're an expert, it just means you're doing it the hard way.
Live today, because you never know what tomorrow brings
insane preprocessor, no module system or namespaces, all kinds of obscure undefined behaviors, no way to express important safety properties like "pointer is never null", weak type system that can't express tagged unions or tell the difference between data and code pointers (https://lkml.org/lkml/2017/9/25/708), broken type syntax where it's impossible for humans to write complex types, security-bug-prone standard library APIs like sprintf and strcpy, standard library missing basic stuff like hash tables, inability to expose basic library features like ref-counted pointers and growable arrays ergonomically, ...
No offence but I can tell you are not a C programmer.
The great thing about C is that you can fully understand every aspect of it. It's not like C++ where it's overly complex to the point that few people know all its features and behaviours. In C with a few years of experience and study you can know everything there is to know.
There are no obscure undefined behaviours, only well documented ones. You can easily express that pointers should not be null through asserts and common extensions (e.g. GNU's __attribute("no-null")). C supports unions, and it's weak type system is what makes it great for low level development - you just have to get into the mindset of data being bits and bytes, not some abstract and opaque box.
The standard libraries are a bit crap, I'll give you that. There are things like Boost if you want more, but the lack of things like hash tables in the base language is because those things would make it hard to port and run on low resource systems.
I think you using the wrong tool for the job. C isn't designed to do those things you talk about, because they come with overhead and C is a system programming language. Any "replacement" for C is going to have to work in environments with memory measured in bytes. It's going to have to support stuff like full static allocation. What you want is something more like C# or Java.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
As a python developer, I'm totally there with you. I also see how it happens.
Currently all my projects I mandate to be compatible with python 2.6, 2.7 and 3.6 because I have a significant userbase still doing supported, but old enterise distros and I want them to be comfortable with the fact that it's mostly running from the OS provided runtime. *repeatedly* a developer comes along and say "why should we support old language runtimes? just make the users deal" Of course then I point to the large number of CVEs we'd suddenly be resposible for, in addition to how broken some of their suggestions would leave the customers python environments on top of how non-python developers view shenanigans like requiring your own python when a seemingly usable one is right there on the filesystem.
Then we get to pypi. We incur a lot of testing if a package *must* use PyPI content, and then package it as rpm and/or .deb if and only if distribution does not have it, and test with and without popular third party repoes (like epel, centosplus, etc. )Developers want to pull in a big pypi package over the most trivial of things. Suddenly we find a package in EPEL that isn't the same as the one in Ubunutu repoes and they have different API (because python developers tend to not give a crap about stable APIs either). So our code adapts to use the different API generations that may come about due to those sorts of differences.
Python is more accessible so you get more developers willing to work on it. The problem is that that large base of developers is not anywhere near as disciplined or caring about their userbase as would be ideal.
XML is like violence. If it doesn't solve the problem, use more.
While I have not made mistakes with pointers (so far), I will say that it is tedious to constantly be passing around the max size parameter to every little function because that's the only way for a C function to safely deal with pointer data.
Of course on the other hand, when I have reason to use C, it is refreshing and keeps me more aware of the limitations of the machine at all times. The coddling of other languages makes me forget and do slow algorithms out of laziness.
XML is like violence. If it doesn't solve the problem, use more.
I can report that in a Go project in which a raft of objects had to be moved out of the heap - because the Go garbage collector was constantly looking at them (this was a multi-million element tree) to see if they need to be dumped, some significant performance gains were achieved by getting 'round the GC. The final code eded up with nothing but the root of the tree in the heap, and the rest... not. GC time wasted was culled, overall it was a definite win. The code's in production and running well.
Also - this was in June/2017. It was Go 1.8.
I've fallen off your lawn, and I can't get up.
Anyone with a gate-array development board can design a CPU these days, and there are Open Source designs with Open Microcode. Here is the microcode source for RISC-V.
Bruce Perens.