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.
How exactly is it pronounced? Cause I can already see other language designers claiming "Our language is better than Cx!"
Ezekiel 23:20
Just because they will be different, funnier and hipster than regular ones.
We are in [current year] for goodness sake!, modernity must be made of fads that beget novelty from novelty's sake.
Also boring, regular hammers and nails have been more or less as they are for millennia for some unknown reason (functionality? familiarity?, experience? previous use cases?, what's that?).
The time to change those old tools is really long overdue.
For as long as we're running Von Neumann architecture machines then C and C++ will continue to dominate anything and everything that needs to be high performance and/or low-level/hardware access.
Because if you don't need C/C++ then you're scripting or whatever much-higher-level language stuff. Languages like Go and Rust fit somewhere in between... no-man's land, where they're doomed to get lost like every single previous attempt at such languages.
The ratio of people to cake is too big
Claiming "I have a friend....trust me on this" instills so much trust, doesn't it?
Static code analysis and runtime checking (valgrind) pretty makes C's little issues a non-event now.
And that lack of type safety is actually needed in some domains, so solving it makes it harder to write say kernel code.
The only problems I've seen with C in the last fifteen years are when the ****ing C++ zealots get control of the C compiler and have managed to break C in the process ;)
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.
After "C" the next language name is.... "P". This follows the BCPL heritage.
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.
> 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.
At least we'll get to choose a better language. It'll die of it's own weight if LP attempts shove it upon us all.
Why guess when you can know? Measure!
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.
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
... and the "D" you linked to is only one of several C-like languages named "D".
There are also multiple languages each named "E" and "G".
"We mustn't be caught by surprise by our own advancing technology" -- Aldous Huxley
(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.
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++.
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.
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.
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.
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.
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
Oh come on. I don't know about the other two, but Go's standard library is really impressive. What "complex program" can't you do without resorting to "import C"?
If you mean OS-specific APIs that aren't yet captured in a cross-platform lib, that's a different beast (see the console APIs for instance, which the Go team is still solidifying into a cross-platform terminal package) but that doesn't equal complexity.
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
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?
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.'"
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.
Downmodded as redundant?! This is new! Well... if the ideas in that video are clear to everyone (they should be, although quite a few comments here or in previous threads seem to indicate otherwise), I guess that everything is OK.
Custom Solvers 2.0 = Alvaro Carballo Garcia = varocarbas.
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.
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.
The results are simply unarguable.
Well, except that the only thing you've shown is that C is faster when the only thing you're doing is incrementing an integer inside a tight loop. There are a variety of reasons why that isn't necessarily applicable to real applications, not the least of which is that you would never actually do that in a real application.
If you want to create a useful benchmark, you'll need to test a wide variety of operations -- floating point math, string manipulation, memory allocation/deallocation, threading, recursion, and so on. And I feel like you might be surprised at how Java's thread concurrency or large string manipulation perform compared to C's...
Karma: Terrifying (mostly affected by atrocities you've committed)
Well, except that the only thing you've shown is that C is faster when the only thing you're doing is incrementing an integer inside a tight loop. There are a variety of reasons why that isn't necessarily applicable to real applications, not the least of which is that you would never actually do that in a real application.
Sure. I highlighted this fact in different parts of the video. I wasn't implying that C is absolutely better in any scenario, but at least for the kind of applications where this language is supposed to be used. For example, in any implementation relying mostly on simple programming structures like loops, conditions and simple collections, C is definitively faster. Typical situations where you can find this are core/basic/engine parts taking care of the most essential actions. For more complex situations where other functionalities might be preferred (e.g., heavy use of modern-language in-built functions analysing different array aspects), the comparison and even weighting in things like implementation difficulty would be much more difficult to perform and the absolute superiority of a specific language very unlikely to occur.
If you want to create a useful benchmark, you'll need to test a wide variety of operations -- floating point math, string manipulation, memory allocation/deallocation, threading, recursion, and so on. And I feel like you might be surprised at how Java's thread concurrency or large string manipulation perform compared to C's
The main point of this video was to highlight the impressive superiority of C on a very specific aspect. I was quite surprised myself when I firstly saw it. In fact, I have confirmed that certain assumed-to-be-theoretically-faster algorithms are actually slower in C than the slower-in-other-languages-simple-loop-based alternatives! What I am showing in that video isn't just C being faster, but C loops being unrealistically faster than anything else!
Custom Solvers 2.0 = Alvaro Carballo Garcia = varocarbas.
BTW, have you donvoted the video? Is there anything wrong with it to deserve a so aggressive reaction, as opposed to mere inactivity? Is there any accuracy in what I am showing/saying that might have a negative impact in future viewers? Don't feel offended! I am always interested in understanding what is the motivation for people to easily downvote/censore others. Personally, I only do that when strictly required because of seeing it as some kind of aggression on others which, as such, should be have a fair motivation.
Custom Solvers 2.0 = Alvaro Carballo Garcia = varocarbas.
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.
Memory is cheap, CPU is expensive. The problem of C is that it uses void *userdata everywhere as it has no templates. And unprefetched pointer reference is lethal for modern processors stalling for hundreds of cycles. As an illustration GCC was using horrific #defines to substitute missing templates and despite that after GCC got converted to C++ STL vectors got even faster.
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'
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.
I thought the wheels did that.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
What's the commonality between them: they all have to revert back to plain C to get any performance out.
That doesn't sound true, not for rust anyway. Rust is currently a bit, but not much slower than C, and unlike many other language doesn't have flaws which are easily hidden in microbenchamrks.
This is not surprising: you can pretty easily on paper mechanically translate Rust to C. It's basically a representation of the same abstract machine, but with a good macro system and an iteresting type system. All of that lot disappears at compile time anyway.
Rust, unlike the others was specifically written to be able to do the kind of high performance things that C and C++ traditionally do well.
SJW n. One who posts facts.
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.
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."
... and I have come across a rare dialect of Haskell named "H" intended for embedded systems, but there may of course be more.
"We mustn't be caught by surprise by our own advancing technology" -- Aldous Huxley
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.
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...
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'
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)
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.
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.
I don't think pascal was ever popular - apart from schools. It wasn't something you'd use in the real world
...apart from Delphi (Object Pascal). Skype, KazaA and just about every antivirus suite are written in Delphi.
'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'
Wasn't there a "J" language which was based on APL?
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Correction. Stirngs always count from 1, not 0. Oops.