Multi-Device C++ is used everywhere on planet Earth and beyond
blogs.embarcadero.com
blogs.embarcadero.com
I get that there are userland applications in C++, but coreutils and all the GNU apps traditionally used in Linux distros are in C. And if you're counting userland apps, then you might as well say that Python and even JavaScript are the language of Linux, particularly since their use is growing more and more in most distros. Clearly, no one would make such a claim, so why for C++.
I like the civility in this sentence, yet I'm inclined to say that it's more than just "a bit disingenuous." Is there anybody who has not read this post by Linus Thorvalds on C++:
While this isn't "linux" per se, it's also kinda hard to do anything useful on a GNU/Linux system at this point without a working C++ compiler.
Looking at the graph it amazes me Microsoft has not tried to tackle this more directly. C# and Haskell only attack the application level, why was there never an effort from them to improve the system level?
And you can certainly write crappy Haskell too. It is hip to shit on C++, I get it. But for some types of software there is not a good alternative.
Pity the down vote isn't on the far right of the heading.
I think C++ was a bad idea from the start, because it attempts to be a strict superset of C, which is like trying to win a race while being tied to the current front runner. It might have allowed C++ to use the rope to get in front, but now its in front it just drags the language down.
I am trying to invent a good alternative, but obviously that is easier said than done. I like to talk about it openly and provocatively so others who are more qualified to do it might jump in and try too.
This is exactly it. As much as many people dislike C++, not having it at all would be very bad for some areas. Users of the next major systems language should regard C++ in much the same way as (willing) users of C++ regard C.
The takeaway here should be about how much better the future can be, not how bad the present looks. The former is hopefully much less controversial than the latter.
Enhancing your own craft has a ceiling (that of the technology), advancing technology has none.
So my question is the same: Why programmers should try to eradicate C++?
Instead, let's consider this: Should we try to make C++ unnecessary? I think the answer is 'yes' and I don't think it's specific to C++. For all languages × all domains, I think the time should come that there is a fitting alternative language.
I personally love C/C++, write my guile scripts in vim, and see no reason to replace it.
Loosely, you're looking for a language where you can ensure that garbage collection won't happen and that assembly can be written. Those languages aren't popular these days. Then what's needed is some level of type safety and guarantees about efficient code generation. You should be able to reason quite well about the generated code. "No Magic" is the watchword of that land.
Rust is targeting the next level up from kernels, i.e., system utilities and performant applications. It's not really intended to write kernels, but I think it can get there with some careful work. It should, IMO, do reasonably well on more powerful embedded systems based around typical OS models, e.g., the RasPI.
Why? If you don't like it don't use it. There are enough people who are happy with C++ because it perfectly fits their domain.
I want the speed of C.
I want the soft realtime characteristics, practical functional, highly granular GC, lightweight message passing concurrency, hot code reloading and easy parallelism traits of Erlang.
I want the fault tolerance and network distribution tools of OTP.
I want to have access to hard realtime performance with some additional work.
I want type inference, and a static type system which stays out of your way but can approach the if-it-compiles-it's-probably-bugless ideal, yet without weighing you down where you don't need it. (When it comes to dynamic vs static typing, I'd like a slider that I can move at will.)
I want immutability to be the default.
I want pattern matching and code-is-data macros.
I want recognition that the best part of object orientation is interfaces rather than inheritance, but with a way to provide default implementations.
I want a syntax that's very readable (with a gofmt-style standard) and easy to refactor without resorting to a heavyweight IDE. Parenthetically, I am not opposed to parentheses. Its LoC counts should compete with the most expressive languages without sacrificing much readability -- if that means some readability for newbies is sacrificed, so be it, but it should read easily once you've progressed beyond the neophyte stage.
Whenever we get those promised 1000 cores on a single chip, I want this language to scale beautifully onto that kind of CPU.
If I can't write a hard realtime aircraft flight control system, a competitive 3D graphics engine, a complex web app, a word processor, a highly parallel distributed numeric solver, a fault tolerant telecom switch, a variety of throwaway sysadmin and text processing scripts and a selection of games across multiple platforms without feeling like this language was the most appropriate choice for all of these tasks, then it doesn't do everything I want.
I haven't done much with Ada or Eiffel, or enough with Lisp or Haskell, so this list is probably too short on that basis alone.
And once I have all of those things, I'll have another list.
You need all those things _and_ interoperability with existing libraries that are written in C and C++, preferably both ways. That is a lot less fun to implement.
Another thing is that implicit in the 'realtime' part of your requirement is that you don't want a runtime system, and that bugs a whole bunch of your earlier wishes. It also makes the language less interesting as many of the cool features of modern languages depend on runtimes (it's why we can't use Rust or Go!)
Whoever designs the new language needs to have a lot of restraint, knowing all the fancy things modern languages have, and picking only those that can be implemented whilst satisfying the needs that those core applications have.
Thanks for adding to my list -- the more the merrier. :-)
It would be interesting to make the runtime optional, to see how close together the two runtimey and runtimeless subsets could get. Or, perhaps it would be possible to mark a section of code as runtime-free. IIRC some work's been done on that but I don't think it's ever been practical.
Oh, and did I mention my dream language has a great REPL, compiles nearly instantly and can run interpreted, too?
After that comes designing a grammar. How do you want to express the features? This is a fun part. I start by selecting a small program I think should be easy to implement in my language, for example a coffee machine, a small web application, a mathematical algorithm (like fibonacci). Find some you think should be written in your language, and then just do it. Be very careful in that everything you want to express is actually expressed in an unambiguous way.
When you think you got the idea of your language down, now you write it down formally. This is where it gets a little complex so I'm not going to fully explain it (you can mail me when you're at that point @tinco.nl) but the basic idea is that you learn EBNF, and pick a lexer/parser generator (there's multiple in every language, even javascript).
Depending on what features your language has this can be very hard, Ruby for example can only be parsed and lexed at the same time so it requires much hand tweaking.
Depending on the particulars of the language it doesn't really matter in which language the compiler is written, pick one as highlevel as you can. Compilation speed is only important once you have a reference implementation.
Then a rather difficult step, the code generator. It takes your AST and turns it into executable code. For CoffeeScript this means turning it into Javascript. For C# it means turning it into CLR bytecode, for C it means turning it into x86 machine code.
I recommend that as a target language you pick a language that is as close to your desired feature set as possible without conflicting with any of your features. A conflict here means either a lot of work to implement, or incurring a too big performance loss. Pick a low level one like LLVM or CLR bytecode if you need good performance.
And then you're done. Now you have a reference implementation you can focus on making it run fast (by selecting a lower level target language / implementing optimizations) and on making a standard library.
Video games are one of the domains where C++ will always tend to be THE standard choice, indispensible when creating engines.
I'm pretty sure the Linux kernel uses C.
http://thread.gmane.org/gmane.comp.version-control.git/57643...
--------
Then read the article again. C++ terrifies me.