Hacker Poll: Is C++ the Language of the Future?(readwriteweb.com) |
Hacker Poll: Is C++ the Language of the Future?(readwriteweb.com) |
I can't help but think that people that suggest this stuff simply look at lists of features and see "lambda" and think C++ has somehow been modernized. Still fundamentally, it's producing machine code and fundamentally it has a fairly limited runtime and compared to what a LISP coder thinks of when he thinks of closures you might not want to call what C++ has 'closures.' Maybe the fact that the article referenced "lambdas and closures" is what throws me off... that's two features, right? haha The posts that mention C++'s cross platform nature also kind of make me laugh, it's sort of true, it's also remarkably easy to make it not true, just using "int" somewhere will break it some cases and if one of your platforms in Visual C++, then you'll probably have 2 code bases #ifdefed in to one, you can make it work but you have to do some work.
C++ probably won't die, not exactly that languages just die. Microsoft is all in with it, and many other organizations use it. It seems like we are in an era where there is more freedom to match the tool to the job than ever before and I can't imagine starting a medium or large scale project in C++ when Java and .NET are both still very viable. I can't imagine any serious C++ web app development, I can easily see some Ruby, Python or something other calling a chunk of C++ code, but I just can't see it rendering javascript and html in any serious way, it makes very little sense. Now VMs, runtimes, browsers, they'll likely continue to have some C++ in them for some time. It's a fine tool for some jobs. I also find is puzzling, the OpenJDK is GPL, simply Oracle's ownership somehow suggests Java is ending? If that's really what matters, then pretty clearly Go and Objective-C are what the future is, just looking at corporate ownership and momentum.
From a feature matrix? Sure C++ is the next big thing. From reality? I think and hope that it's future use shrinks and becomes more specialized.
Even if this somehow happened, allocators include protection at least in debug mode that will let you know when you're doing something obviously wrong.
Writing int won't break your program, I don't see why it would, unless you're making assumptions about range - which you shouldn't. If you need an integer of a certain length there is stdint.h
I wonder if it'd make sense to develop a Coffee Script style language that compiles a "sane" subset of C++, gets rid of some of the nasty\annoying aspects of C++ (header files), and helps enforce good C++ coding practices (const correctness) but is close to C++.
The result hopefully won't feel like a nano-management attempt, while people will think twice before they make anything "mutable".
What I was proposing is a C++ compiler that could enforce a specific subset of standard C++, along with making things that are generally regarded as best practices default. Because of the complexity of C++ it might have to be a somewhat simplified version of it to work (something like http://www.csse.monash.edu.au/~damian/papers/HTML/ModestProp...).
1. cross platform
2. the programmer can choose from several levels of abstractions, as appropriate for a particular project: low-level c-style coding, OOP, templates, meta-programming.
3. even the very high level abstraction usually doesn't induce performance penalty.
4. not using some property of the language doesn't induce performance penalty ("you pay only for what you use" principle).
5. New ISO C++11 standard makes the language even stronger
6. Many design decisions can be expressed by using templates or multiple inheritance, and enforced during compilation.
From internet discussions, I noticed that quite a few people under-appreciate the points 2) and 3), or don't have good understanding about why abstractions are an important part of software design (especially in larger projects).
Also, even in 2011, in a lot of projects the performance achievable only by native code is still very desirable or even required.
2. Just use 2 languages, like C + Lua. or C + anything-higher-level-than-Java. As a "language", such a combination is easily simpler than C++, and the high level part is way cleaner. My point is, don't use one complex tool when 2 simpler one can do.
On a side note, you should think about what OOP, templates, and "meta-programming" are good for. Most of the time, naked lambdas and closures solves OOP's problems in simpler ways. Templates solve parametric polymorphism (or "genericity"), and meta-programming is just a buzzword, as far as C++ is concerned. (When it is not a buzzword, the systems behind are so huge than I wonder if it's worth the effort, see the Boost library.)
3. That one sounds like a lot of work. A high-level and efficient abstraction has to be build from a fairly low level. Efficient memory management for instance, will probably be more complicated than the straightforward (but copy-ridden) RAII scheme.
6. Properly thought out type systems enforce better, and in a simpler way. See Haskell for instance. And even if your high level language is very permissive (Lua, Lisp…), you could still write a custom preprocessor. Not too daunting, as long as the syntax you pre-process isn't C++'s.
That's why it will still be around 5, 10 and 20 years from now - as long as there's something for everyone to dislike it will also make enough people happy enough to continue using it.
I think the number of applications where C++ is an appropriate choice for a new project is a lot less now than it was 10 years ago.
Generally a higher level language (Java, C#, Python etc) should be looked at first in most cases, but I am sure C++ will have its niche for a while yet. Like games for example.
Cross platform could indeed be one of those niches, but just being native isn't that big a deal. Python and Java to give a couple of examples are just as compelling options in most cases.
Look at Java today with it's language ecosystem; scala, clojure, jruby, ...
I can't imagine Java and .NET developers moving to C++ much less enterprises changing course.
Some of my more interesting projects are C++ based so i have a feeling it's going to stick around for quite a while yet.
The only real use for C++ I still see is high performance gaming. And I hope that dies out in favor of real games.
I think most people complain that C++ is overly complex because they try to learn it at the same time they try to learn a complex (typically GUI ex. MFC) framework. If you're learning C++ start with backends. Strip it down so that there aren't so many things to learn initially.
The same thing could be said for any language worth a darn. It stands out more for C++ because it's typically only used in heavy lifting situations. It's almost impossible to learn and produce something coherent in this case. Again though that would be true for any language suitable for such situations.
There are tons of people who think they know C++. There are a smaller subset that do.
If you get people who A> Refuse to follow the subset of the language your group is using on the project or B> deeply misunderstand one or two features, you're in total utter hell if you can't fire the person.
Most places don't have an easy enough ability to fire people to do C++ in my opinion, therefore C++ is not suitable for them.
Most other languages it doesn't matter anywhere near as much, as idiosyncrasies can be cordoned off well, but with C++, anyone doing anything strange or incompatible anywhere is a problem for most everyone. That same power and control is a curse when people are controlling things two different ways.
In a bigco which takes 6 months to fire someone, this is killer to a project. One guy can destroy a project in that timespan.
C++ has it's place, and that place is "where we can afford pretty high salaries and fire those people who don't work out quickly".
Writing boost heavy code vs STL code vs object oriented code vs prototype based code vs highly functionally styled code vs custom allocated code vs reference passed code vs smart pointer code, interface based code vs heavily multiple inheritance based code vs flat hierarchy mixin template based polymorphism etc.
It gets expensive to keep people who do all of that around with the level of correctness you need to not have weird bugs that take forever to find. It usually means "You have few domain experts" on the team as well (for if the project is say, for financial software, or RF controllers, or modems, etc).
I do think we'll see languages that espouse some of the same guiding principles of C++, namely: multiple paradigms, only paying for what you use, native compilation options, and compile-time metaprogramming.
As it stands now, it has a huge marketing problem that's been perpetuated by a meme of "omg complexity!!!!!111," (aside: it's goofy how fashion-oriented developers are) so C++ in its current form could never rise up.
If I could only have one programming language, it would definitely be C++. I can do anything with it on any operating system. No vendor or IDE or build environment lock in. It's a solid ISO standard with multiple compiler support.
I still use bash, Python and Ruby for quick test scripts and prototyping and I like them as well.
Compare to C, where everything is heavily standardized and you can use libraries from different compilers without much difficulty.
It sucks, in many ways, but it's what we have.
Every other complaint I have against the language just stems from my familiarity with C++ and love of static typing (or compiler hints and syntactic niceties useful for writing high performance code - namely games).
If we extrapolate (obligatory: http://xkcd.com/605/) present trends it seems that the platform of the future will be the web.
This will require fast internet connections on computing devices (whatever those will look like in 10 years) as pervasive as water and electricity in the rich world. And we are getting there.
So the language of the future will be based on this platform. The obvious choice then would be javascript. But javascript has a lot of problems so most likely someone will invent a language of the form javascript++ within a few years.
There's so much that can change in one year let alone five or ten, therefore it isn't easy to make predictions that far out.
For the record I use C++ in a day job, and there's an awful lot of code written in it, so it will exist in some form or other for a very long time to come. Need I mention COBOL? There's also enough stuff written in Java, C#, Visual Basic, JavaScript, Ruby, and Python for them to easily last into the next decade.
But at the same time, developers will prefer working in higher-level (more productive) languages whenever possible.
So, IMHO, C++ is a language of the future, not the language of the future.
I really hope people will stop doing such silly things, but realistically, it's unlikely to change too soon.
Lately, I've found the ugliness inescapable and deeply irritating:
for (std::vector<mytype>::const_iterator i = myinst.begin() ...
for (auto i = myinst.begin() ...
I've recently been doing a bit of C# coding again. I'm stunned at how quickly I get get stuff working, mostly because .Net contains all the boilerplate I would either write myself, or have to track down in 3rd party libraries. I wrote a page scraping tool the other day in C#, on my Mac, in vim, with the Mono C# compiler. I had it done in under an hour, and it runs on both platforms I use. My productivity increased by about 8x (clearly not universally applicable), and my enjoyment increased even more.
So, no, C++ probably isn't the future. The future probably looks like Python and Javascript on the web, C# in business applications, and plain C at the bottom.
Your statement is false, because the choice of language depends on the job. For example, when I need to make something simple quickly I will do it in C#. However when I need to write an add-on to an existing application that doesn't have an official plugin system, then C++ and Assembly are really awesome.
Complicated + robust + easy to maintain is plain impossible in C++. Also, add-ons fit "enhance software" better than "building software".
// Untested code, I hope I didn't miss anything
class Foo {
public:
Foo(const Bar& b) : b(new Bar(b)) {}
Foo(const Foo& f) : b(new Bar(*(f.b))) {}
Foo& operator=(const Foo& f) { b = new Bar(*(f.b));
return *this; }
~Foo()throw() { delete b; }
// other methods
private:
Bar* b;
}
class Foo {
public:
Foo(const Bar& b) : b(new Bar(b)) {}
Foo(const Foo& f) : b(new Bar(*(f.b))) {}
Foo& operator=(const Foo& f) { b = new Bar(*(f.b));
return *this; }
// default destructor
// other methods
private:
std::auto_ptr<Bar> b;
}
class Foo {
public:
Foo(const Bar& b) : b(b) {}
// default copy constructor, operator=, and destructor
// other methods
private:
Bar b;
}
Actually, copy is the essence of RAII. Rather than saying "hey, your piece of data is interesting, let me hook it" and later complain when the fish broke your line (dangling pointer), RAII says instead "hey, your piece of data is interesting, let me have a copy" so you are sure to keep your data safe, and the other is sure to be able to safely destroy its own copy at any time.
On a side note, you could avoid copying Bar instances by using Boost's shared pointers or a garbage collector. But it will only be practical if Bar is immutable. I am also told that there are other memory management schemes, which can be very efficient, but tend to be complex and error prone.
No it's not. Lots of languages have broad based understanding of good and bad based on some body, consensus, etc, that does not have mutually incompatible schools of thought that combust wildly when stuck in the same project.
I've never seen a ruby project with a code style guide.
While I've seen python ones (the language closest to C++ in getting randomly hairy different types), the mixups tend to be relatively benign comparatively speaking. Most python projects go with "Look PEP8ish/pythonic".
Objective-C is heavily driven by WWDC presentations and strong recommendations by Apple, so people tend to move to that.
C is all over the map as well, but again, individual complexity of each decision is much lower. You'll have a style guide at a C dev company. "Use lint with these flags and indent with this specifications" is what the best ones have for a majority of their work.
Perl tends to not care, same for php, whereas I think they really should care more.
C#? I've seen style guides, but they're only on about 10-30% projects.
Java: they're usually there.
>"there should be some coding style in a project",
This all comes out to: making all these decisions in a consistant style is MANDATORY for a C++ project. For most others, there are conventions which don't blow things up that make people work generally to a similar enough style. While there may be some codified choices, with C++ in particular, you have TONS of choices, choices that your staff will not all have the same opinions on, choices you'll have to get them onboard with using, onboard with understanding, and thinking in terms of those mechanisms.
That's relatively hard to do. There's so much ramming shit down people's throats in C++ projects that I think it's only worth it in a small small number of cases.
If someone tends to use a different style of dot notation in Obj-C, no biggy, at worse you get a leak or two that an automated tool can find 75% of the time
If someone uses a different type of pointer/reference on a serious chunk of the codebase or a different style of template based inheritance, you're up shit creek really fast.
The language itself has tons of choices all over. The issue is getting everyone on the same page without crushing creative, high spirited people or having to fire otherwise excellent engineers.
I'm not saying the language is useless, I'm saying it is a huge ass staffing pain to get the right mix of engineers who are brilliant and willing to slavishly do what they're told which is hard to find.
Also, add-ons fit "enhance software" better than "building software". Your "building software" could also be labeled as enhancing the operating system.
Now let's add "complicated". To me, it means the problem cannot be solved by a small program. Therefore, the program will be rather big. To achieve robustness and ease of maintenance, you have to make it locally readable and modular.
Now, add "in C++". C++ is extremely permissive. You can tweak almost anything. It can be awesome, but there is a flip side: memory must be handled manually (more code), and you can make fewer assumptions about your program (less modular code). For an originally complicated problem, this is a significant burden.
Now, a very disciplined team could overcome this burden. Just mind a few things: Const correctness everywhere, and avoid side effects where you can (this is both extremely important[1] and not easy in C++[2]). Ban or restrict the use of the more problematic features (I would mostly scrap inheritance, except when emulating Java interfaces). Use the remaining features in a standardized manner (make sure copy constructors and destructors are correct, use initialization lists systematically or not at all, make everything exception-safe or ban exceptions, use std::auto_ptr<> as much as possible, and probably a gazillion other crucial things I forgot).
Some individuals are indeed that disciplined. But an entire team? Good luck finding it.
(2) The API of most operating systems are sufficiently language independent to allow several languages. Most languages are sufficiently OS independent to allow the port of programs in several operating systems. This is basically because an OS API and standard libraries are effectively the two halves of a plug-in system.
So, the constraints are very unlike those you find when adding functionality to a program which doesn't have any plug-in system. I concede that C and C++, as the default API for current operating systems, are favoured. But the burden on other languages is barely noticeable (except maybe for the language implementer).