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."
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.
Agree. C++ is the future. Anything else is for outsourced chimps.
> 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.
Python makes programs less efficient than any other language. It will win out eventually, once people get over their irrational fear of having their code not run slow as shit.
Fixed that for you.
Technically, everyone is full of himself.
Ezekiel 23:20
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.
Look at Julia. It is similar to Go, Rust, Swift and the like in that it uses LLVM for generating the final machine code. It can be quite efficient. The language is designed for similar uses as Matlab - except it does not suck. I prefer Julia to Matlab for everything other then debugging - the Matlab debugger is great compared to what is available for Julia.
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.
I write in C for embedded systems. Matlab generated C code is too bloated and inefficient. Especially for a DSP. I've been down that Matlab path with high hopes and it didn't work well. It's still a good idea to test the algorithm in Matlab.
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 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 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.
No one writes C for embedded control systems, we let Simulink and Matlab handle that.
I work on embedded systems. I have been involved in dozens of projects. I have never, not once, seen Simulink or Matlab used in a final product.
The answer is here: https://bugs.chromium.org/p/ch...
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 lot less than Bitcoin's.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
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
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.
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.
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;
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.
Just put everything in one massive struct of doom, then you only have to pass a single pointer everywhere.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
The big change is that there is now, for all *NIX platforms, a stable C++ ABI. The HP Itanium ABI was adopted largely as-is by all *NIX systems (with the slight exception of 32-bit ARM, which does exceptions slightly differently and handles pointers to members differently because the low bit in instruction pointers is already in use for thumb interworking). Variations between archs don't matter too much, but changes within an architecture are problematic because they mean that you can't define long-term-stable interfaces in terms of C++. On Windows, for example, all public interfaces are either C or COM because the MS compiler changes ABI across Visual Studio versions. Apple was bitten by this, because they defined kernel (IOKit) interface in terms of the gcc 2.95 ABI and had a lot of pain to move everything to the Itanium ABI (largely motivated by the fact that clang never supported the old ABI).
On a related note, compilers are a lot better at optimising C++ now than they were 20 years ago. All of the companies that employ a lot of LLVM or GCC developers now have huge internal C++ codebases and care more about the performance of these than of their C code. This is a huge shift from 20 years ago, where C++ was a checklist feature for gcc (clang didn't exist) and no one really cared about C++ performance. 20 years ago, renaming a .c file to .cc and compiling it with gcc would often give you slower code. Now, it will give you exactly the same code and performance doesn't get worse as you use more C++ features. For example, both templates and lambdas rely on the inliner a lot and modern C/C++ compilers have tuned their inliners on this use case more than on common C idioms.
In terms of language features, there are a few big ones. The first is lambdas. These can be used in a lot of places where you'd use macros and generate the same code, but be a lot more readable. The other large feature is the addition of move semantics. This is very important for kernel-style code, where you want to have fine control over memory ownership. Things like the standard library unique_ptr template give you a trivial way of expressing unique ownership in the code, in a way that can be transferred between threads, and compiles down to no code but statically checks that you've followed the correct discipline.
There are a few other things that are pretty useful. Generalised constexpr means that you can write functions that should be evaluable at compile time and you can use a trivial template wrapper to force compile-time evaluation. This is very useful in code where you need to reason about run-time complexity, because you can guarantee that the compiler really will evaluate something at compile time or fail to compile.
For the kernel, the improvements to enums in C++11 can also be useful. You can define enums that are actually type safe (i.e. they're not just the equivalent of #defines of int values and assigning the wrong enum is actually an error) and which have a storage type other than int.
The Linux kernel has a really crappy way of handling memory orderings, which basically rely on having macros that map to the different memory barriers on Alpha and having programmers insert them in the right places, so it's not as well suited as something like FreeBSD to adopting C++11 atomics (FreeBSD provides functions that have almost identical semantics to the C++11 acquire-release model), but adopting it exposes a lot more opportunities for compiler optimisations. The current atomics are all implemented as asm volatile statements, which provide a full compiler barrier (the compiler may not move instructions from one side to the other, even if it would be safe to in the memory model). C11 also has support for this, but it's a really ugly copy and paste of the C++11 stuff to C11 and the standard ends up writing volatile in a bunch of places where it means _Atomic, so using them is painful.
Range-based for loops don't give you anything other
I am TheRaven on Soylent News