ESR Sees Three Viable Alternatives To C (ibiblio.org) 595
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."
Jesus Christ... (Score:2, Insightful)
Re: (Score:3, Funny)
Agree. C++ is the future. Anything else is for outsourced chimps.
Re: Jesus Christ... (Score:2, Interesting)
Python makes programmers more efficient than any other language. It will win out eventually, once people get over their irrational fear of whitespace.
Re: Jesus Christ... (Score:4, Funny)
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.
Re: (Score:2)
Speed matters in a lot more applications than you can imagine.
If you would do something where speed don't matter then you'd do your calculation by hand instead of buying a computer.
Re: Jesus Christ... (Score:4, Interesting)
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?
Re: Jesus Christ... (Score:5, Insightful)
A lot less than Bitcoin's.
Re: (Score:3)
You're going to set the gold nutters off, you do realise that?
Re: (Score:3, Insightful)
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 pro
Re: (Score:3)
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.
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.
What you say is true, however, you are missing the big picture. Reddit didn't start out with millions of users. It started out with maybe a dozen, with no promise that it'll ever grow beyond that. If they wrote the entire thing in C and took 2 more years to launch, maybe it would've never gotten big. Maybe it would've never launched at all. The creators couldn't support themselves indefinitely, and their investors might not have the patience for it.
Another problem is, anything written in C is harder to c
Re: (Score:2)
Python makes programmers more efficient than any other language. It will win out eventually
Let me know when you can run Python on an embedded AVR with 256 bytes of RAM. When you get down to bare metal, it is either C or assembly.
Re: Jesus Christ... (Score:4, Informative)
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.
Re: (Score:3)
so does a good carpenter when it's truly a shitty tool and there's no workaround.
Re: Jesus Christ... (Score:5, Informative)
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.
Re: (Score:3)
Want to guess what portion of work needing to be done is 'small tasks'? We've automated and hidden away thousands of small tasks.
Not everyone needs to write a kernel.
Re: Jesus Christ... (Score:4, Funny)
Just put everything in one massive struct of doom, then you only have to pass a single pointer everywhere.
Re: Jesus Christ... (Score:4, Insightful)
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.
Re: (Score:2)
Normally ACs are off in the weeds but this is the most insightful post here.
Re: (Score:3)
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.
Re: (Score:3)
A bit like dealing with Wipro, then?
Re: (Score:2)
Python is to programming today what Basic was to programming in the 80's.
They share a lot of similarities.
Re: Jesus Christ... (Score:5, Insightful)
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.
Re: (Score:3)
I was thinking about the little pervasive choices adding up in aggregate. In python development, dict is so frequently the first choice of any data structure because it's generally very flexible and requires little thought. In C a struct is about as easy as using a dict in python, but massively better, and it can add up for good or for ill very quickly. It's not as flexible, but the majority of the time I see dict, the members are actually well defined and the flexibility is not really needed.
Just wanted
Re: Jesus Christ... (Score:5, Interesting)
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.
Re:Jesus Christ... (Score:5, Insightful)
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.
Re:Jesus Christ... (Score:5, Insightful)
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.
Re:Jesus Christ... (Score:5, Interesting)
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.
Re:Jesus Christ... (Score:5, Interesting)
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.
Re:Jesus Christ... (Score:5, Informative)
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
Re:Jesus Christ... (Score:5, Funny)
Re: (Score:3)
"Cx"? Uh... (Score:4, Funny)
Re: (Score:2)
It's pronounced "goat-see"
Re: (Score:2)
It looks more like it should be pronounced Cux (cucks).
Re: (Score:2)
How exactly is it pronounced? Cause I can already see other language designers claiming "Our language is better than Cx!"
If it's making the reference I think it is, it would be "C double sharp [thoughtco.com]".
Re:"Cx"? Uh... (Score:5, Funny)
Re:"Cx"? Uh... (Score:5, Interesting)
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.)
Let's re-invent hammers and nails (Score:4, Insightful)
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.
Re: (Score:2)
We have "modern hammers", and they are used quite a lot in construction. Ever heard of a nail gun [wikipedia.org]? Sure, they haven't totally rendered hammers obsolete (for one thing, they suck at removing nails) but neither will Cx completely replace C.
Re: (Score:2)
You're still not going to use a nail gun if you don't have the nails. C is the nails.
Comment removed (Score:5, Insightful)
Re: (Score:2)
Simulink has been dominating embedded for some time now. It just generates C and you can continue to use your tool chains.
Re: (Score:2)
Because "embedded" as in nearly invisible computers with small OSes or even barebones runtimes are still pretty much C's domain. The first compiler most of this systems get is a C compiler, usually gcc.
Re: (Score:3)
Because "embedded"
Embedded as in the chips in vehicles: trains, planes and automobiles.
The Freescale PPC e200 chips and the Renesas RH850 line.
usually gcc.
Not a single chip I've worked on has had a GCC compiler.
It's either WindRiver's Diab [wikipedia.org] or Greenhills [wikipedia.org]. Former used on the mars rover.
Re: (Score:3)
How does Simulink perform when you have to write a USB device driver ?
Re: (Score:3)
"C is perfectly fine for most of what it is used for"
Except for anything with complex I/O for which security is relevant. Complex I/O such as a network interface or an USB port for instance, although frequently even text input has proven been too complex to implement securely in C.
Re: (Score:3)
What are the use cases for a type safe version of C anyway?
On the embedded side you can't live without being able to do type punning and other unsafe but extremely common techniques.
On the desktop side people have realized that big C apps are very hard to secure (hi Adobe) and maintain and moved on to other languages like C# or just gone full node.js.
In the middle you have things like operating systems, drivers, stacks etc. I guess they might benefit a little from being type safe, but do we actually have a
Re:Let's re-invent hammers and nails (Score:5, Insightful)
C, Ethernet, and RS232/485 will be with us long after humanity has gone extinct. Possibly after the heat death of this universe.
There should be a name for technologies that achieve that level of entrenchment.
wood considered passe (Score:3)
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 adequ
Not gonna happen (Score:5, Insightful)
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.
Re: (Score:2)
Because if you don't need C/C++ then you're scripting
Yes, APL and the like totally qualify... But then again, APL and the like would profit from better architectures than what C runs on, so maybe you're right.
Re:Not gonna happen (Score:5, Interesting)
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... [github.com]. 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.
Re: (Score:2)
Re:Not gonna happen (Score:5, Informative)
C has critical flaws everywhere: 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, ...
I could go on and on.
Native-code Java? (Score:3)
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,
Re: (Score:3)
But are not Rust, Go, and Swift essentially native-code versions of Java?
I can only speak for Rust in that the answer is no. If anything Rust resembles Haskell a lot more in form, function, and operation than 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?
Rust does but that hardly equates it anywhere near Java. If anything its just any language that wants to avoid those things. It would be like calling a nutritionist a doctor on the merits that they want you to live a healthy life.
such a thing wouldn't be Java and they would sue your backside if you tried to call it Java.
There were indeed compilers for Java to native code back in Sun days. But you are right that you couldn't call it Java, but that had a lo
Re: (Score:3)
Re: (Score:2)
Read up on the AS/400 architecture and you'll find IBM has eliminated most of those problems.
Re:Not gonna happen (Score:5, Insightful)
For what C is used for, none of those are even approaching "critical". A lot of criticism leveled at C and C++ these days tends to come from high-level devs who simply don't have enough context for what someone could want in an improved C. As someone who clearly has a better understanding, you could do better to rise above hyperbole.
At this point with C, there are very few things everyone can get behind as an improvement. A lot of people like it for its small non-magic surface area, and something like e.g. tagged unions would even be too much syntax sugar. I think if people wanted a broadly more powerful language they'd move right to C++, but they don't -- so we need to look at why that is, and maybe we'll have a better idea of what a "new C" could possibly look like.
A new c... (Score:5, Insightful)
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.
Re:A new c... (Score:5, Interesting)
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.
Re:Not gonna happen (Score:4, Interesting)
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.
Re: (Score:2, Informative)
Re:Not gonna happen (Score:5, Informative)
I will grant you, C++ has a steeper learning curve than most languages, but the performance of the code you can write in C++ is vastly superior to all languages except maybe C. There are constructs I can create with template metaprogramming that even C cannot match the performance of. Proper use of the STL allows you to minimize the need for memory management, but like any C derivative, the option of going all pointer-fu is there if you need it.
In all, C is a language for professionals, C++ is a language for experts. Everything else is for amateurs.
I'm guessing that you are only referring to higher level languages by this comment. But just for the the record, Assembler gives you better performance than C and C++.
Re:Not gonna happen (Score:5, Interesting)
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.
Re:Not gonna happen (Score:4, Interesting)
Re: (Score:3)
But just for the the record, Assembler gives you better performance than C and C++.
Eeehh... kinda. A skilled assembler programmer can usually out-optimize the compiler over smaller sections of code and simplistic, but on larger projects or complex CPUs the compiler usually wins. For example, most modern CPUs are superscalar, pipelined, do out-of-order execution and have large caches. It's pretty difficult for a human to optimize code for those things better than a good compiler can.
On microcontrollers it's a different story of course.
Re: (Score:3)
No, it's just that optimizing assembler requires a detailed understanding of the operation of the CPU. Back in the day we had tables of instructions with execution times, memory access requirements and the like. As machines developed it got harder, you had to consider DMA memory cycles for other hardware, then caching, burst accesses, pipelining etc.
Once you get to large, multi level data and instruction caches, plus out of order superscalar execution, and a large variety of them, it becomes very hard for a
Re:Not gonna happen (Score:5, Insightful)
I would say that before C++11, all C++ code could be compiled into the equivalent C code without loss of performance .. which is also how the very first C++ compilers worked.
In C++11 came move-semantics and better synchronisation primitives that C did not have. In C, you may be able to use intrinsics for synchronisation and atomic access though but move-semantics even for simple value types can improve low-level performance.
While I am also primarily a C++ programmer, I do mostly agree with the AC.
Most of the so called "idioms" in C++ are what would be called "hacks" in any other programming language.
C is more readable than C++. In C++, you often have to spend more mental energy trying to find out what exactly is going on in other people's code.
For instance, because what looks like one type of call might actually be something else involving operators that takes place between types higher up in the class hierarchies, and what looks like value-semantics may actually be pointer semantics because references are used.
You are often completely dependent on the IntelliSense (or whatever it is called) in the code editor you are using to not get lost.
Next, shared_ptr needs multiple objects for a friggin pointer and C++ lack the concept of "borrowing" which I would say is absolutely essential in a language with unique pointers.
Re:Not gonna happen (Score:4, Insightful)
Most of the so called "idioms" in C++ are what would be called "hacks" in any other programming language.
That's true in any programming language, by the way. Even Haskell, probably the most pure language that is used in practice, has a bunch of "idioms" to make up for the fact that it doesn't have mutable state. Almost any other language would consider that a hack.
No, short of asm, c is the best performer. (Score:3)
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
Re: (Score:3)
C++ is an insane language that no-one truly understands.
Here's an example: according to the Standard, you are not allowed to call push_back() on a vector>. Can you explain why? I'll post the answer as a separate comment on this article.
Re:Not gonna happen (Score:5, Interesting)
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.
Re: (Score:3)
Instills trust, no? (Score:5, Insightful)
Re: Instills trust, no? (Score:2)
Re: (Score:3)
"From you, no. From ESR, quite possibly."
I'd trust an anonymous slashdot poster's anonymous friend a lot more than ESR.
Re: (Score:2)
"quite possibly," and yet not for any apparent or adequately-explained [geekz.co.uk] reason.
Solve the 'problems' of C now they aren't problems (Score:3, Insightful)
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 ;)
Re:Solve the 'problems' of C now they aren't probl (Score:4, Informative)
> 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... [lwn.net]
Re: (Score:3)
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".
Re: (Score:3, Insightful)
(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.
"C with safety" has been tried before (Score:5, Insightful)
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.
Re: (Score:3, Insightful)
Any forceful language isn't tolerated. You know damn well people are going to be driven away (banned indefinitely from communications) for hurting people's feelings.
OpenBSD nor Linux wouldn't exist in their current forms under a rust code of conduct. No wonder the language is such shit.
standard stability and speed (Score:5, Insightful)
Best language for scientific/numerical work? (Score:3)
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.
Re:Best language for scientific/numerical work? (Score:4, Informative)
Re: (Score:3)
It's either MATLAB or Python. I can't imagine how many wheels you're trying to reinvent by doing it in Java because of what ever personal objections you have to Numpy.
Jupyter notebooks is used by a large number of organizations for numerical analysis and display.
Rust? Go? (Score:2)
If it can't target something as small as ATtiny25, it's not an alternative to C.
There are no flaws in C... (Score:4, Interesting)
There are no flaws in C that cant be fixed by becoming a better programmer.
Why C++ is an insane language (Score:5, Informative)
The answer is here: https://bugs.chromium.org/p/ch... [chromium.org]
The Problem With Me-Too Languages (Score:5, Interesting)
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
Re: (Score:3)
Re: (Score:3)
I should have augmented my reference to JAVA with exactly the point that you raise - I did not mean to infer that it was somehow exempt from the problems seen elsewhere, only to offer it as an example of a language that had actually contributed some new thinking to language design. [ At least, I *think* that some of what JAVA offers is original thinking, although I'd be happy to concede that the example was poor if someone can correct me].
If we could return to the principle, howev
Go -- long term alternative? (Score:4)
The Nim Language (Score:3)
Re: (Score:2)
CD is the successor to C? (Score:2)
No, CD is successor to cassette tape.
Re: (Score:2)
... and the "D" you linked to is only one of several C-like languages named "D".
There are also multiple languages each named "E" and "G".
Re: (Score:3)
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? [utexas.edu]. I feel like I need to leave this here for you to read.
Yaz