Slashdot Mirror
ESR Sees Three Viable Alternatives To C (ibiblio.org)
An anonymous reader writes:
After 35 years of programming in C, Eric S. Raymond believes that we're finally seeing viable alternatives to the language. "We went thirty years -- most of my time in the field -- without any plausible C successor, nor any real vision of what a post-C technology platform for systems programming might look like. Now we have two such visions...and there is another."
"I have a friend working on a language he calls 'Cx' which is C with minimal changes for type safety; the goal of his project is explicitly to produce a code lifter that, with minimal human assistance, can pull up legacy C codebases. I won't name him so he doesn't get stuck in a situation where he might be overpromising, but the approach looks sound to me and I'm trying to get him more funding. So, now I can see three plausible paths out of C. Two years ago I couldn't see any. I repeat: this is huge... Go, or Rust, or Cx -- any way you slice it, C's hold is slipping."
Raymond's essay also includes a fascinating look back at the history of programming languages after 1982, when the major complied languages (FORTRAN, Pascal, and COBOL) "were either confined to legacy code, retreated to single-platform fortresses, or simply ran on inertia under increasing pressure from C around the edges of their domains.
"Then it stayed that way for nearly thirty years."
"I have a friend working on a language he calls 'Cx' which is C with minimal changes for type safety; the goal of his project is explicitly to produce a code lifter that, with minimal human assistance, can pull up legacy C codebases. I won't name him so he doesn't get stuck in a situation where he might be overpromising, but the approach looks sound to me and I'm trying to get him more funding. So, now I can see three plausible paths out of C. Two years ago I couldn't see any. I repeat: this is huge... Go, or Rust, or Cx -- any way you slice it, C's hold is slipping."
Raymond's essay also includes a fascinating look back at the history of programming languages after 1982, when the major complied languages (FORTRAN, Pascal, and COBOL) "were either confined to legacy code, retreated to single-platform fortresses, or simply ran on inertia under increasing pressure from C around the edges of their domains.
"Then it stayed that way for nearly thirty years."
...this guy is fucking full of himself.
The entire purpose of this seems to be fundraising. Next week it'll be Java because another friend is working on a Java successor and needs funding...gtfo.
How exactly is it pronounced? Cause I can already see other language designers claiming "Our language is better than Cx!"
Ezekiel 23:20
I wrote a FORTH interpreter in T-SQL, and you don't see me asking for money.
If it's all that and more, call it "D." (or E, because D is already taken.
"National Security is the chief cause of national insecurity." - Celine's First Law
Just because they will be different, funnier and hipster than regular ones.
We are in [current year] for goodness sake!, modernity must be made of fads that beget novelty from novelty's sake.
Also boring, regular hammers and nails have been more or less as they are for millennia for some unknown reason (functionality? familiarity?, experience? previous use cases?, what's that?).
The time to change those old tools is really long overdue.
For as long as we're running Von Neumann architecture machines then C and C++ will continue to dominate anything and everything that needs to be high performance and/or low-level/hardware access.
Because if you don't need C/C++ then you're scripting or whatever much-higher-level language stuff. Languages like Go and Rust fit somewhere in between... no-man's land, where they're doomed to get lost like every single previous attempt at such languages.
The ratio of people to cake is too big
Claiming "I have a friend....trust me on this" instills so much trust, doesn't it?
Static code analysis and runtime checking (valgrind) pretty makes C's little issues a non-event now.
And that lack of type safety is actually needed in some domains, so solving it makes it harder to write say kernel code.
The only problems I've seen with C in the last fifteen years are when the ****ing C++ zealots get control of the C compiler and have managed to break C in the process ;)
ESR is a bullshit artist. Maybe he can code, I don't know. But he is definitely a bullshit artist and he has been involved in some underhanded stuff like his hijacking of the money assigned to an NTP security project. I wouldn't give his opinion much weight at all.
I'm hopeful that JAI goes mainstream :)
Help! help!, the termites are eating my DRAM!!!
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.
C# has native AOT compilers that can target low level architecture. I wish the COSMOS operating system and its tool sets were adopted more by Visual Studio and Microsoft. With these tools you can easily write code that targets native hardware.
https://github.com/CosmosOS/Cosmos
Valgrind drastically reduces the performance of the software, so isn't practical for critical code that needs to execute quickly.
Courtesy of Lennart Poetering
> 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...
OP means running Valgrind on test suites, I hope. Nobody runs Valgrind in production.
What I want from a programming language are Standard, Stability and Speed. Nobody minds the little quirks, redundancies or the lack of elegance. When I program something today, I want it to run in 10 years, without modifications! In particular, I want the language to be around still, the grammar once put stay a standard. I want the program to run stably. In particular, I expect developers to be very careful when changing the compiler. Even small changes annoy. An example in C (which is in general quite good in respect to stability) it was no more possible to run gcc -lm example.c . Linking the math library required gcc example.c -lm. One has to change now 700 Makefiles just because somebody thought this is more elegant? I don't mind if a language is extended or sped up, but don't for change old grammar, not even the smallest things. There is lot of code around which would need to be fixed. I'm in particular careful with new languages. They first hype and spike. A language needs to earn respect, prove that it is stable over a long period of time.
All the alternatives to C he proposes are just horrible.
That is the problem usually. All these so called "replacements" suck in a different way. This is why C is here to stay.
You mean world history?
White people invented all the shit everyone else appropriates for granted.
Fuck off.
China, India & the Middle East were doing great stuff long before Europe
Pain is merely failure leaving the body
You seem to be under the impression that valgrind is for production use.
Go and Rust both come with large runtimes, all their associated risks, and low performance. They're not competitive with C in the embedded or operating systems fields. Anyone who has written hello world has noticed this. ESR isn't a programmer anymore, he's a pundit reading press releases.
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.
Feel free to contribute the numbers for all gun violence in the US and the references for said numbers.
Probably you'll be surprised.
They've even been caught suppressing firewall alerts.
Could you accomplish what you ask for by coming out with a native-code version of Java? Maybe ditch the GC and replace it with best-practice non-GC memory management "smart pointers"?
Back when Sun Microsystems was the fiercely protective parent of Java, such a thing wouldn't be Java and they would sue your backside if you tried to call it Java.
But are not Rust, Go, and Swift essentially native-code versions of Java? If not rigorously adhering to Java, are they not attempts to ditch the preprocessor, provide a module system and namespaces, properly define behavior and improve safety, in a native-code setting?
They are native code, because if they are managed code, what is the point of not using Java, or if you want a different language, at least adapting it to the JVM (cough, C#, cough)?
Seems like it's the white guys with guns causing most of the trouble lately. Maybe that's a conversation we should have.
Mod parent down. Off Topic.
The Russians have won. They have made the world a cesspool of distrust, greed, fear and hate.
If it can't target something as small as ATtiny25, it's not an alternative to C.
#DeleteFacebook
Exactly. Today it is smelly shitty fucking ugly hindu-chimps leeching off of america.
Exterminate these parasites.
Mod parent way, way down. Poster too busy with all the people living rent-free in his head.
The Russians have won. They have made the world a cesspool of distrust, greed, fear and hate.
No, CD is successor to cassette tape.
#DeleteFacebook
Hork!
Well written C# and Java is actually more efficient than C/++.
LOL. Poor trolling is poor. Outside of some ridiculous microoptimization benchmark (like a C#/Java can run this for loop that makes this single method call faster!!), please do post your proof.
Partially because it can do whole of program optimization.
PGO has existed for C++ for years now.
Partially because it can optimize for a particular processor rather than a generic one at a separate compile time.
So can any C or C++ compiler.
Partly because garbage collections minimizes the need to copy data structures (particularly in C++), and smart pointers are grossly inefficient compared to generational garbage collection.
[citation needed]
Partially because it allows focus on algorithms rather than fixing nasty bugs.
Because no one has to fix nasty bugs in Java code. As long as you ignore things like Apache Struts, right?
strict no waning policy. Problem fixed.
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.
Srsly? Starting at 0 is natural and ideal. For a programmer, of course. You know, the sort of person you claim to be.
Starting at 1 causes all the off by one errors. Starting at 0 is the cure.
Rather than seeing an industry trying to fix its mistakes, I see one constantly reaffirming them in a bizarrely self-defeating manner, all under the auspices of "business needs" or "knowing better" through some brazen assertion that having coded in a mediocre language for 30 years showed us that it's foolhardy to aim higher... just leave that to the dreamers and fools we can comfortably dismiss while we continue making mediocre products.
ESR has fallen into this exact trap, and it's incredibly sad to see people pay him any credibility on topics like this beyond healthy respect for one's predecessors. We have become the fossils, and we're holding back the future of that which we're about to leave behind, just as our predecessors did, etc. It's humbling to be a part of this and know that no matter how hard we fight, the best we can come up with is the likes of Go or Cx, and general mockery for anything beyond the most minimal progression of the status quo (Rust has clearly been tossed on his list simply as a diplomatic and defensive gesture, given how little he has reached out to truly do anything about this general problem space over two damn years, despite his apparent concern over it).
A waste of a career, Bruce. A waste.
What's the commonality between them: they all have to revert back to plain C to get any performance out.
Python: Every performance library is written in C, not compiled to C, written in C.
Go: "Import C" and cgo are practically a pre-requisite for any complex program
Rust: The majority of the community is asking for or have hacked in a bridge into C
Cx: Dead as a project but many have come before implementing checks into C, the majority has failed because if you wanted the checks, you wouldn't have used C in the first place.
Custom electronics and digital signage for your business: www.evcircuits.com
Partially because it allows focus on algorithms rather than fixing nasty bugs
Anyone who has done any real world programming would call this guy a dirty liar. Almost all programs have bugs. Not because the language allows them but because we are lazy, tired, or just misguided. A SQL injection attack is just as likely to be made in C as it is in C# or Java. You could argue it is more difficult in C as you have to go out of your way to make it happen incorrectly. Where as there are many examples of doing it wrong in javascript/java/python laying around on the web. The only bug that the higher level languages helps protect against is buffer overflows or under runs. Even then that is not always true.
Our memory issues stem from the fact that we sit upon a hardware architecture that allows it. I would argue even encourages it.
The only reason these days I favor python over C/C++ is the ease of quick prototyping is just not there in C anymore for me. I can stand up a python program in a few mins. In C/C++ it takes longer but I get more power. As the project progresses the C/C++ library methods become faster to noodle out and build with. Where as python quickly falls in upon itself and you have to bend it to do things it is not really meant to do to make the thing work as a project. But with great power comes great responsibility. Valgrind and lint are your besties...
And...
Indexing and counting are not the same thing. Thus, there's no way to escape off-by-one errors; there will always be both indexing and counting.
(1) Undefined behavior. UB is completely unacceptable in 2017
You'll be sad to find out that your favorite language has undefined behavior as well, unless your favorite language is ML. It's just not worth the effort to fully define the language.
"First they came for the slanderers and i said nothing."
Spoken like a "programmer" who's never written anything of significant size. Just because your idea of programming is to go suck on some bloated framework (and suffer the irreducible slings and arrows that result), that doesn't mean there aren't real application programmers doing real work out there.
Coding is the very heart and soul of programming, at least until machines take the job over. Anyone who doesn't think so is an outright fool.
You can have stupid security issues in the strongest typed languages. That's a wash.
Unless I've totally misunderstood the article, why isn't he telling people to move their projects from C to C++? Isn't the basic concept a better C, with give or take no surprises recompiling your C with a C++ compiler, and trickling in new language features which are applicable to your code base?
Of course, he could be lumping C and C++ together into one bucket, which to be honest, I tend to do but coming at it from the other direction (assuming you mean C++ when you say C). However, his mentions of what is wrong with C make me suspect he isn't. It's a bit of a major omission from the discussion if he isn't...
Now personally I rather like C++ as i'm writing realtime software, both soft and hard, and so I need to worry about and control memory allocation. False sharing is a concern, performance is critical (there's no upper limit to the required throughput, faster is always better for this code base). Until someone can offer an alternative, i'll be sticking to C++.
We don't need, want or deserve something safer, more elegant, less terse to avoid constant interpretation or near ambiguity. Briar rabbits wait for a prepared set of arguments to knock over.
Remember, we won't be able to join the Galactic Federation until we.
1. Get rid of nukes.
2. Stop destroying our own environment.
3. Enjoy world peace (yes, you also have to enjoy it).
4. Stop oppression and supremacy.
5. Find a replacement for C.
Building a warp core might also help.
Anyone else read this as 'ESR Sees Three Vitamin Alternatives to C?' Was thinking it was awhile since they invented a new vitamin, how disappointed I am that we still only have B, C, D, and uh some other ones that I can't remember.
You're scare-mongering. At least, you're trying.
"First they came for the slanderers and i said nothing."
As someone who writes a ton of C# and C++... no. C# might be fast enough, and things trivially transcribed can be faster due to default implementations, but, C++ will literally always win in the end. It might take two or three times longer to write the C++, but it will win. That's kind of the reason C++ still exists: if you need to, you can make it fast. For everything else there's [insert high-level language here]. Because things like C# only let you go so far with optimization, and then C++ lets you go ten steps further.
The promise of "the JIT will just make it all faster in the end" is an old one that has been made for decades by JITed languages. The promise has never been fulfilled -- it's pie in the sky marketing fluff.
GC is good for certain highly scalable lock-free algorithms, though. I'll give it that. Not much else.
Tab or space freedom
Isn't that the apropos analogy? Let's do something as simple as keeping English the same, except for making its spelling phonetical. Any takers? An argument can be made that putting the current and "improved" version of English side-by-side, the phonetic version makes more sense.
Inertia, legacy, and culture are as much a part of C as the BNF diagrams are.
There are no flaws in C that cant be fixed by becoming a better programmer.
As the C++ compiler compiles most C just fine, I have a hard time believing that you canâ(TM)t make C++ as efficient as C.
To be honest, I think it is an âoeurban mythâ, that C is faster and more efficient than C++ - just disable exceptions support in the compiler (it is useless anyway).
Of course, when writing C++, you can easily end up with code not as memory efficient due to STL and templates, if you use then without thinking.
I for instance, made an automatic serializer with templates at a former job: it ended up using 1.5Mb in typeinfo - was the platform had 16Mb RAM in total.
Solution: compile without runtime type info and exception support and remove a lot of memory and runtime overhead.
C/C++ directly, logically, objectively follows from assembly language.
Until the fundamentals of computer systems are changed, C/C++ is here to stay. FOREVER.
Anyone who disagrees has fallen in with charlatans who are trying to carve out their piece of the pie by making maladapted tools for people who have no business programming anything to begin with. We don't need to market engineering to incompetents. In fact we need to NOT do that.
Sure you have specialized languages for specialized tasks....but systems run on C/C++.
The end.
Although C was the first language I properly learned and I have extensive experience in quite a few C-based programming languages, I haven't used plain C much until since about 4 months. I relied on it for a reasonably complex and big development (although R&D, no-time-pressure one) and, as a way to compensate the numerous differences between C and the languages which I use on a regular basis, I created a set of methods to somehow emulate the modern-language conditions and simplify the pointers/memory allocation aspects (note that this piece of software is mostly dealing with string variables of any size). After some struggling, I have been able to come up with a light and reliable methodology allowing me to not worry about all the memory problems in C. I guess that experienced enough programmers are comfortable with their own approaches and that's why my question is for kind-of-newbie ones: will you, C-newcomer, appreciate a small library (+ clearly defined methodology to use those methods) allowing you to easily and safely deal with strings (arrays too if you wish) of any size (via malloc)?
The aforementioned set of methods have been an unintended consequence of my adaptation from modern programming languages to C. I have got so used to these approaches that I will certainly rely on them for future C developments. In any case, I am completely aware about my relatively short experience in this language and the problems which the users face at the start; and I don't want to release a new library promising a solution for either a non-existent or solved-many-times-before problem. So, any developer having problems with these C aspects care to share his/her thoughts?
Custom Solvers 2.0 = Alvaro Carballo Garcia = varocarbas.
I think a "new c" might look a lot like Go - without the handicap of garbage collection.
There hasn't been a garbage collector written yet that doesn't constitute an outright insult to performance and predictability.
I've fallen off your lawn, and I can't get up.
Nothing else quite does what C does. It has no real competition (except maybe C++) in its niche.
What you must recognize is that application programming is NOT C's niche.
That just means you could be better at c. Because there is nothing you can't write in c; c gives you absolute control of everything. The questions are:
o Do you have the time?
o Do you have the skill?
Most people aren't willing to say yes to the first, and most people can't honestly say yes to the second (and that's given us a lot of very bad c code. But it's not c that's the problem. It's the raft of so-so and worse programmers that have built things in it.)
I've fallen off your lawn, and I can't get up.
Just kidding. It's more than three. I mean, ESR is a reimagining of RMS in a more modern manner, just without everything that would actually be important.
Yeah, but better languages eliminate whole classes of security bugs that plague C programs, including the bugs that hit dnsmasq.
This is one of the lamest defense of C: "You can't prevent all bugs, so why bother trying to prevent any".
The answer is here: https://bugs.chromium.org/p/ch...
BTW. Probably the most evil thing that C has inflicted upon the world is counting from 0. All pre C languages count from 1, as do children. And then it all changed. And we will live with off by one errors for the rest of time.
Can I just leave this here?. I feel like I need to leave this here for you to read.
Yaz
I don't consider myself to be a programmer by profession, although I have been in the past, with experience spanning quite a range of different language types, including COBOL (74 & 85), FORTRAN 77, BASIC, JAVA, PHP, Visual BASIC (up to 5.0), VBA and Assembler (several different CPUs).
... and, if there are, are they acceptable?
When I started to learn programming languages at high school, the number available was relatively small (compared with today) and the differences between them relatively significant. Each language was specifically designed to solve a reasonably well defined set of problems. If you were working mainly with mathematical problems such as with physics or engineering, you'd use FORTAN. If you were developing applications for business, you'd use COBOL.
Look again at the syntax and structure of these languages and their origins, architecture and design are clear.
I am very (very!) sorry to all those professionals currently working in the field of programming language design if what follows is offensive, but we seemed to have entered an age in which a "fantastic" or "revolutionary" new language is released every few months. The better ones then follow the Gartner Hype Cycle before drifting back into obscurity. The mediocre ones never seem to make it even close to widespread adoption...
We now seem to have reached a point where, instead of designing and developing a programming language to solve a specific business, scientific or technical problem, language designers are simply stealing primitives and ideas from existing languages and throwing them together into a framework before declaring their solution to be "The Next Big Thing (TM)". Of course this is a generalisation - every now and then we see some really remarkable innovation happening in the language space. JAVA for example, with it's aim of "write once, run anywhere" and it's much improved memory handling, would be a valid example.
But in my ignorance I can't help but look at the current state of programming languages and think that too much of what we see today is just different, not necessarily better. Perhaps the most egregious mistake I see us making, as an industry, is that we're losing sight of the fact that programming languages should be designed to be easy. Remember the relevant portion of ESR's own "Art of Unix Programming", the Rule of Representation, which says, "Fold knowledge into data, so program logic can be stupid and robust."
Do we see modern languages with the data handling sophistication of COBOL, for example? No. That's acceptable if the new language has a well-defined set of design goals that don't include data handling, but if not, I think we need to think very carefully about that old maxim, "all progress is change, but not all change is progress"...
So whilst I'm always interested in learning about developments in programming language design, I think it helps if we ask a few fundamental questions of a new language:-
1. What are the specific goals and design requirements of this language? How well does it meet them? Are there any compromises made in doing so
2. Of all existing programming languages that exist today, which one or ones are closes to this new offering in terms of goals and design requirements? Having identified the competition, what are the features and key differentiators of this new language that make the existing language obsolete? Are we certain (for example), that before embarking on an all-new language, that it is impossible to extend the legacy competition with new language primitives?
3. Given that all design decisions are in fact compromises by another name, what is/are the impact(s) of the design decisions taken that differentiate this new language from the competition? [If these yield benefits, then wonderful; if they bring costs, then are we willing to accept them?]
4. What is the learning curve like? Does the new language include weaknesses that yield to commo
After reading some of the comments in this thread, I went ahead and recorded a small video comparing the performance of various languages (C, Java, C#, PHP and Python) in a simple while loop. The results are simply unarguable. You can (dis)like C (or any other language) and use it or not; it might even not be recommendable under quite a few conditions. But, at least, be aware (or/and honest) regarding what it can do better than any other language. Here you have the video and, please, bear in mind that my talking-to-camera skills are quite bad :)
Custom Solvers 2.0 = Alvaro Carballo Garcia = varocarbas.
Jonathan Blow's jai is the only promising c replacement I've seen.
Kotlin Native is also a very interesting option
So memory guards and other clever debugging mechanisms are not a good idea for code that needs to run quickly? Any new language out there that is built on that idea, or do I just keep using the COMMON and EQUIVALENCE statements?
an alternative, so says the late great Edwin Newman. It can be an impractical, inelegant, unethical or fattening alternative, however.
Meanwhile, we might have had a viable alternative to ESR, but what we got back from the transporter didn't live very long.
Because if guns didn't exist they'd have to use crossbows to deal with crossbow-armed robbers?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Except that's bollocks, and Samuel Clemens never invented anything, so what would he know about it? All of those things were major leaps, and the first man to make the major leap got the credit in most cases.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
My irony meter just exploded :(
Samuel Clemens never invented anything
Wrong. He received three patents for three inventions.
so what would he know about it?
More than you.
When the C++ complains that parameter 1 of a method has an inconsistent type, which one is it talking about? The 1st or the 2nd? Example of confusion.
Have you ever measured it?
I have.
The idea of Cx sounds very similar to the C0 project at Carnegie Mellon University. See
http://c0.typesafety.net
A filthy muslim invented the camshaft which converts rotational force (engine) into linear motion (like driving your car to a different place), which makes an even earlier invention (the wheel) much more useful. Unfortunately this includes American hot-rods and muscle cars. Each of them conceals a filthy muslim idea deep inside, which enables them to be totally badass -- instead of just a rumbling, gay piece of shit couch on wheels.
Food for thought.
https://dlang.org/
ESR is a fat, mentally-retarded homosexual
These sorts of pronouncements are made every decade or so. Gee, what is it about C that makes it so popular as a low-level alternative to assembly?
Why does everyone mention these two together? Rust has no GC and is faster than C++ in most benchmarks, and GO has tiny pause but low overall speed GC and is slower than java in most benchmarks. Benchmarks aren't real software but they do show trends. GO has trouble with memory allocation performance for instance. Rust's problems are mostly ergonomic (and nontrivial), performance and undefined behavior they have down. They are completely different languages for completely different uses.
refactor the law, its bloated, confusing and unmaintainable.
Except that's a strawman, nobody uses that argument. The analogy is that C is a razor sharp katana. You can hurt or kill yourself if you don't know what you are doing, and have not trained to use it correctly; yet it is far superior to go into battle with than, say, a pair of safety scissors. There are people out there that advocate safety scissors and say we should all be using them, but for going into battle they suck.
Any developer worth his salt should be very, very wary of any tool or app that comes from google; they have a nasty habit of providing things that eventually disappear.
Circle the wagons and fire inward. Entropy increases without bounds.
is still around and used
Not until they create Visual Go# and add it to the Mono project.
Thanks for the tip on the Julia language for numerical work.
A proposal came up in committee for an Engineering course emphasizing numerical programming. Julia was in the list of languages along with Matlab and maybe one other that the instructor proposed to approve for student projects. I didn't question that because we give a course proposer latitude in that sort of thing, but I wondered whether that was an odd personal preference by that instructor. One comment below suggests that Java is an odd personal preference on my part, but we actually have an introductory programming class taught in Java "on the books."
I now know that Julia is a language other people are adopting for that use.
Actually, the language that C is derived from is BCPL. BCPL begat B, B begat C, and C begat C++.
If we were to follow this orderly procession, the next logical step is to program in P. I, for one, am looking forward to programming in P.
Yeah, that's the same technique I use with my girlfriends! Condoms aren't 100% effective at prefenting pregnancy and STDs, so I don't need to use them.
dom
Youtube, Netflix, and SuperTVstreamer.com.
One of these is different than the others. ...
A standard Cx language introduction would get less coverage than a fake/presumptuous comparison.
Nice try... it worked, I looked up Cx. But no interest until wider adoption.
'Go' has traction. Node has traction.
'Rust' has none. assumed dead.
Cx needs some users/code before anyone would put it on a list.
This is what I find.
http://benchmarksgame.alioth.d...
refactor the law, its bloated, confusing and unmaintainable.
C persists because its designers decided to invent a language to express how the world actually is, rather than how faddish humans would like that world to be (in particular, even LISP doesn't entirely pass this test, because—like it or lump it—real computers are state machines).
C is not perfectly fine, though it's perhaps the adequate and (mostly) comfortable marriage we've long had, warts and all.
ESR, I've slowly learned, is generally full of shit. Long ago I was fooled by his giant, noisy he's-one-of-us hat. But over time I came to perceive that he is primarily a noisy propagandist, who almost always wades into a debate to noisily send it down the river in the wrong initial direction.
Here he builds his entire case around the dangerous word "replacement", invoking the metaphorical reasoning processes associated with small, painstakingly divisible pies. What he is simultaneously hiding behind his back is the glove metaphor: that every language has a natural application domain where it excels for some people, at least some of the time (or it will soon wither and die).
What's he's trying to argue is that some other languages now exist that don't instantly disqualify themselves (due to stupid, faddish design decisions) from potentially becoming the next hegemonic ecosystem for all things systems programming-ish (C would remain the size of India for decades to come, even if China ultimately asserts itself as the new, "uncontested" superpower).
[*] Hegemonic thinking and the human predilection for fads are fused together at the hip bone.
He also means that within the next five to ten years, C might develop and increasingly strong legacy body odor (as if your grandfather's shaving cream didn't already have such a smell).
The legacy smell of C is that of a hearty pioneer, after many decades of a life well lived, who ain't dead yet, not by a long shot.
Stewart Brand: Good Old Stuff Sucks (2008)
Brand is a kinder, gentler, less rhetorically clueless ESR, and here he gives us a third metaphor: C as wood. Many an aspiring bullshitter has announced to the world this or that "wood replacement". For a long time, most of those wood "replacements" sucked. That was Brand's middle phase.
Now for many purposes (e.g. window frames, etc. etc. etc.) we have wood replacements that don't suck.
Roll the presses! Wood considered passe.
The thing is, humanity has never really needed a wood replacement. Wood is pretty good at many things. We've been using wood for a long time. I mean—crikey!—Jesus once listed carpentry on his brief CV. But that doesn't mean we shouldn't continue to pursue other materials or not find other great ways to build stuff.
It does mean, however, that wood considered passe is typical ESR weak sauce.
I'm an old timer. I learned how to program on punch cards. That being said, I consider myself "current." I follow the trends, I look at the language fads. Try new things, etc. Pure and simple: the reason why "C" is what it is because it is a simple language who's constructs can be implemented natively on almost all computer hardware. No matter what comes next, if it can't do that, it can't replace C.
That last attempt at improving C was C++. Sadly, C++ fell victim to what is going to kill any presumptive "C" replacement. The language wonks are idiots. Where computer languages work (IMHO) is where they allow better organization of code, i.e. structures, classes, functions, libraries of functions, etc. in the way computers work. Structures are a grouping of variables, classes are nothing more an enforcement of a naming policy. Where they fail, IMHO, is when they try to create meta constructs that aren't really based on the underlying hardware. Take for instance "lambda functions" there is no such thing in the computer hardware.. Dump out the assembly, its just a function. It serves no purpose other than to make some language wonk happy. It doesn't make the code more readable, doesn't make it more efficient, its just there to be cool. I'm old enough to realize that "being cool" sucks.
So, getting back to my point. C is a truly functional language. It doesn't have the fashionable affectations that language wonks like, and that's why it will remain supreme in OS development.
Also, it may not matter but many of those benchmarks where c and c++ win, like n-body, platform specific intrinsics are used. Rust is the fastest platform independent solution for n-body. I expect it to get even faster once they incorporate an llvm with newgvn enabled. The clear partitioning of speed is c,c++,rust, and then everything else. They stand alone of the languages in the benchmark game. If I were to take a step down to java speeds go would definetly be in the running along with swift and c#, but those are the languages I would compare go to, not systems languages that make absolutely no compromises to ease of use.
refactor the law, its bloated, confusing and unmaintainable.
Are we just going to pretend it doesn't exist now?
"Well written C# and Java is actually more efficient than C/++."
Provably false.
First problem: Define "efficient."
Second problem: You do know that java is written in C. Think about that for a moment.
Third problem: Are you including the virtual machine in that assessment?
" Probably the most evil thing that C has inflicted upon the world is counting from 0"
Yes, because roman numerals work so well in math.
The fencepost error you are talking about was hardly invented with C. It existed in assembly, which C largely imitated, and for high level languages, I seem to recall that Basic had 0-based arrays as well, which itself was invented over half a decade before C.
File under 'M' for 'Manic ranting'
The language wars is a team sport. Following the death of objectivity all we are left with is the exhortations and hand wringing from the inexperienced and uninformed looking for a new toy to love. A common behavior from those with a primary need for affiliation [1]. Ok everyone, dicks on the table. Let's see who's got what it takes.
The truly experienced do not participate in the language wars. They get their jobs done and enjoy the fruits thereof.
[1] - https://en.wikipedia.org/wiki/Need_theory
I'd argue that the Nim language is another modern alternative to C.
Yeah, but they were all like "... via the electric telegraph".
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Perf is very important to me, so yes I've measured. You've reached a flawed conclusion from whatever you measured.
When I started writing C#, coming from C++ it would drive me nuts seeing all the blatantly wasted instructions, memory bloat, indirection, and extreme lack of locality that .NET has. It relies very heavily on the CPU's branch target prediction and cache to be reasonably fast, which has the effect of your "hot path" needing to be smaller in C# than it needs to be in C++.
It's been a decade since I started using C# and it still occasionally drives me nuts when I'm trying to write fast code. I do like C# for a number of its features, but performance is not one of them -- it is merely adequately fast for what I use it for.
When you have mod points you can spend them. Otherwise shut the fuck up.
I thought the wheels did that.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Hey look, Eric S. Retard discovered a new programming language. But he can't tell us anything about it because it's a secret known only to him. This is the girlfriend from Canada all over again.
Okay, so in your mind, the engine is attached directly to the wheels, without any intervening bits, like axles or crankshaft. And the up-down motion of pistons firing just magically makes them turn in a circle.
Assume for a moment that the creators of languages such as Python and Go indeed know something about programming languages. We can observe that python itself is written in C. "Use Python, not C", they say, but that's impossible because /use/bin/python IS a C program. Their "Python program" is nothing more or less than input for a C program that actually does the work. That actually is a good approach in many cases. One need not be a educated professional software engineer to write list.sort() ; one should, however, recognize that what that means is "ask the C program to sort it for me, using whatever algorithm the C programmer chose for me, because I don't know".
https://github.com/python/cpyt...
Rust was originally written in C, then a Rust compiler was written in C++. If the creators of Rust know about what makes a good programming language, and they chose to write Rust in C ...
Now most recently they have the front half of a Rust compiler written in Rust.
Sprintf and strcpy, really? Stuff that's been deprecated in all major compilers for over a decade? strNcpy was introduced in 1978 or 1979 - it predates even the standard IO library. So with strcpy you're talking about a function that was replaced almost 40 years ago. snprintf was officially standardized in 1997, after having been in use before that. So more than 20 years ago.
> I could go on and on.
Yeah why don't you go on to compare 10, 20, or 30 year old Rust and Go, since you're talking about how C was used in the 1970s and 1980s. Oh wait, the version of Go and Rust used 10 years ago couldn't even implement "hello world". I'd say a language that exists is a hell of a lot more useful than one that doesn't, so even if you insist on arguing about 1980s programming practices, C is still inarguably better, in absolute sense.
Would you like to compare modern C practice to modern practice in some other language? Because if you want to talk about 1980s C, the obvious comparison is 1980s Rust, and obviously C wins, by being used to write software such as Unix, while 1980s Rust or Python couldn't be used to write "hello world".
If you'd like to see some modern C, to get an idea on how it's used today vs in the eighties, you can look at the source code for Python or Ruby. These language author's, like most, we're smart enough to write their interpreters / compilers in C.
New language to replace C! Looks and works just like C.
More at eleven.
How can the engine be attached via the crankshaft when the crankshaft is part of the engine? Do you even have a clue what you're talking about?
And the up-down motion of pistons firing just magically makes them turn in a circle.
I'll tell you what doesn't do that - the camshaft, which was the original claim. No wait, the claim was that it converts rotation into propulsion, which is utter fucking rubbish.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Rust was originally written in C, then a Rust compiler was written in C++. If the creators of Rust know about what makes a good programming language, and they chose to write Rust in C ...
The original Rust compiler was written in OCaml. There was never an official C or C++ version of the front end. The backend of the self-hosted compiler is LLVM, written in C++.
Now most recently they have the front half of a Rust compiler written in Rust.
Rust has been self-hosting since about 2011, which is not "most recently" in my book. There is an independent front end written in C++, which generates LLVM IR and still needs the LLVM backend. It is also incomplete, since it lacks the borrow checker.
Or maybe... cysts.
Here's the problem. Hard real time embedded code needs to run fast IN TEST MODE.
No, I'm not anti valgrind. I'm just saying it's doesn't fix everything.
The fact that they even have a Code of Conduct is a big red flag. When you sign up with a company and they make you sing a big long thing about sexual harassment, doesn't that always turn out to be an awful company to work for?
I'd be all for Rust if they were all for freedom and prioritized solving technical problems. But with time, you learn to distrust anyone who doesn't make solving technical problems a top priority. Even if you agree with their values on other things. These people just don't know how to keep it real.
You can't work productively with others if you can't agree to disagree. Especially on matters unrelated to programming.
Grownups don't need a code of conduct. Codes of conduct are for children. Never try to work with someone who thinks of you as a child.
I'll tell you what doesn't do that
Yeah I'll tell you what doesn't do that: the wheels. The wheels don't do that... which is what "you thought"... Do you even have a clue what you're talking about?
that can undo all the damage done by all the lesser programmers out there.
And the general sentiment that C or C++ is good enough if you program them right flies in the face of reality. Yeah they can be programmed right but rarely are. Rust for example shuts down classes of programming error from even happening.
poobah says its time for you to do self pleasuring, go away from the screeny
Can you enumerate some of that 'great stuff' China, India & the Middle East were doing which helped in a measurable way the civilization to reach the point where it is now?!
ICE CREAM, the Chinese invented ICE CREAM nom nom nom
You do not get weird memory corruption bugs in .Net/Java. The sort that produce strange effects long after the bad code runs. Buffer overflows, accessing freed memory etc.
You do still get threading errors, which is another issue. But one nasty class of bugs is gone. Every time you read about a buffer overflow security violation think that that would never happen if they had not used C.
Traditional basic counted from 1, just like Fortran. Later ones let you define both the upper and lower bounds. It was fairly late, post C, that the default lower bound moved to 0. Strings always count from 0, so instr can return 0 if not found.
And the 0 lower bound in visual basic is an absolute pain. Excel, for example, counts from 1. So when you copy some cells into an array, where do they end up?
This is C pollution.
http://www.dictionary.com/brow...
This guy is a complete joke. I'm not sure why anyone keeps reposting anything he says.
He's contributed nothing to this community but hard feelings
Nobody is going to shift the enormous capital invested in tools and optimizations geared towards C++ - in the development of the language itself - and of the innumerable codebases using this language. Nothing will ever offer all that C++ does in this regard. It has never been and will never be, a case of the best language winning - the most widely supported language, with the most capital invested in it, will always be the one that wins - and C++ just has that level of unsinkable critical mass, that will not be shifted in our lifetimes.
I did not mean to suggest I was sure about the thing with Basic... the point about assembly remains, however. 0 based arrays make sense if you think of the array index as an offset, in units of the underlying data type, from the beginning of the array instead of an absolute position. This is, particularly coming from an assembly programmers point of view, a very intuitive concept
File under 'M' for 'Manic ranting'
Name as in C/C+/C++ or C/++C/C++. It should be superset of C, with addition to C ..aka ++C but OOP removed from C++?
Ideas are a dime a dozen. Getting people to use a new idea is the hard part.
The problem with a "successor" to C (whatever that means) is not that such languages don't exist. It's that developers need to work in a community. Every part of the community has different needs, so what this guy comes up with won't work for a wide spectrum of developers. This means that many others have to buy in, provide components, provide hardware support, etc.
The language has never been the problem with finding programming language nirvana. The problem is adoption.
What actual, important contributions to *any* project has ESR made? He seems like a perpetual hanger-on who occasionally inserts himself into conversations on mailing lists to start flame wars. (a racist, sexist, misogynist hanger-on at that)
I don't think pascal was ever popular - apart from schools. It wasn't something you'd use in the real world
China, India & the Middle East were doing great stuff long before Europe
Then succumbed to religious extremism and became shitholes.
Plenty of religious extremism, of the Xtian kind, in the great old USA.
Pain is merely failure leaving the body
If you lift the wheels off the ground, or interfere with their contact (say by putting oil or ice on top of the road) it tends not to move so well. So yes they are what converts rotation into propulsion. Stop lying.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
When those debugging techniques prevent the code from properly responding to hardware interrupts in time, to the extent that the code locks up and doesn't operate at all, yes.
30 years of programming in C makes you unable to count to three?
"Now we have two such visions...and there is another."
Umm, two plus one equals three...
The wheel maximizes the efficiency for a specific application of force. Ironically, what it does best is minimize the friction. You have jumbled concepts of wheel vs tire & conversion vs traction. The conversion between linear and rotational force is done by camshafts & crankshafts. Both items were invented by a muslim. Learn to read.
1 is a feature, not a bug. Undefined behavior gives the compiler room to optimize certain kinds of problems. You would know this if you actually wrote C++ for a living.
I guess his writings are "truthy", but I'm going to be honest, anyone who even bothers to call out a broad replacement to C is pretty much delusional. It will continue to take a smaller percentage of things, due to overall growth in the field, but said growth will probably continue to increase the absolute number of C programmers.
"D", of course.
http://dlang.org/
'Nobody ever writes anything original, they just regurgitate the same thoughts they read...'
Mark Twain was likely just taking a piss on Edison, his associate/friend.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
Lifter pegs are _much_ older than that. First invented by the Chinese, but independently reinvented many times.
The connecting rod/crankshaft is the most basic rotational to linear motion mechanism. First used with animals for power.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
Crankshafts existed long before the Mohamed was born. So did peg lifters. Try again.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
If anything replaces C, it'll probably be Python - The Visual Basic of modern times!
Computers are now so powerful nobody can be bothered to write programs properly any more - It's all about getting it done fast rather than doing it right - Everything is about rapid development; Optimization takes much longer than laying down the bulk of the code quickly - It's probably the second most time consuming thing after debugging - and the people in charge don't have any pride in the work like the small programming teams would have in 'the old days' - so they don't give any time for it.
This is partly why it takes my Windows 10 machine just as long to boot and login as my Windows 95 machine despite the machine's processing and I/O being several orders of magnitude faster.
This is one of the more gratifying things about Linux - Every time I buy a faster machine and move my Gentoo over to it, it shows dramatic increases in performance, but when I upgrade it to a new kernel or update the WM or whatever I don't get the associated slowdown (Althoughv I also don't use KDE or Gnome so that might help :P)
Correction. Stirngs always count from 1, not 0. Oops.
Code is invalid. Therefore doesn't compile.
Much better than it running and doing something unexpected, like you'd get in a scripting language (JS)