Slashdot Mirror
Why ESR Hates C++, Respects Java, and Thinks Go (But Not Rust) Will Replace C (ibiblio.org)
Open source guru Eric S. Raymond followed up his post on alternatives to C by explaining why he won't touch C++ any more, calling the story "a launch point for a disquisition on the economics of computer-language design, why some truly unfortunate choices got made and baked into our infrastructure, and how we're probably going to fix them."
My problem with [C++] is that it piles complexity on complexity upon chrome upon gingerbread in an attempt to address problems that cannot actually be solved because the foundational abstractions are leaky. It's all very well to say "well, don't do that" about things like bare pointers, and for small-scale single-developer projects (like my eqn upgrade) it is realistic to expect the discipline can be enforced. Not so on projects with larger scale or multiple devs at varying skill levels (the case I normally deal with)... C is flawed, but it does have one immensely valuable property that C++ didn't keep -- if you can mentally model the hardware it's running on, you can easily see all the way down. If C++ had actually eliminated C's flaws (that is, been type-safe and memory-safe) giving away that transparency might be a trade worth making. As it is, nope.
He calls Java a better attempt at fixing C's leaky abstractions, but believes it "left a huge hole in the options for systems programming that wouldn't be properly addressed for another 15 years, until Rust and Go." He delves into a history of programming languages, touching on Lisp, Python, and programmer-centric languages (versus machine-centric languages), identifying one of the biggest differentiators as "the presence or absence of automatic memory management." Falling machine-resource costs led to the rise of scripting languages and Node.js, but Raymond still sees Rust and Go as a response to the increasing scale of projects.
Eventually we will have garbage collection techniques with low enough latency overhead to be usable in kernels and low-level firmware, and those will ship in language implementations. Those are the languages that will truly end C's long reign. There are broad hints in the working papers from the Go development group that they're headed in this direction... Sorry, Rustaceans -- you've got a plausible future in kernels and deep firmware, but too many strikes against you to beat Go over most of C's range. No garbage collection, plus Rust is a harder transition from C because of the borrow checker, plus the standardized part of the API is still seriously incomplete (where's my select(2), again?).
The only consolation you get, if it is one, is that the C++ fans are screwed worse than you are. At least Rust has a real prospect of dramatically lowering downstream defect rates relative to C anywhere it's not crowded out by Go; C++ doesn't have that.
He calls Java a better attempt at fixing C's leaky abstractions, but believes it "left a huge hole in the options for systems programming that wouldn't be properly addressed for another 15 years, until Rust and Go." He delves into a history of programming languages, touching on Lisp, Python, and programmer-centric languages (versus machine-centric languages), identifying one of the biggest differentiators as "the presence or absence of automatic memory management." Falling machine-resource costs led to the rise of scripting languages and Node.js, but Raymond still sees Rust and Go as a response to the increasing scale of projects.
Eventually we will have garbage collection techniques with low enough latency overhead to be usable in kernels and low-level firmware, and those will ship in language implementations. Those are the languages that will truly end C's long reign. There are broad hints in the working papers from the Go development group that they're headed in this direction... Sorry, Rustaceans -- you've got a plausible future in kernels and deep firmware, but too many strikes against you to beat Go over most of C's range. No garbage collection, plus Rust is a harder transition from C because of the borrow checker, plus the standardized part of the API is still seriously incomplete (where's my select(2), again?).
The only consolation you get, if it is one, is that the C++ fans are screwed worse than you are. At least Rust has a real prospect of dramatically lowering downstream defect rates relative to C anywhere it's not crowded out by Go; C++ doesn't have that.
He seems to think he has some great insight into why C is C, why C++ is C++. But really, he is so fucking clueless I don't know where to start.
There's enough business logic programmed in C++ and Java to keep both languages around until my kids retire and they're not yet in the workforce. Rust and Go, yeah doubt there's a single company of any size running their business processes on either.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
rust and go will only be popular in the hipster circles
when people refer to you by your initials....
MLK
JFK
FDR
and now...
ESR
He's a person, not a technical description.
We have enough abbreviations in tech.
Hate it when people do that.
Thank you, Bradley Manning, Edward Snowden and so many others, for courageously defending humanity, my freedom and more!
The higher the level of abstraction in your language, the higher the overhead it will create. Now, it needn't be so absolutely stupidly overengineered as .net is, but still the metric fits, the more safeguards and handrails your language comes with, the higher the overhead it incurs to have them. This is admittedly not really a huge problem in today's working environment because our computer speeds are far greater than our needs.
Still, somehow it feels silly that I need increasingly more powerful computers just to run the same kind of program, only because programmers can't be assed to learn their trade and instead rely on ridiculously overblown frameworks that is the equivalent of delivering a pack of soda with a semi because you have to bring a soda factory along with the workforce since the framework doesn't know how to deliver a single soda.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Breaking: java programmer has trouble understanding void* and memory allocation, thinks 100ms of garbage collection every now and then is fine. News at 11.
Did this guy ever write anything that needed to be fast or realtime?
The reason we have to say "don't do that" is because C++ remains compatible with C and older version of C++. There are literally billions of lines of existing C++ code out there, and the language committee realizes it can't just snap its finger and order everyone to rewrite all that old code (which is stable, functional, and debugged, btw) because we have something newer and better now.
It's pretty straightforward to write safe, new C++ code if you understand how to use the new features and abstractions. I wrote an entire game / game engine recently using modern C++, and it's amazing how few bugs I've had thanks to recent language improvements and techniques.
I'm not sure where this "large projects can't enforce code discipline" idea comes from. What does he think "coding standards" are, which nearly every major company, organization, or project has? And if someone doesn't understand how to use a smart pointer instead of a raw pointer or avoiding class inheritance hell at this point, then really, they shouldn't be contributing to your C++ projects.
I get it that some people dislike or distrust C++. It's a complex language that's hard to master. They don't like that it makes a lot of compromises in the name of practicality, but that real-world practicality is why many of us use it for large, performance-critical real-world projects. I'd never argue that C++ is the right language for every project. In fact, it's a fairly specialized language at this point. But that level of hyperbole is a bit annoying.
Irony: Agile development has too much intertia to be abandoned now.
Arguing that it's harder for large-scale projects to manage a 'well, don't do that' approach implies that he's completely missed the last 40 years of tool development. This is much more of a problem for small C++ projects than large ones. Large ones have pre-push hooks that run static checkers that enforce rules like no bare pointer and no operator new / delete. It's the smaller ones that rely on programmer discipline to do this that are more likely to have problems.
Go is a horrible language. It has multithreading as a core part of the language, but no memory model and no type system that can express notions of sharing or immutability. The designers clearly realised that generic types are important, and so added precisely one to the language (the map type, which is parameterised on the key/value types). It has a map type that maps from one object type to another, but no way for users to define what equality (or ordered comparison or hash) means on objects.
I am TheRaven on Soylent News
Languages are merely a palette from which to work.
Our job is to elegantly use the tool available to create a solution.
I kind of like the challenge of creating beautiful code in any language.
go is the way to go. Java is good, but is very boiler-platey ... C++ is just a mess. There are no real memory management tools ... and there are just too many shoe-horned things ..
The big problem when it comes to using anything other than Fortran, C or C++ is that 20 years after the first MMX and SSE instruction sets have been added to CPUs, there are only a handful of compilers that known how to vectorize even loops that are hand-crafted to be vectorizable - and the ones that can do it are all commercially licenced (GCC might theoretically have some support for it, but in reality it doesn't vectorize most things). And since most of the performance advancement in silicon has for a long time now been focused in SIMD units, that means that for any performance sensitive workload there are no feasible alternatives. If it has taken GCC 20 years to get not very far, how long will be be before much younger compilers get anywhere with this performance critical feature?
Take the low-level access provided by C, and then add the ability to construct both compile-time and run-time abstractions to an incredibly high level, but with as little cost as possible. That's C++.
C++ is an amazing achievement.
Every academic language approaches Lisp, but every practical language (you know, the ones that actually make the world turn) approaches C++; Bjarne said as much, and he was right.
Anything that allows us to reduce errors, increase functional complexity, reduce development time, improve readability and maintainability, and/or make it easier to code for a greater amount of people, is progress in my book. Working at a higher abstraction level achieves some or all of those goals.
And good frameworks help with that. When I build a house, I don't want a craftsman who takes time to learn how to use an adze so he can plane down lumber to the correct size for the job; I want a builder who knows he can get lumber of the correct dimensions right at the store. The skills to build instead of buy are useful in many trades (both building and programming), but they are expensive and a possible source of additional errors. Frameworks are often a good answer to that... as long as the developer understands the nature of the framework, its limitations, the licensing model, its viability, and thus can assess the consequences of using it.
If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
I'd like that stolen battery life back please, you Code Monkey.
OK... whips open Tor...
What I find kind of annoying is that Ada fixed all these flaws decades ago with Ada 95, now it is at Ada 2012 and still gets no love, just because it's a bit more verbose than C if you use it correctly. (Though not necessarily more verbose than C++.) Sure it has some flaws, e.g. concerning aliases and their scoping rules, but these are mostly inconveniences and some of them have been fixed in Ada 2012. But it doesn't stop there, the same story can be said about dynamic languages. Take fancy new dynamic language X and you can be fairly certain that CommonLisp solved all the problems of the new language already in the 80s.
Maybe developers are in the end less rational than they think? It seems to me that a language must have serious flaws, lots of incoherent shortcuts and tricks, or at least a cryptic syntax to become really successful.
Usually, when you try to merge the 2 ideas, you end up with something as stupidly inefficient as run-time introspection.
So, because the guiding principle of C++ is "zero-overhead abstraction", perhaps it is the case that you must explicitly choose where the computation will occur—run-time or compile-time.
... then how are you not clueless?
Right now ESR is way ahead of you by having some actual thoughts to share, no matter how wrong they may turn out to be. You're nowhere near that. So you go on, pick any thing, start there.
Here, let me help you: Me, I think that ideology makes for poor abstracting in programs, so rust is out. Incidentally that "community" is full of people who are so full of it they "can't even". (Which is one reason why ESR would be wrong picking rust as a successor to C: rust people "can't even", C people very much just do.) Now you pick anything else, maybe the next thing you can think of right off the bat, and enlighten us with your insights.
I remember I interacted with him back when he started the irker project.
That pretty trivial piece of software, written in Python, was riddled with bugs, and no amount of bug reporting and discussing with him the design mistakes got anything fixed for a whole week, despite him actively trying.
I rewrote the whole thing in C++ in two days and it always worked robustly from the get go.
Personally, I think way more problems arise of terse syntax and high symbolic abstraction that C/C++ and derived languages like so much. I mean, I'm as lazy as the next programmer and that's why I like C (and its derived languages) but even I cannot ignore that
{ (a!=1)?b=!b:b=0}
is way less readable than
begin
if a is not equal 1 then set b equal complement of b else set b equal 0
end
You'd immediately spot an error in the second because the sentence would look "wrong".
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Ok, you stated your position in the old debate. It is clear that you want a garbage collected language. Some high profile programmers agree with you, others have different ideas.
Personally, I tend to prefer manual memory management, I think that garbage collectors are wasteful and that abstraction pile is the reason why we have these ridiculous 6 GB smartphones that still have unacceptable latency. But I understand the value of it.
If you don't know how to use C++, just don't. If you want to use Python or Go or Perl, suit yourself. ... (in decreasing amount).
Using 100% of C++'s features is pretty easy (and in a team there are coding standards, when you don't work with monkeys)
If you want elegance and power, C++ is pretty nice (but granted, most of its features are not for newbies and amateurs).
If you want easy you use Basic, Python and the likes.
I've written millions of line of codes in the past 36 years. Mostly x86 assembly followed by C++, C, C#, Ada, Java, Pascal,
By far my favourites are C++ and C# (and assembly because you don't get surprises like when the compiler goes wrong ).
In my point of view, Java sucks and does not compares to C# in term of design and internationalisation.
Of course nobody should care about my opinion anymore than his (nor the Queen of England's)
Opinions and authority argument are fallacies.
Zillions large scale C++ projects, and nobody creates or deletes bare pointers,veerybody uses smart pointers
I do not believe in karma. "Funny"=-6. Do good and forbid evil. Yours, Oft-Offtopic Flamebaiting Troll.
The problem with C++ is that it is a relatively ugly language with fragile infrastructure, that is getting more and more complex and uglier with every new release, because new features are actually not removing the language deficiencies but are workarounds (sometimes very ugly ones) around existing language deficiencies which are just left there so to not break the backward compatibility. As backward compatibility has its benefits, so does ever-increasing complexity its caveats.
It has huge issues, that because of backward compatibility, either cannot be solved at all (Pimpl anybody? memory safety?) or cannot be solved in an simple and aesthetically pleasing way. In my personal opinion, the average code written in C++ (especially C11 and greater) is just damn ugly and is getting more and more harder to understand on the "first look".
In my view the language infrastructure is very lacking by moderns standards and need huge modernization. Also there is a lot of boilerplate code compared to some other languages, like implementation of patterns that are in some other languages part of the language, and because of other stuff like Pimpl, headers, etc. I would move some very common patters as much as possible into the language, maybe not into the runtime, but to make a syntax that will reduce this boiler plate code, this is a synthetic sugar I would like to see in the language.
Of course, solving all this mentioned problems is no possible without breaking backward compatibility. I am not saying that backward compatibility is bad, just stating what are limitations and what we are losing with this choice. The choice has its obvious benefits, but it is also making language less and less desirable to use, and as this continues, I believe that replacement candidates will start popping up more and more.
It's not always so clear cut. What you say is definitely true for naive compilers, but higher-level abstraction also often mean more information for the compiler and more freedom for the compiler. These can translate to better optimisations. To give a trivial example, languages like Java provide an abstraction that looks like a C struct, but don't require that the memory layout be visible to the programmer. Imagine that you create a struct-like Java object with RGB values to represent a colour and you do the same in C. Now you put them in an array and try to do some processing on them. The C version is constrained to lay out the objects as three fields with no padding (this is visible in the language with sizeof and will break ABIs if it dynamically changes). The Java version, in contrast, is allowed to put an unused padding field at the end of the struct. Why does that matter? If you want to vectorise the loop, then being able to guarantee 4-element alignment for every object in the array is a huge win. This is a legal transform for a Java compiler, but not a legal transform for a C compiler unless it can prove that no pointers to the array escape (and a few other constraints).
The big advantage of C was that a fairly simple compiler for a simple architecture could get very good performance. The disadvantage for C is that compilers quickly hit diminishing returns and the abstract machine makes a number of desirable optimisations unsound.
For example, if your language has a first-class notion of immutability, then this gives the compiler the opportunity to elide copies or add copies if they make sense for NUMA systems, and gives the compiler a lot more freedom with regard to reordering or eliding loads. Similarly, if your source language has higher-level notions of sharing then this means that you can avoid a lot of defensive memory barriers that you'd need for correct C/C++ code. If your language has stricter guarantees on aliasing, then a whole lot of optimisations suddenly become easier.
Any compiler optimisation is a mixture of two things: an analysis and a transformation. The analysis must be able to tell you if the preconditions for the transform are met. The more information you can give to the compiler, the more often the analysis can prove that the preconditions hold and enable the transform.
I am TheRaven on Soylent News
And the programmers who write your phone apps would like it very much not to waste 10x or 20x of time writing software in a half-low level and half-high level language like C++. That's why they use Java (Android) or Swift (iOS). Before Swift, programmers had to use Objective C, which is slow as hell in terms of app development time.
I can tell he has no real relevance in todayâ(TM)s programming world. Java is a disease, and nothing will dethrone C/C++
And good frameworks help with that. When I build a house, I don't want a craftsman who takes time to learn how to use an adze so he can plane down lumber to the correct size for the job; I want a builder who knows he can get lumber of the correct dimensions right at the store.
On the other hand, when all you want to build is a garden shed, you can do it yourself in a quick week-end afternoon project by quickly nailing a few planks together. You definitely don't want a several month-long adventure involving half a dozen sub-contractors (and each further down, their own individual group of a dozen of sub-contractors), plus hiring a few special planification manager (because sub-contracors D and Y each out-source their screw to a different sub-sub-contractor. Incompatiubles) which will all require two hectars of work space around your shed. And somehow the garden shed need to be connected to an industrial triphase 380V power connector in order to be able to function.
Some time, over reliance on frameworks and helpers means that some very simple projects that would be handled by a few dozens of C or C++ lines of code (perhaps a couple of hundreds top), suddenly need to pull more than 20 MiBs of libraries in the package and are dependent on 200 different github repositories (hoping that they'll not blocked on the dev's whim - see Node.js and string alignement). And you need to use special command line settings to tell the VM to allocate 2 GiB of memory for the process.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
With so many languages, try searching a code snipped for "c", "go". Why can't they give a unique name to them??
The higher the level of abstraction in your language, the higher the overhead it will create.
This is exactly why C++ remains popular among those who create large, complex, high-performance applications. C++ is well known for using zero-cost abstractions. That means you get the performance of low-level C code, but can design much safer interfaces and type safety in your code which allow the compiler, not a runtime, to validate that the code is correct and safe.
For certain types of applications, it's an effective compromise between the pragmatism of retaining backwards compatibility with decades-old ecosystems, while at the same time providing better safety and abstractions than C.
Irony: Agile development has too much intertia to be abandoned now.
My first thought was they were referring to some system's Extended Support Release.
Did you get ! mixed up with ~; or is b a boolean and 0 should be false.
Either way, your 'English' equivalent was wrong and it doesn't look wrong.
Simple... I needed something better.
C and C++ are both amazing languages but :
a) C and C++ are not and never have been worth a damn as a standard. Even in the absolutely best C and C++ code, there are so many platform abstractions and #ifdefs that it's a nightmare. Neither C or C++ are useful as a platform.
b) C and C++ are not so fast anymore. There was a time where you couldn't write better code in assembler than a well optimized C or C++ code set could produce. Working in tools like Intel vTune Amplifier and optimizing your C or C++ code allowed amazing code performance to be achieved. Then money was spent on JIT technologies and hand optimized JIT code ended up being substantially faster in most cases.
c) C and C++ are more versatile than any other languages because you can program at a register level if you choose to. Need to make a new kernel system call interface... C or C++ are your languages. If you want to hand code vTables for object inheritance, C is for you.
d) Everything useful in C/C++ requires non-standard language extensions. Need proof? Look at the Linux kernel and try compiling it with a strict standards compliant C compiler.Try the same with the different standard C library implementations.
I can go on, but in reality, C and C++ are not very good anymore for anything other than operating system and JIT development.The code they generate is often far less than optimal. They target individual CPU revisions. They have no internal knowledge of the cache management structure of the system they're running on. They can't optimize code on the fly for "inlining" code differently based on how it is used and the current state of the processor pipeline architecture. Multithreaded and multiprocessing code has to make excessive use of locks (semaphores, mutexes, etc...) to manage shared memory and cache coherency because pipeline directions aren't easily detected and IPC can't be achieved exploiting ring-bus direction to its advantage since the compiler has no idea whether it's running on a ring or a mesh or even how many cache levels it has available.
This is what make things like CUDA far more interesting for high performance computing. If for no other reason than the CUDA compiler runs as AOT for the local platform. C and C++ is limited to whatever the developer compiled for.
Let's talk memory management. Garbage collected memory in a dynamic memory system is ALWAYS faster than manually managed memory. Using even the best memory allocators in C and C++ generally causes fragmentation hell. Let's also consider that free always frees now. They depend on pool systems which are often quick but make an absolute mess of the system. Memory is in fixed positions which can't be defragmented.
I can go on and on... but in 2017, no hand coded memory model will ever compare to a good garbage collected memory manager.
While I'm not a huge fan of JavaScript, I love Node.JS performance. Node.js is absolutely insanely high performance because of roughly a billion dollars invested by 4 companies in competition with each other to make the fastest JavaScript JITs. Right now, for code performance and memory optimization techniques, there probably isn't anything out there that can touch JavaScript for performance. Let's not forget the inherent async programming model of modern JavaScript which makes it absolutely beautiful for multithreading or even more importantly, scaling through microservices.
Again, I can go on and on... but these days you can use things like EnScripten if you really must have C and C++. There's also things like TypeScript and other languages which transpile to JavaScript. There's also some high end compilers like C#/HTML5.
These days, there's absolutely no good reason to be using C/C++ unless you're a sadomasochist who actually thinks they can write better code by hand than can be produced by modern JavaScript JITs
Managed language will never replace native languages and vice versa. Eventually Rust or Go will replace Java thanks to Oracle crappy leadership..
That's the only RMS that I know.
.Net is the Transformers of programming languages
If you want to say that it explodes violently in your face from time to time, it has an attitude that few can stomach, is way overengineered for its supposed purposed and manages to go around in circles of trying to fight itself and stand in its own way instead of getting to the point and be done with it, yes.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
...to ELO?
With some extra spaces, and the whole thing changed to an expression (which is how ?: is supposed to be used) it's a lot easier to read.
b = (a != 1) ? !b : 0
The advantage of the ternary operator is that you only need the LHS part once, which helps if it's a more complex variable.
In the hardware? We already do a lot of MM in the hardware.
Goes to show a lot of American coders out there whining about losing their jobs.
As you have shown the error stems from the programmer, not the language. If you can't easily look at that C code and see that it won't compile then that explains why you find the language difficult. You don't even have beginner level proficiency.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Pimpl is solvable by creating an implementation class and and interface class that has a reference to that class, and if you are crying about memory safety starting with C++ 11 there are smart pointers.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Hates C++.
Loves Java.
Go will *replace* C?
Is there anything of value to read here? (No I haven't even RTFS)
I tend to rant.
How do I write drivers and firmware in Go? I think C is going to be around for awhile.
We'll make great pets
I know in my worthless opinion that if I have to choose between getting pointers right in C++ or LISP's handling of parens where literally having too many or too few causes your app to crash then damn it, I'm going with the pointers.
Did you know 80 to 90% of the moderators on slashdot wouldn't recognize a troll even if one dragged them under a bridge.
If your point was to make that part more readable, I think I want you on the other team in the next debate.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
The good thing about Rust is that the overhead is in programmer and compiler time, not in run time or a runtime library overhead. Their binaries are slim and fast.
The bad thing is that there is a lot (big lot) of overhead in programmers brain and a slow compiler.
A kernel running java?
I don't want to wait 3 days for my computer to boot, let alone 3 weeks before the hotspot detector makes it *close* to usable.
If Java is so great, we would be running compilers written in java, running on a java machine in java, which runs on a library in java. More recursion would mean more speed!
But we don't. We still code in C. Everything performance oriented is in C or Assembly. If you don't care about performance, use Java.
OK. We've seen you go on and on about how a language you don't use or understand is horrible because you saw someone say it on Youtube. Thanks for sharing.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
I find
(a != 1) ? b=!b : b=0;
much easier to read and quickly interpret than "if a is not equal 1 then set b equal complement of b else set b equal 0". The former has much clearer delineations between the test and the true/false actions, for example. It can also be automatically formatted for readability by a code beautifier.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
Oddly enough today I have been trying to track down a crashing bug in a rather large Go project created by some ex-googlers. Which became a stable release as few releases back.
In the logs it produces I find:
panic: double close
and
panic: to many xyzDone() calls.
As is often said, garbage collection of memory is only part of the resource management problem.
Meanwhile using C++ last week I uncovered memory leaks and race conditions in openssl using the clang analysers. I presume openssl is written in C.
I'm afraid it's hopeless!
The higher the level of abstraction in your language, the higher the overhead it will create. Now, it needn't be so absolutely stupidly overengineered as .net is, but still the metric fits, the more safeguards and handrails your language comes with, the higher the overhead it incurs to have them.
Nope. Rust is a so called zero-cost abstraction language. What this means is you can pile layers of niceness to have clear and understandable code, and the generated code will be as good as if it had been hand-coded, manually unrolled.
Getting rid of C/C++ isn't just for the fun of it. Language designers have done some real progress since a few years. Nowadays you can have beautiful and efficient code.
How much extra hardware could Equifax have had running with the cost of their breach? 10x? More?
If Java GC worked, it would package itself up, collect itself, and delete itself from my system.
According to my browser's search bar, ESR never used the word *hate* in post you entitled "Why ESR Hates C++, ...".
Please don't do that again.
Thanks.
I'd like that stolen battery life back please
OK, just pay more for the extra development time, or use a version with fewer features. Every decision has trade-offs.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
But what happens when everybody buys lumber at the store? There still must be somebody that make sure the lumber is the right size and quality for your project. This problem is exactly why we today need giga range cpu's and ram just to watch a web page. Nobody knows how to deal with the details any longer, and so they end up building a new house every time there is a new problem.
What you say is definitely true for naive compilers, but higher-level abstraction also often mean more information for the compiler and more freedom for the compiler. These can translate to better optimizations.
Did you actually just pull the "sufficiently smart compiler" argument for higher level languages? There's a good write up on it at http://wiki.c2.com/?SufficientlySmartCompiler (and in that, when you see the statements about SSCs have been created, read the comments below that explain how those benchmarks were debunked and java is in fact, still slower than C).
Seriously, as the SSC has never been created, your argument is hypothetical. And until you can create it, the SSC is not a good argument to make. It's sort of in the realm of P = NP. Nobody knows if it's possible, so it's best not to make arguments based on it until its figured out.
It is 5000% more readable than the original. Perhaps you can't read.
The python version of this works really well.
foo = 1 if condition else 0
Computer modeling for biotech drug manufacturing is HARD!
A language that has keywords like `static_cast` or `thread_local` has reasons to be hated.
Slashdot, fix the reply notifications... You won't get away with it...
Beginners and expert obfuscators write the terse C++ style.
Good Go-programmers just use simple if...else-semantics, and use meaningful but shortest possible variable names.
Energy is free.
Therefore we need not concern ourselves with writing a efficient piece of Software ONCE to be used by BILLIONS of people burning clock cycles.
Though memory consumption might fall under marginal costs at the start of a new hardware generation, swapping out memory will consume more energy in the long term or require trashing the computer and wasting energy on a new one earlier.
There's a tradeoff involved.
(DRM is also funny, consuming 3 times as much Energy than non-DRM'd BD's. I guess other applications suffer similar costs.
Also nice to throw away your TV or other HW because the standard got changed. Or the smart TV's Apps break one by one.)
Parent said:
"The C version is constrained to lay out the objects as three fields with no padding (this is visible in the language with sizeof and will break ABIs if it dynamically changes)"
That is incorrect.
I used to write C code, and in my work, the struct fields were padded by the compiler to start on 4 byte boundaries by default. (This was because there was a speed penalty on SPARC CPUs to access words that were *not* aligned this way.)
The gcc compiler gave you options (compiler flags) for how to align the struct fields. You could specify padding or not. I don't see why this would not still be the case.
If your point was to make that part more readable, I think I want you on the other team in the next debate.
If you find that unreadable, I don't want you on my team in the next software project.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
If your point was to make that part more readable, I think I want you on the other team in the next debate.
If you find that unreadable, I don't want you on my team in the next software project.
Well, I do have to say that the code would not pass my code review. Not because of the use of the ternary operator, because of the meaningless variable names. I'd also ask that "0" be replaced with "false".
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
“I don't know what the language of the year 2000 will look like, but I know it will be called Fortran.” —Tony Hoare, winner of the 1980 Turing Award, in 1982.
It is now 2017, is it called FORTRAN?
We still compile FORTRAN source and make static libraries out of them. We still link with them. But there is no development in FORTRAN.
If Go is able to deliver a kernel that is "not leaky" whatever he means by "leaky", we will get compiler directives that will deprecate and eventually disallow C compatibility. C++ compiler will build intermediate binaries compatible with Go based linker and loader. The sources that could not be migrated to disallow C will become unmaintained static libraries that are buried deep in the code base along with Fortran libraries, and IMSL and BLAS and other such esoteric code that have become living fossils without any upgrades and revisions.
Go programmers will occupy the niche presently occupied by pure "C" programmers. The vast majority of developers will be working on higher level languages, C++ mostly.
After dissing the prediction by "expert" why do *I* venture to predict?
Hubris. Somehow I convince myself that because I am on the front line of development and see the incoming resume stream and skill sets, and know the magnitude of installed code (25,000 CPU hours for Level 2 testing, 2 to 4 million CPU hours for a complete release testing) I would be able to predict better than theoretical experts. But I could be wrong.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
You're a typical /. moron... assuming stuff without any proof. Thanks for lying, asshole.
Since ESR is a fucking moron.
If you're a developer, that was considerably more readable than the COBOL-like version you translated it to.
I could read it immediately: set B to not B if A isn't 1, else 0.
Developers who become used to a particular language generally can read it as long as it's formatted correctly, which religionofpeas did. Even stuff like while(*d++=*s++); becomes second nature. The key isn't in avoiding symbols, which you're supposed to be able to just read if you plan to do any coding at all, but to ensure formatting and sane use of whitespace makes turns a string of symbols into a set of instructions.
You are not alone. This is not normal. None of this is normal.
ERLANG / ELIXIR
Zero machine-cost abstractions, maybe. High mental cost abstractions, certainly.
I find Haskell has less mental cost than C++.
I think you meant: b = (a==1) ? 0 : ~b
C does not have a boolean type. Instead it tests for truthiness by checking whether the value is zero (false) or non-zero (true). That bit of code might not make sense, but it will compile.
In Soviet Russia, Jesus asks: "What Would You Do?"
The C version [a struct] is constrained to lay out the objects as three fields with no padding (this is visible in the language with sizeof and will break ABIs if it dynamically changes).
This is just wrong. From the C99 standard, section 6.7.2:
13 [...] There may be unnamed padding within a structure object, but not at its beginning.
15 There may be unnamed padding at the end of a structure or union.
struct RGBP{
int R;
int G;
int B;
#ifdef WIERD_PADDING_REQ
int Padding;
#endif
};
OK, yeah. There's no (so far as I know) guarantee the compiler will put them in that order in the object code, or someone won't fiddle with things later on. Maybe you can use a union with an array or getter/setter functions. But really, how much "simpler" is the corresponding java class going to be anyway?
That list of Rust "friends" is pretty misleading, I think.
Few of them are what I'd consider real companies. I define a "real company" as one that produces a usable product, has a significant number of paying customers, and makes a consistent profit.
A lot of them appear to be extremely early-stage startups, which will most likely fail, if they haven't already.
Some of those "startups" are probably no more than a lone college student who has fantasies about being an entrepreneur, and who threw together a logo and now thinks he has a "startup", despite lacking every other aspect of what's typically considered a business.
Even the biggest names on the list, like moz://a, Dropbox, Coursera and OVH, really aren't that big at all and it sounds like they're barely using Rust in any meaningful way.
I think that list of Rust "friends" actually shows how pathetic Rust's adoption has been. So far it has only attracted wannabes and minor players. Even a language like Go has a powerhouse like Google using it, at least.
Nobody outside of moz://a appears to be using Rust in any serious way. At best it has been used experimentally. More realistically, its "usage" is just some college student's fantasy "startup" that someday, maybe, hopefully, possibly, will use it.
For HPC (high performance computing) I don't see C++ going anywhere. For HPC the only viable languages I see are C, C++ and Fortran since they have the best optimizing compilers.
Mostly I use python for command and control with a simulator written in C++ and this seems to be a pretty common setup for HPC applications.Command and control often has a lot of code but is 1% of the compute time so write it in a high level language and then do the simulator is something that is FAST.
Computer modeling for biotech drug manufacturing is HARD!
but that is not practical for large applications.
your statement is meaningless drivel without some sort of evidence, but you don't have any
Just a couple of weeks ago Slashdot reported that moz://a has gone back to suckling on Google's money teat. Keep in mind that this is very likely moz://a's main source of income.
So as far as I'm concerned, moz://a is effectively a department within Google at this point. In practice, moz://a's projects, including Rust and Firefox, only really exist thanks to the budget they get from Google.
I'd expect Google to pull their financing of moz://a well before they'd kill Go. That means that Rust, which hasn't seen much real use outside of moz://a, could very well perish in such a scenario.
It really doesn't help that Rust's hype is evaporating. And to top it all off, the most recent releases of Firefox that include more and more Rust code have been among the worst ever. Firefox 55 and 56 are often described as being very slow, and although Firefox 57 is supposedly faster compared to those dreadfully slow Firefox releases, it's still slower than its main competitors. In my opinion, Rust hasn't improved Firefox in any noticeable way, and may actually have made it slower!
I'd trust Go's long-term future over that of Rust. There's at least some tangible, financial benefit for Google to keep supporting Go. On the other hand, a language like Rust exists almost as an accident at this point. If Google ever stopped funding moz://a, it could be a total disaster for Rust and anyone silly enough to consider using it.
Programmer time is really expensive though...
A colleague and I were joking around one day, when a hardcore-dev (with a lot less humour, and chronic flatulence, as I remember) overheard us. He maintained that super-terse code is easier to read than the alternative. Since we were just messing about, we both just let him say his peace and then stated that the One True Language was of course Turbo Pascal 6 (which sort of ended the conversation).
My take on it is that the terse syntax does make sense (more quickly) to someone who knows the syntax really well. If you don't know it quite as well, then the long-form is better because as OP says "the sentence would look wrong". Also, actual words are 'googleable' where as it's hard to lookup the meaning of "~->" or whatever. Thus, the long-form plays to more average programmers.
The question then becomes... who should a language be for? For the super-expert, or for the midrange programmer, or possibly even the junior? IMHO, midrange is a good place to aim at because that's where the majority are, and if they're using your language then you'd want them to be able to do so reasonably easily and safely. That way, of all the billions of opcodes executed around the world as a result of your language, the majority of them will be reasonably safe and sensible.
> C does not have a boolean type.
It does, since C99.
https://en.wikipedia.org/wiki/Boolean_data_type#C.2C_C.2B.2B.2C_Objective-C.2C_AWK
Given that the performance of Rust is often inferior in peformance to doing the same job in C++, I'm not sure how you arrive at the notion that it has zero cost.
File under 'M' for 'Manic ranting'
So we are listening to a neo-pagan gun rights advocate who denies global warming. He seems like a perfectly rational bloke!
A C compiler may add padding, but its ability to do so is constrained (or mandated) by the platform ABI. The layout of a struct is exposed directly in the language because you can ask for sizeof() the struct (which, if you subtract the size of all of the fields will tell you the total padding) and you cast a pointer to a field and a pointer to the struct to char*, subtract one from the other, and get the offset of each field. This means that it is effectively impossible for a C compiler to add padding to make optimisations easier (the only case in which they will reliably do it is for on-stack structs that are not address-taken).
I am TheRaven on Soylent News
If you want readability over efficiency, here's what I would write:
b = !b;
if (a == 1) b = 0;
There's no (so far as I know) guarantee the compiler will put them in that order in the object code
There is no guarantee that the compiler will put them in the object code. There is, however, a guarantee that, if a pointer to one has escaped from a compilation unit then the layout will be the same for all compilation units (including, implicitly, ones that are in shared libraries that are dynamically loaded as plugins). In contrast, there is absolutely no guarantee of structure layout in Java, and typical JVM implementations sort the fields to have primitives and object references contiguous, to simplify GC.
I am TheRaven on Soylent News
ESR is making an early invalid assumption - that "fast transparent garbage collection will happen".
Sorry, no. The smartest people in the CS world - possibly the
smartest in the world, period (specifically those at MIT AI Lab,
Xerox PARC, BBN, TJ Watson, and Stanford) worked the GC problem
for literally 20 years, throwing hardware at it, software, tagged
architectures, secondary processors, all that.
They never cracked it. GCing at realtime speed is just a tough problem.
Unless ESR can show me code that can GC in faster than O(n) time
AND not have to freeze the allocator process for O(n) time, he's just
pitiably wrong.
(and no, I don't count flip and sweep GC as workable in this, as it
means that a buffer that DMA hardware is writing to will move without
warning. Nor is "generational" GCing, all that does is to stave off the
inevitable full-out GC for a few minutes to hours, which is fine for a
hacker sitting at a terminal but no good at all for a self-driving car or
SaaS server).
Now, I could be wrong; if he *has* a realtime garbage collection algorithm
then he deserves the Turing award.
But I'm betting "not".
Or at least an "engine" with code hugging around it. If that's the case, then I have no reason to leave Python. I don't trust anything made by Google.
Rust doesn't need a garbage collector because everything is tightly and explicitly scoped. Nobody who's written a line of real-time code imagines GC to be in our inevitable future and even in the kernel. Shudder! Maybe if GC were incremental and didn't go out to lunch it would be different, that is of course an implementation "detail", but one not properly addressed.
Why do you think that is a useful skill to have? Simple syntactical errors is something that the compiler can catch for us.
It's better to be able to spot logical errors.
If your compiler doesn't catch typing errors and lets them become runtime errors instead, switch compiler/language.
You're goddamned right C wasn't type safe or memory safe, because it wasn't meant to be. C grew out of the real problem of needing a programming language that was very close to the assembly language while being at a higher level, and was created to allow bare-metal OS programming direct to the hardware. It so closely follows the assembly of a PDP-11 CPU it isn't funny.
Having cut my teeth writing code at that level in C, and had to manage my own memory, interchangeably call a block of memory many different things with casts and pointers and bit operations, it was an awesome language.
C has no safety net whatsoever, nor it is meant to. What it isn't is a high-level language for people who need to be hand-held with type safety and with huge gobs of programming libraries to do all of the work for you. The things C excels at are for people who can operate without a net, close to the bare metal of the machine, where both writing tight code and having the knowledge and flexibility to do something like an "array of pointers to pointers to printf like functions" or any number of strange stuff people did in C on a regular basis.
There are many higher level languages suitable for people who need type safety, training wheels, and safety guards and libraries of functionality. And those languages have their place in the world and should be used where applicable.
But there comes point where you're doing certain kinds of tasks, that C will always be the required tool ... precisely because it's got no safety net and is pretty much suited for close to the hardware type stuff, where type safety and training wheels is just going to be too slow. You're not going to write an interrupt handler for a piece of hardware in some high level namby pamby language which makes sure you don't poke yourself in an eye and which imposes vast frameworks and type checking for you -- because it will be too fucking slow.
I'm definitely NOT saying all things should be written in C. But I definitely AM saying you learn things as a C programmer that you simply cannot learn in other languages, because it requires a level of understanding many languages go to great lengths to remove for you.
This is why I've met far too many programmers who don't really know what the hardware and OS really does, and are just simply used to pulling in yet another library to solve the hard parts. They've had so much abstracted away for them they have very little real understanding of what is actually happening, and in some cases that limits them in ways which is hard to overcome.
Programming in C is like orienteering or making a fire from scratch .. there's a foundational aspect to it which is valuable to have, and which can give you a better understanding of things when you're not doing things which require it.
People who complain C isn't type safe have missed the point. We wouldn't have UNIX and Linux or most modern OS's without C, because it really is that important. Don't decide retroactively that because it doesn't hold your hand and look out for your safety there's problems with C. The problems people were solving in C pretty much required you to really know what the hell you were doing.
Which of course makes the assumption that you're dealing with a boolean, and not a pointer, or some other data type. 0 often maps nicely only many data types, but 1 does not.
Right, Unix/C was written in the early 1970's before good optimizing compilers. That ternary expression is almost the same as the assembler operation to do it, e.g. (~b) means "bit-complement the value of B in some register". On the other side is the COBOL sentence-level "if a is not equal 1 then set b equal complement of b else set b equal 0", which is too much code. Languages should have readability to humans over syntax that is computer-friendly.
The C version is constrained to lay out the objects as three fields with no padding (this is visible in the language with sizeof and will break ABIs if it dynamically changes).
That is compiler specific, just because the C compiler you used doesn't add padding doesn't mean that the C compiler isn't allowed to.
It can make every field into a 32 bit value if it wants to. This could be beneficial on the ZPU architecture where byte access often is emulated.
Dynamic change doesn't have anything to do with that. The structure size is decided at compile time.
Yes, it will break ABI if you use different compilers that pads or packs structs differently. That is why many compilers gives you a lot of control in how it handles the structs.
That's why they use Java (Android) or Swift (iOS).
No, the reason developers use those languages is because they are forced to by Google respectively Apple.
I do not use Rust but I read enough of the book and saw enough of the tutorials to know that Rust has no garbage collection because it is not needed! The borrowing concept allowed a compiler to be written that prevents the things that cause memory leakage in the first place. No garbage collector is not a negative thing in this case. It is a very, very great plus, Does ESR really not know that?
English is a horrible mess that's unsuited to programming. (Which might, arguably, be why AppleScript was so widely disliked. It tried a little too hard to follow the natural language metaphor.)
However, we definitely could do better, and we could make code more explicit and more readable. Sometimes I get the impression that serious computer language geeks are afraid to even talk about syntax. The subject is too lowbrow. We all know that language geekery is all about impressing other language geeks with your knowledge of abstruse comp-sci concepts. (Just scan the other comments on this piece!) Easily readable syntax isn't sexy like that. A highly readable language might even suffer the stigma of being "dumbed down" and unsuited to Real Coders.
I remember reading a comment from Chris Lattner explaining why Swift syntax is so C-like. We could have made it more readable, he said, but we felt it was more important to keep it familiar-looking to C programmers! The implication (to me) was that readable syntax is a frivolous matter, not worth expending any concern or effort on.
He should add "programmer" to his LARP resume
The problem is that we've added layer upon layer such that we still need C to write the OS underneath even though CPU's are a thousand times faster than when C was started. You'd think we'd have enough headroom by now.
If I put objects in objects in objects in classes in python or java it can blow up in my face. I don't know if Rust is genuinely "zero cost", but at least if there's any slowdown from my compulsive OO and encapsulation habits it hasn't been nearly as bad.
[...] the equivalent of delivering a pack of soda with a semi [...]
Oh, man. When I was in junior high, we heard rumors of Jolt Cola giving guys erections, but I just thought it was an urban legend.
You'd immediately spot an error in the second because the sentence would look "wrong".
No I wouldn't, because I'd have to read the sentence, then read it again because it doesn't quite read like correct English. Then say, "wait, what?" and read it again.
In junior high? You'd probably have an erection anyway if you drank nothing but tap water.
That is not true for modern processors and modern C.
Structs will always be padded and filled up to the next best fit to make its size a multiple of the register size, unless you add zero sized bitfields to indicate that you don't want padding.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
The main issue that is never addressed in these "OH, c/c++ is going to die" sorts of arguments is interoperability. At any point in time, C++ code can fall back to C for any of its shortcomings. And at any point in time, both C++ and C can fall back to inline assembly for both of their shortcomings. So this is already three separate languages playing very nicely with one-another. And then on top of that, most other languages out there to be successful have some sort of either C or C++ compatible interface. Need a new PHP module? They're written in C. Need a new Lua module? The same, it falls back to C. Need dynamically loaded/unloaded code at run time? Shared objects and DLLs using the C calling convention, regardless of which language they're compiled from initially. This trio of languages is the foundation of everything else on the computer cooperating and working together in unison, whereas all other languages are trying to be walled gardens upon which they can only access themselves and nothing more.
The other issue to a lesser extent is that C and C++ are strictly languages, not libraries. The compilers provide standard libraries, but they're never included by default. This allows for some interesting things to happen, such as the community building replacements for various "built-in" libraries. This also allows for the "built-in" libraries to be maintained and updated separately from any one particular compiler. This level of flexibility is what truly gives C and C++ their powers.
Important questions like "does this look like FORTRAN to you"?
Watch this Heartland Institute video
You can not put objects into objects into objects in Java or Python ...
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Considering ESR is generally considered to be, on a technical proficiency level, not a particularly good programmer, why does his opinion on this hold enough weight to merit a Slashdot post?
People who do electrical engineering learn to read and understand the funky symbols they use in electricity. We don't expect them to write out everything in plain English. It's the same with programming. Your Pascal-y pseudo-code took how much more space and time to convey no extra information? Your pseudo-code actually took longer for me to parse and understand than the C version.
Please read my reply to the other poster. TL;DR: The C compiler is required to either add the padding required by the ABI, or prove that no pointers to the type escape from that compilation unit. It is not free to add padding to improve optimisation unless it can prove that no pointers to the type escape (which is typically impossible).
I am TheRaven on Soylent News
C has had a _Bool type for 18 years and a stdbool.h header that defines bool to be _Bool.
I am TheRaven on Soylent News
You can use a data structure that was designed for runtime allocation.
You're so mad. One wonders what you're compensating for.
So can we please stop reporting on every damn stupid thing he does or says like it's actual news?
The man's just an internet crank who happens to like Linux, enough of him already.
Why not write a program (in whatever language you like) to be run at build time to compute those values and then output the necessary C++?
We're talking about simple code style rules, easily enforced with code reviews or static checkers. These are easier to do in larger projects than in one-person ones. These rules won't make people write good C++, but they will eliminate some large classes of errors.
If you've got a lot of legacy code that is in the wrong style, and it's C++, you can change it slowly and make it more reliable. We found a few bugs simply by adding "override" to our function definitions, for example.
If you can't get your programmers to follow a few simple rules of style, you're screwed no matter what language you're using. If nothing else, you'll find yourself with piles of code you can't read easily that could hide myriads of bugs.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
depends if b is expected to only be 1/0 at the end of this function even if it *may* be some other true value (why this would be the case I do not know), also !b is going to be faster than ~b in many cases. But! write it as it makes sense and profile to see if that speed is an issue or not.
Given the a b operators (yeah I know this is an example, but I'm running with it) this is likely an inline function that will be called very heavily in a nested loop or somesuch... as a result the speed of operators can have a very noticeable impact.
True story:
Had a co-worker that did something very similar to this, but b was a UINT64 and he used it to store a bool. used ~ operator to toggle it.
When he needed to make it look like he was busy and improved performance he switched it to a UINT32, then UINT16, then UCHAR, then to use the ! operator instead of the ~ operator.
I didn't rat him out because our manager was a dolt and my co worker was actually working on a hard problem, but manager was one of those "didn't see an improvement, so you were wasting time" people.
whois gawk date unzip strip find touch finger mount join nice man top fsck grep eject more yes exit umount sleep dump
I wish it was only once a decade this topic reared its head, but it seems like it's once a month.
Replace this, don't use that, the other one is OK but that one there is better... hey look, a new language that solves all the problems of C! I'm sure this will seamlessly and effortlessly replace the many trillions of lines of legacy code and function without any objective flaws whatsoever!
C++ is fine. Java is fine. Rust isn't that bad. Go is certainly a programming language. Nothing is perfect and the pursuit of perfection will only generate another imperfect option to choose from.
C is not going away. Get used to it. If you don't like it then that's fine and everyone else who does should get used to that too. There's just so many options... so many... I don't see why this is even an issue at all anymore. Programming is like any other engineering field: If it's broken it gets fixed, if something new and better comes along you can replace the old and busted when it becomes cost effective.
Any other approach is hubris, pride, vanity or any combination of those things.
I think you fucked up your use of the ternary operator in your OP.
If you're throwing away its result, you're doing it wrong.
You never need an assignment inside the ternary. It always belongs on the outside.
"Slow Down Cowboy! It's been 58 minutes since you last successfully posted a comment" -- slashdot, driving users away.
While I certainly not found of C++ myself, I can certainly code in it. As it stands, most of the problems that I have to solve on a regular basis does not involve usage of that language directly. That said, I still think there is use for it, even beyond legacy compatibility. I typically work on user-land applications, data ETL jobs, and web services. For those, Java, C#, SQL, and the occasional bit of Python each are well suited for the job. There is less cognitive overhead to simply code for solving the problem, and then tweaking for minimizing performance issues and garbage-collector/resource leaks.
I have, on occasion, needed to interface with low-level hardware. In a Windows environment, C++ typically proves to be an excellent tool for the purpose. For the same purpose in Linux and DOS, I typically use "old fashioned" C if not using any APIs/libraries that would make C++ the better choice. I do not mind mind managing my heap in those cases and for C++ I can make use of RAII (stack).
This is not to say the Rust and Go (which I have not got around to trying) are bad choices for a project; however, I would not simply assume they are a silver bullet for a problem. I will also mention that sometimes a sub-optimal tool can be used for the job in a pinch. In the physical sense, I would normally use a hammer for a nail and a screwdriver for a screw-- I have used a hammer to beat in a screw and I have used the back of a screwdriver to insert a nail (and lamented the entire process).
Now, concerning ESR's position, I certainly see his reasons. Since my thoughts are difficult to articulate, I shall make a comparison to my browser: Firefox. I first started using it (under the name of Phoenix) because it was not Internet Explorer, but lighter weight than the then bloated Mozilla-branded browser. It had problems and it was lacking features, but it did provide enough customization that I was comfortable using it. Since then, missing features were added, security holes were patched, features that I had liked were removed since they were either troublesome or not popular, and it has gained bloat (likely to fulfilling features) similar to its predecessor. Other browsers are starting to look "shinier" to me. C++ is a language, but it, like application, will evolve to the niche of the target audience. Individual users, whether speaking of applications such as browsers or languages, will each have different needs and different limitations they are willing to tolerate. I prefer to focus on solving the problem, but I do not mind taking on the extra responsibilities if it brings me benefit. I have had talented co-workers that are absolutely allergic to idea of managing their own memory, but loves to "create clean elegant solutions." I have also had other talented co-workers that absolutely refuses to trust language/library provided mechanisms such as garbage collection, but they have the attention to detail and the background of knowledge to rapidly create lean and correct solutions to problems where they do have that level of control.
For the TL;DR, have a reasonable set of ability to use for the time and effort you are willing and able to invest in the niche that you can or want to fill. Find the right balance of flexibility and proficiency that matches the limited resources to invest and the opportunities available. Also, remember that ESR is a quasi-public figure with strong, sometimes bitter opinions: earnestly consider them, but take them with a grain of salt. I will also note that concerning his mention of the futility of trying to predict the future (the next big language), it is like predicting the stock market in that some things will stick around forever, but have only modest returns; however, a penny stock have the possibility of a minimal investment with a big return, but also carries a high risk of just being a useless waste of resources.
He gets 'ranked and rated' by LOC/day you insensitive clod.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
God I love the ternary.
Then again, I love F#'s match even more.
Can someone clue me in about why Equivalent Series Resistance has anything to do with taking my trash to the dump? kthxbai
Superflous verbage does not more readable code make.
Though there is a macro that functions like bool in stdbool.h
I'd also ask that "0" be replaced with "false".
I'm so hoping that was a joke.
When I'm working in a low level language, I absolutely abhor the compiler doing stuff behind my back. Padding, re-ordering execution, all that garbage does is give more chances for bugs. I really wish we could have a language whose specification would _never_ say "implementation dependent". How many times have you seen code that defines their own "BYTE" or "INT16" because the C language allowed it to be different.
Sorry, that is plain wrong.
Basically everything regarding padding - and even ordering of fields - is implementation dependent and not specified in any standard.
Supposing short is 16bits and int is 32bits and long is 64bits and word size/register size is 64bits, code like this:
...
struct {
short s1;
long l1;
short s2;
int i1;
};
The above would be heavily padded
And can be reordered e.g. into:
struct {
short s1, s2;
int i1;
long l1;
};
To avoid that, you need to do your own padding with 0 sized bitfields.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
So, I'd rather pay more for continuously better performance.
He's wrong, as anyone familiar with perl will tell you, but he's also right - the "code" rather than the "English" syntax is more readable once you progress above beginner levels.
Maybe the ternary operator was a mistake though, or maybe a mistake is to chain operations together on one line without some form of delimiting spacing.
not compared to the time of a million users though.
Its just that those creating the programs don't pay for the user's time (unless it gets really bad and a competitor product appears), or the server time for the extra hardware required to handle the complexity.
The thing I note about better programming languages is that they mostly aren't better.
I've occasionally thought "This would be much easier to write in Perl than C."
I've never thought "This would be much easier to write in C++ than C".
Fewer lines of code doesn't mean much.
Thousands of line of assembler, is roughly as hard to write as hundreds of C.
A six line function can often replace a 500 line table.
Copy and paste code instead of using subroutine calls, and you too can be writing 500 lines of code a day.
It isn't significantly harder to write in assembly, that is not why we avoid writing assembly code.
IMO the successor to C won't be a higher level language at all.
It will be a language that gives as low, or even lower level access, but is more portable.
Something that let's me specify endian-ness, or bit rotation, or do atomic operations without the need to invoke a semaphore/system call.
Obviously there's no single right answer, but unless you have a good, specific reason to think Solution A will not be "fast enough" then choosing Solution B for better performance at the expense of slower development is probably a bad idea. With processors as fast as they are today, even on a phone "not very fast" is very often still plenty fast. I do Android development in Java, so I'm using a language / VM with a reputation for being slow on a platform with a processor that is at best not optimized for high performance, and I don't recall ever encountering anything the user had to noticeably wait for other than making network calls to some other system. For a different situation performance could be a much more significant concern and maybe it's worth it.
It's not less readable. Your Pascal is way too verbose, giving you the illusion that just because it sounds like English you actually understand it.
These are not the issues C/C++ programmers are having trouble with, because these are beginner problems.
Yeah, smart pointers...
Except there're not so smart. They're about as smart as first generation garbage collectors which used ref counting, meaning they can't deal with cyclic references.
I'd also ask that "0" be replaced with "false".
I'm so hoping that was a joke.
Not a bit. Using the explicit boolean literal makes the author's intent clearer.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Not built in per-se, though stdbool does provide macros that act in its place if you want to use bool in C.
Frameworks are often a good answer to that... as long as the developer understands the nature of the framework, its limitations, the licensing model, its viability, and thus can assess the consequences of using it.
And that's exactly the problem. More often than not the framework is being touted by a skills-weak 'developer' who DOESN'T understand the nature of the framework, it's limitations, or it's actual applicability. Frameworks are great when they're used properly. The hate against them comes when they're too often seen being used as crutches instead.
Yes and no. I agree that wordy version reminiscent of COBOL or Pascal is bad. Just because English is currently the language of choice for international communication doesn't mean we should accept gratuitous use of it in programming languages. Imagine that in Latin. Still readable?
The key isn't in avoiding symbols
Oh yes it is! Lots of Idiotic Spurious Parentheses? Tell me which format for accessing an element of a multidimensional array is easier to read, [a][b][c] or [a,b,c]? How about XML and HTML, especially properly written markup with every closing tag included?
while(*d++=*s++);
That's antiquated string.h style library crap that doesn't even use the appropriate library function, strcpy(d,s);! Yeah, yeah, it computes the length as it copies, but better to have kept the length which was surely available somewhere somehow beforehand. Did you know that the null terminated string format required to make that work is regarded as one of the biggest mistakes of C? Maybe d and s are not char, but if they are, one byte at a time is a really rotten, slow way to copy a block of memory. Should at the least copy a 32bit word at a time. Or use the memcpy library function, which just might contain a whole lot of optimizations.
Intellectual Property is a monopolistic, selfish, and defective concept. It is "tyranny over the mind of man"
It's a poor craftsman who blames his tools....
Do you have any level of competence in it?
When all you have is a hammer, every problem starts to look like a thumb.
int l (S* s, T** t) { return s ? (t = s->sub, 1) : 0; }
Why are we debating the readability of a ternary operator? Are you all pansy suck-ass python programmers or something? But really:
b = (a==1) ? 0 : !b
Yeah. You are full of it. Constructing a situation without proof, then generalizing to 100 percent.
Let me guess, your paymasters live off the cyber war domain created by C?
That is a lame excuse for the use of C. There are few reasons why rust and swift programs should be much less efficient.
Even java code from capable sw engineers is close to c speed. See language shootout.
Bullshit. Just because the cheapo operating systems you KNOW are all written in C means zilch.
The have been very successful large computer operating systems written in Algol and Pascal. Unisys, icl, HP mpe. Look it up.
Unix is a regression as compared to Algol mainframes.
Msft has singularity OS, written in C#.
C and unix have made computers much less secure than they need to be.
Do you need your diapers changed with that also? Python programmers are so pathetic...
Really? I can read, comprehend and spot mistakes in:
b = (a != 1) ? !b : 0;
A lot faster and easier than:
begin
if a is not equal 1 then set b equal complement of b else set b equal 0
end
Or are you trying to play on the fact you presented an incarnation of a ternary operator that is not common?
I find it hard to believe that anyone with a passing knowledge of the ternary operator would prefer your verbose version.
Never happened. True story.
C++ reduces development time when it achieves in one thread what another language requires complex concurrency to handle.
Sometimes not using C++ causes infrastructural scope creep.
When a small team of C++ programmers knocks it out of the park on a mission critical tight loop, that leaves many other machine resources free to run fat VMs with memory safety guarantees (and any manner of other sissy rails), and to run languages that excel in readability for the benefit of larger, less elite teams.
I'm sure it wouldn't add any infrastructure code at all if Google suddenly needed to add 20% more computer nodes to their typical data center because they had eliminated all their C++ out of some misguided obeisance to training wheel purity.
Any complex expression one retypes for no reason is another potential bug. Especially in C++ where complex lvalue expressions abound.
Furthermore, every nested if statement is another mental simulation, rather than the far more potent algebraic reasoning. However, if you've only got one hammer (mental simulation), then I guess it's right and proper that everything dresses up like a nail.
Just because you like to write contrived code that requires a second look doesn't mean C can't have code that is much easier to read than your "english" version.
if(a! = 1) b = !b else b = 0
When I was 8, I tried Basic, failed miserably at it. So I picked up ASM. Much easier. Actually, ASM was quite natural for me. It mirrored the mental model I had about how I thought CPUs worked. I don't "write code", I tell computers exactly what I want in an unambiguous way.
GC was hacked-on for decades to no avail (in bringing it low-level).But now here it works well (very fast, concurrent).
What changed? The language spec was made very simple.
Compiling was a very tricky, slow business. Now here it's fast and relatively simple.
What changed? A simpler language. Smart people who know which options to take away.
Only painfully low-level languages could work with raw memory pointers. Now we have that in 2 friendly, "default-safe" languages.
What changed? Realization a lot of power comes from low-level operations.
So C & it's layered C++ will break as safer variants with the same power begin to exist.
High level languages depended on dozens of C libraries and libc. Go needs none of those.
What changed? A realization this is important.
A fork of Go now runs without a kernel on bare-metal ARM. That's the right space to grow into a kernel-module-capable language. Languages aren't fast or slow, their implementations are. Go's ease of portage suggests it could show up in the kernel.
Science & open-source build trust from peer review. Learn systems you can trust.
Same for math symbols.
Imagine a mathematical prove in plain english. Well, it is possible, I think Euklid made his proves in plain greek.
Basically everything regarding padding - and even ordering of fields - is implementation dependent and not specified in any standard.
There are two relevant standards: the C language standard and the platform ABI standard. C compilers must comply with both for anything that is intended to interoperate. The platform ABI standard places much stricter requirements on structure layout than the language standard. This is important because the following is allowed in C (from your example):
In one compilation unit subtract a pointer to start of the struct from a pointer to the the l1 field and pass it to a function in another compilation unit.
In another compilation unit, construct a new instance of the same struct, cast the pointer to a char*, add the offset, and then cast it to a pointer to long, and assign to it.
The result of this must be a version of the struct with the l1 field assigned. This is a guarantee of the C language, and the platform ABI standard provides the rules that allow it to work between different compilation units from different compilers (e.g. in different libraries).
Oh, and the C standard actually does place some constraints that prevent the reordering that you describe. If you look at paragraph 6 of section 6.5.2.3, you'll see that, if a two structs start with the same fields then it is permitted to access the fields in either from a union. By induction, this means that struct fields must be ordered from the start, because anywhere else in the program (including other compilation units into which the compiler has no visibility) I can have structs that contained all of the prefixes of your struct (short, short long, short long short) and can declare a union of them and your struct and access the fields through them (and 6.7.2.1 paragraph 15 prevents there from being any padding at the start, so s1 must be at offset 0).
I am TheRaven on Soylent News
Stop talking now. You sound very foolish.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Why nobody mentions such valid and important points as packaging, modularity/reuse and build tooling?
Both C and C++ suck in this regard. Integrating 3rd-party project is usually an exercise in self-control and calm-keeping.
Autotools, CMake, Make, VS Studio, Ninja, Meson, Scons, whatever shit, a new Grand Shiny Build Tool is coming every year as The Only Solution.
No versioning. Everything is manual - binary dependencies, source dependencies, all has to be done manually for every project, with fuckload of weird compiler switches and preprocessor directives.
Most of the modern languages have acceptable solutions for that (I love Rust and crates.io in particular) - not perfect perhaps but working, except for stupid C/C++ legacy shit, and the fucking committee just keeps adding template madness instead of sanitizing it. The C++ compile times are getting bigger with each revision because another fuckton of header files are added.
Or any other big name professionals. There are plenty of others who love working with it. I mean, look at this topic, well over 500 posts already. Doesn't that tell you something? C++ isn't going away any time soon. Neither is plain old C. Those corporations who push for their alternative languages still use C++. And will use it in future. Now if I'm wrong, and indeed, none of their devs write a single line of C++ code in the next 10 years or so, and I mean not a single one...well, then I'll be truly amazed.
I've been using Borland C++ since 1998 now RAD studio, I really think the programming language doesn't matter but what is to be acheived and how fast it can be coded. The results that count. In RAD Studio the possibilities are endless. Now Android, Linux and even iOS support
C++ is a universal language that can express very abstract computing, and has tight speed and size requirements for it resulting code so that it can be used in embedded application, operating and critical systems. One day someone will produce a formally verified C++ compiler (such a C compiler already exists), and it will be a safe language too.
How long have they been working on low latency garbage collection? If they have not developed it after decades of basically static hardware, then it will never exist. Garbage collection will always have lower performance than the alternatives so it is not suitable for low level code.
I agree with ESR that C and C++ are flawed but no modern language has solved those flaws either so I do not care.
In regards to your sample:
If no reason was given, I would quickly demand:
Unless optimized inline, there would be extra work on the stack for the call, but someone unfamiliar with the idiom or the subtleties of operator precedence (or C lacking a dedicated bool type) of the original sample will have trouble. Yes, a veteran C/C++ programmer would recognize it instantly, but for crunch-time, it is not that unusual for a "loaner" to be attached to the project that normally uses a different but similar language, e.g., a skilled Java or C# person that knows what a pointer is. The latter example I provided has a clear purpose. Of course, extra help worth their salt would have the sense to look it up, assuming they aren't on their last drop of liquid motivation while burning the midnight oil.
This is related back to your mention of:
The key isn't in avoiding symbols, which you're supposed to be able to just read if you plan to do any coding at all, but to ensure formatting and sane use of whitespace makes turns a string of symbols into a set of instructions.
I am just adding that it helps to be mindful of having good naming, try to use standard libraries (except for when there is documented good reason not to do so), document when doing something esoteric (when cannot be helped), and keep the "clever" to the obfuscation contests and proof-of-concept snippets.
For the TL;DR, having good conventions (whitespace, naming, library usage, etc), inline documentations (and actual written documentation, please), reasonable communication concerning standards, and clear expectations can allow for C/C++, or most other languages for that matter, to be maintainable even in the largest of projects.
I suppose client stuff is constrained by graphics, but I tend to think in terms of server software - and efficiency means the difference between serving a heap of users and a load of users, the difference can be significant.
Now sure a lot is algorithmic, not language these days, but I find that the "easy" languages are the ones laden down with layers and layers of abstractions which fall into the category of bad algorithm practices.
Besides, the issue shouldn't be "this language is easier than others" as all you do is make it quicker to develop shitty software by untrained people. The experienced developers are just as quick in their favoured language as any, so an old experienced C++ dev with a framework he knows will be no slower than the Java developer with a framework he knows, at that point it starts to be the abstractions that come into play. For example, if I as a c++ dev did some DB access, I'd writ e a sproc and call it via native calls. If I do C# work, I'll use entity framework that adds a massive amount of overhead to every call. The EF version is quicker to type out, but not by such a significant amount, particularly when you consider how long I take to design what the functionality should be in the first place!
efficiency means the difference between serving a heap of users and a load of users, the difference can be significant.
That is true, though you may be able to throw more money at the problem to overcome inefficiency. Buying more hardware may or may not be a good solution.
The experienced developers are just as quick in their favoured language as any
That sounds like a controversial claim. No programming language has any efficiency advantages over any other? I'm not buying that.
Did you mean this shootout where the C (gcc) benchmarks run on average 2x faster than Java?
experienced developers are just as quick with languages they are experienced in. Its not surprising to see a master craftsman bang out something complex with ease.Once you've reached a level of mastery, the time taken is really just down to typing speed - which is irrelevant.
For junior developers, or those (like me who code C# by pressing '.' and seeing what intellisense clues I get next), then language does make a difference, but possibly that too is irrelevant as the time in developing is more about the overall environment and design practices than the actual coding.
experienced developers are just as quick with languages they are experienced in.
Just as quick as what? Some other language that they're also experienced with? I'm still not convinced of your (unsupported) claim just because you repeated it.
as quick as someone else experienced and proficient in a language. The point is that one language is not "better" than another once you're good at it - a C++ dev is just as fast as a Java dev once they're good at their respective languages because they know what they're doing and can produce results very quickly.
Take a while to think about it from the point of view of developer skill rather than language ease.
a C++ dev is just as fast as a Java dev once they're good at their respective languages because they know what they're doing and can produce results very quickly.
Well that's the third time you've claimed that without any supporting evidence, and I'm still not convinced.
Take a while to think about it from the point of view of developer skill rather than language ease.
This isn't a question that can be decided by thinking about it. The only way to tell if it's true is by measuring the output of developers in some way.
Yep, and I'm not going to give any - its easy to demand evidence, troll-like, while offering nothing constructive to a discussion. so tghat's it from me. cya.
Well I can't say I'm surprised by that response, and I think it's telling that you believe asking for evidence to back up a claim is "troll-like".