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.
Use Windows, pay your bills with a credit card, and pull your head out of your ass.
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.
Not saying it is, but at some point we're going to need to have the conversation.
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 ;)
There are now three search engines that are viable contenders to Google: DuckDuckGo, Bing, and WayCoolSearch.io, the latter which is an awesome technological tour de force that "my friend" is developing.
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.
Better to stay the way it is than go batshit crazy like ESR.
His 3 viable replacements are Rust, Go, and some language nobody but him and 1 other guy have even heard of? That is beyond fucking retarded, on every point. Rust is garbage. Go is garbage. The third thing nobody has heard is apparently not even fucking done yet. If he's actively trying to raise money for it that third one is probably his own pet project. This thing reeks of marketing dribble without substance.
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.
Valgrind drastically reduces the performance of the software, so isn't practical for critical code that needs to execute quickly.
You’re a really stupid moron. Do you even understand what the term debugging means?
Eric S Raymond is a lying turd who does nothing but misrepresent what he knows and take advantage of those who don't know everything in order to make himself more rich.
He is a misrepresentation of a person and a global variable for a type that does exactly what I just explained because of reasons he won't explain. Yet he couldn't exist in this state of being without having had been told exactly how to understand exactly what he is fighting.
Who would trust anyone of them?
You need to understand that what they do is use a kid to fight rather than doing it themselves, only because they gave up on being able to learn. They still think they should get paid for it.
What are they afraid of explaining? They seem like god damn mercenaries to me.
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 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.
C's two biggest problems are:
(1) Undefined behavior. UB is completely unacceptable in 2017. For any UB that can be reasonably detected by the compiler, it should be required to emit an ERROR diagnostic and reject the program. For all other forms of UB, there should be compiler flags and/or (type/expression) annotations that instruct the compiler what to assume and what DEFINED behavior to use in the case of things like NULL-pointer dereference and integer overflow. In most cases, the user would prefer to have a well-defined trap/exception for NULL dereference (sorry, but catching SIGSEGV isn't portable solution), and have twos-complement behavior for signed integer overflow -- except in loops, where you'd usually prefer to have a trap/exception.
(2) Implicit casting and weak typedefs. Make explicit casting the default (offer a flag for old-style code), and add a keyword to create strong typedefs that cannot be converted without an explicit cast. (aside: C++ allows a horribly verbose hack for strong type wrappers around primitive types: user-defined types with explicit constructors and conversion operators for types you want, deleted constructors and conversion operators for types you don't want, and user-defined operator overloads that delegate to a wrapped primitive type; however, C++ still suffers from C's implicit conversion disease... case in point: try to do operator += on a bitfield with -Werror=conversion enabled == you're going to have a bad time).
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.
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)?
If it can't target something as small as ATtiny25, it's not an alternative to C.
#DeleteFacebook
No, CD is successor to cassette tape.
#DeleteFacebook
Hork!
People do not use C/++ because they have done a careful language analysis. They use it because everyone else does and they are too lazy to learn anything else.
By the 1970s there was a general movement to type safe languages. But some of them were fascist, others just not available on all platforms. Details that force unfortunate decisions.
But the big technology developed in the 1970s generally misunderstood by slash dotters is efficient generational garbage collection algorithms developed by the Lisp community. That makes such a difference in how one goes about using memory.
For writing a micro-controller application then C will do. But for serious code, I want something that manages memory for me. Plus I want static type safety, and very efficient compilation. And today that means Java or C#/.Net. A bit bloated, no good for micro controllers, but so much more productive for larger systems.
Well written C# and Java is actually more efficient than C/++. Partially because it can do whole of program optimization. Partially because it can optimize for a particular processor rather than a generic one at a separate compile time. 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. Partially because it allows focus on algorithms rather than fixing nasty bugs. There are two caveats 1. They both use stupid UTF-16 for strings and 2. They both enable much more code to be written for a given amount of effort, so people write a lot more code in them.
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.
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
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.
Undefined behavior in C and C++ almost literally means that the compiler is free to completely subvert the behavior of your entire program if the program contains a single instruction of undefined behavior, even if that code would never execute under normal circumstances. Look up "time travel UB" and cringe in terror. That was so bad that the kernel forced GCC to add a compiler flag to omit the *cough* "optimization" *cough*. A smarter solution would have been to fix GCC to emit an error instead of deciding that any unchecked pointer dereference discovered by function inlining means it's free to assume the pointer could never be null even prior to the site of inlining, which means it's free to "elide" (that's a fancy word for "fuck up your program") all branches related to manual error checking up to that point. That's sheer stupidity.
Show me a moderately complex program that is guaranteed 100% free of UB, and I'll show you my "I don't believe you" face. Basically C and C++ are unsafe for use in production code because of the threat of UB. IMO C's UB is the single biggest threat to security in all of software. Yes, it's worse than PHP magic quotes / SQL injection.
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."
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...
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.
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.
The idea of Cx sounds very similar to the C0 project at Carnegie Mellon University. See
http://c0.typesafety.net
https://dlang.org/
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?
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.
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.
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.
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.
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.
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.
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
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...
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/
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)
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)