A Deeply Skeptical Look at C++0x

August 20, 2008 at 7:07 pm 40 comments

Today I saw a link to an article entitled C++ Gets an Overhaul on Hacker News detailing C++0x, the proposed set of standards for the new generation of C++. Working on Half-Life 2 mods and a DirectX game in C++ left me with the impression that C++ was complicated, ugly, bloated and inexpressive. and I was eager to see if these latest changes – other than garbage collection, about which I had already heard – would bring a much-needed dose of simplicity and ease-of-use to C++. Alas, it was not to be. As I read the article, I became so incensed with the sheer stupidity of some of the changes being introduced that I began mocking them out loud. In an attempt to preserve these witticisms for posterity, I will juxtapose extracts from this article and my thoughts.


Ten years after the ratification of the first ISO C++ standard, C++ is heading for no less than a revolution.

Seriously, though, a revolution? The sort of revolution in which average people are freed from unjust laws, or the sort in which average people are crushed under infighting among the elite? Or is it the sort in which everyone’s head gets chopped off?

C++0x, the new C++ standard due in 2009, brings a new spirit and new flesh into the software development world.

How the hell do you pronounce ‘C++0x’ anyway? I’ve got a few ideas:

  • “cee-plus-plus-zero-exx” (logical)
  • “cee-plus-plus-hexadecimal” (what else would 0x mean?)
  • “cee-zero-ex” (terrible, sounds like the name of an energy drink)
  • “cox” (has a nice, if profane, exclamatory ring to it)
  • “cee-tox” (rhymes with detox, raising uncomfortable questions of addiction)
  • “cuttocks” (rhymes with “buttocks”, which is automatically funny)
  • “terrible”

I think I’ll go with the last one.

Brace yourself for state-of-the-art design idioms, even better performance, and a plethora of new features such as multithreading, concepts, hash table, rvalue references, smarter smart pointers, and new algorithms.

Sweet crouching Jesus! Brace yourselves! Hash tables? Multithreading? Truly, the future has arrived, and it’s going to kick your ass.

No doubt you’ll find a lot to like in C++0x!

Replace “like” with “mock” and you have yourself a true statement, sir.

New Core Features

The two most important features of C++0x are concepts and concurrency support. Concepts enable programmers to specify constraints on template parameters, thus making generic programming and design immensely simpler and more reliable.

Go on, try to think of a worse or more ambiguous name for a proposed language addition than ‘concepts’. No luck? Me neither.

Variadic templates, template aliases (also called template typedefs), and static_assert—though not directly related to concepts—will also make the use of templates in generic libraries more intuitive, flexible, and less error prone.

Please, please don’t add language features just to make the lives of library designers easier. Add features to make the average programmer’s life easier.

The importance of a standardized concurrency API in C++ can’t be overstated

Technically, it could; I could say “a standardized concurrency API in C++ will end world hunger”. But to step away from relentlessly mocking hoary clichés, I’d like to point out that compiled imperative languages like C++ are the absolute worst languages in which to do multithreading. The whole model of imperative programming is based around the introduction of changes in state – and when the state is being modified by hundreds of concurrent processes, your previously-bug-free program becomes nondeterministic. Multithreading is really, really hard for a vast array of reasons. Some of the smartest people in the world are trying to figure out how to make programming languages play nice with multiple cores now that Moore’s Law is on its way out, and there’s a reason that they’re using Haskell or inventing new languages rather than pretending that yet another layer on the tower of hacks that is C++ will fix the problem.

As multicore processors are becoming widespread, you simply can’t afford to remain stuck in the single-threaded era, or compromise on platform-dependent APIs. At last, there’s a portable, standardized and efficient multithreading library for C++.

There is very little that about C++ that can be described as “portable” – just ask the Firefox team. Even changing compilers from g++ to Visual C++ involves working through a host of cross-compiler flaws and incompatibilities, and actually porting across operating systems – or, God forbid, architectures – involves more #ifdef’s than you can shake a proprocessor at. (Whether a compiled language can be considered to be portable at all is another matter entirely.) Deep in your heart, you know that you’re going to have to make a lot of changes to make sure that your program compiles across architectures and OS’s – why not recognize this fact and use each target OS’s most powerful threading API?

Rvalue references are yet another silent revolution. While most users will probably not even know they exist (read my interview with Bjarne Stroustrup), rvalue references enable library designers to optimize containers and algorithms by implementing move semantics and perfect forwarding easily, thus reducing unneeded copy operations.

I have to force myself not to write this in as sarcastic a manner as possible, and this is the sort of statement that doesn’t help. C++ doesn’t need any more optimization, because it’s plenty fast already. The reason that Java beat C++ in the 90’s wasn’t because Java had features that C++ didn’t, it was because Java and Sun were willing to take a small performance hit in exchange for happier programmers, more readable code and cleaner algorithms. Silent revolutions won’t help C++; the only thing that can really save its life now is to remove features from the language. Yes, users will bitch and moan, but they do that anyway. Don’t let your language linger and die while it tries to bear the burden of backwards comaptibility.

Automatic type deduction is made possible by the new keywords auto and decltype which deduce the type of an object from its initializer and capture the type of an expression without having to spell it out, respectively.

Wow, uh, that’s actually exactly what C++ needed. Someone is listening to me!

Adding auto and decltype also paves the way for a new function declaration syntax. The function’s return type appears after the -> sign:
auto func(int x)->double {return pow(x);}

There are so many things wrong with this that I barely know where to start. The arrow? The fact that in contravention of who-knows-how-many-years of tradition, return type is going after the function and parameter names? The fact that though auto supposedly deduces that this is a function, it can’t figure out that this function would return a double, forcing the programmer to give two seemingly contradictory types?

Lambda expressions and closures are another prominent feature of C++0x. A lambda expression is a nameless function defined at > the place where it’s called. It is similar to a function object except that the programmer is rid of the burden of declaring a class with a constructor, defining an overloaded () operator and an instantiating a temporary object of that class—this tedium now becomes the compiler’s job. Here’s an example of a lambda expression:
//a lambda expression is used as an argument
myfunc([]\(int x, int y) -> int {return x+y;}

The lambda expression is indicated by the lambda introducer [] followed by a parameter list in parentheses. The optional return type comes next, following the -> sign. Finally, the lambda block itself is enclosed in braces.

Oh, man. Instead of the square brackets to introduce an anonymous function, why not use syntax that is a) meaningful and b) not used everywhere else? Off the top of my head, square brackets perform array declaration, array initialization, and are overloadable operators – why use them to declare anonymous functions as well? Why not take a cue from Python and use an actual keyword?

myfunc(lambda: (int x, int y) -> int {return x+y;} )

Clearer, no? What about function? Anything except this. How do we even tell where the anonymous function ends and the other arguments begin?

Other Additions

Some C++0x features are meant to simplify recurring programming tasks and minimize boilerplate code. Most of these “convenience features” were borrowed from other programming languages.

Maybe they’re recognizing that boilerplate code is a Bad Thing. Perhaps we’re getting typesafe macros? Better syntax for function pointers?

These convenience features include a null pointer literal called nullptr

We have a null pointer literal. It’s called NULL. It’s in C. Honestly.

C++0x enhances compatibility with other independent International Standards. The first set of additions is designed to bring the C++ in closer agreement with the ISO/IEC 9899:1999 Standard C (C99 for short).

Well, better a decade late than never, I guess.

The influence of the recent Unicode 4.0 standard is also reflected in C++0x. C++98 defines a wide char type called wchar_t, that has an implementation-defined size. In the mid-1990s, it was assumed that wchar_t would be sufficient for supporting Unicode but this turned out to be a false hope. The unspecified size of wchar_t prohibits portable UTF encoding in C++98. C++0x solves this problem by introducing two new character types with standardized sizes: char16_t and char32_t that are specifically designed to support portably all the Unicode 4.0 codesets and encoding schemes (UTF8, UTF16 and UTF32).

No, God Damnit. In introducing yet another character type, C++0x just made the problem worse. Now a newbie has to Google his way through forests of documentation and reports just to find out which character type to use. Considering that very few people have the know-how to use wchar_t anyway, why not simply redefine wchar_t to use UTF8? If your “solution” involves introducing two new character types into a language already fraught with unnecessary typedef’s, it’s not a solution. Period.

Some support for Unicode strings in its Standard Library will be available too.

Excuse me? If you’re going to introduce an entirely new character type, then you’d better provide C++ programmers with a coherent reason to switch beyond “because we said so.” The lure of a Unicode-embracing standard library would do much to spur adoption of these char_16t and char_32t types, harebrained though they may be; considering that strings are possibly the most fragile thing in C++, thanks to a million competing implementations, I sure as hell wouldn’t switch my already-working code to use a new character type if I wasn’t provided with a comprehensive set of reliable and fast string manipulation libraries.

A new library for manipulating regular expressions is defined in the C++0x header. Regular expression support has been noticeably lacking in C++—especially among web programmers, designers of XML parsers, and other text-processing applications.

There’s a reason for that, and it’s because scripting languages do regular expressions better than compiled languages. Continually tweaking a regular expression to capture just the right amount of information gets very tiresome when you have to wait ten seconds for your latest code to build, rather than having Perl or Ruby interpret your code for you.

C++ is my forefathers’ language, the language of the 80’s, the language of enormous videogames, segmentation faults, bluescreens, and linker errors. The programmers of my generation want to work in languages that teach us how to love our own potential before we have to hate others’ restrictions. C++0x makes no effort to step in this direction, and it truly saddens me that future generations of programmers will be taught in this language.

Entry filed under: code. Tags: .

Git vs. Mercurial: Please Relax jQuery is a Monad


  • 1. Alex Gordon  |  August 20, 2008 at 8:52 pm

    You’re supposed to replace the x in C++0x with a number representing the year. So if C++0x is finished in 2009 then it would be:

    It’s got nothing to do with hexadecimal constants.

    I wish there was a good successor to C++. Sure there’s a plethora of scripting languages, but most of these can’t be used for applications that need high performance (like 3D games).

    There needs to be more compiled languages with some of the flexibility of scripting languages. And without static typing, thank you. It really slows down development.

  • 2. Phil  |  August 20, 2008 at 9:15 pm

    > C++0x makes no effort to step in this direction, and it truly saddens me that future generations of programmers will be taught in this language.

    I don’t know, this seems like a final act of desperation from a community that sees its own irrelevancy fast approaching. Future programmers might read about cuttocks as a footnote in a Wikipedia article, but I’ll be surprised if it’s used for anything relevant outside of games.

  • 3. Brandon Werner  |  August 20, 2008 at 9:16 pm

    *bows* to you.

  • 4. N  |  August 21, 2008 at 5:47 am

    That was a very entertaining critique. I find it rather unfortunate that C++0x has fallen into the “bike shed” problem, but that is to be expected when a language is designed by a committee rather than by a SABDFL.

    As for the cross-compiler compatibility issues, part of the blame lies in the published specs. The spec published in 1998 had numerous defects, some of which were sidestepped by many compiler developers/vendors. It was not until 2003 that the defects of the 1998 spec were addressed. Then again, instead of just publishing an Errata, some brilliant spark decided it was also a good idea to amend the standard library and put forth extensions.

    Also, that syntax for lambdas and auto/decltype is not just ugly, it’s definitely fugugly.

  • 5. Greg M  |  August 21, 2008 at 5:53 am

    C++ has no niche. The days when we needed to write high- and low-level code in the same language are far behind us – I posit that they never even happened; C++ only existed to migrate programmers from C to OO.

    So what’s the point now that there are next-to-no C-only programmers left and anyway OO has been found wanting and we’re busy migrating _away_ from it? C++ has no purpose today.

    How do you expect them to come up with a satisfactory upgrade to a language without a purpose? You’re attacking a sitting duck (the details of the proposal) and missing the real point, which is that we _don’t_want_ a new standard for C++ (or Java for that matter!). I’d like to see your vitriol directed there.

    Any C++ or Java code written in 2008 is legacy code already. Why do we want to split our legacy codebase amongst more incompatible language dialects than we have to?

  • 6. Vivek  |  August 21, 2008 at 7:41 am

    C++ , you either love it or you use something different…
    For someone who enjoys C++ programming C++0x is a huge leap forward, especially concepts.
    If you are in a situation where you HAVE to use C++ despite your dislike, just find a new job and quit bitching…

  • 7. Asbjørn Ulsberg  |  August 21, 2008 at 8:09 am

    Entertaining flaming, I quite enjoyed the read. And of course I completely agree. C++ was already heading for extinction — C++0x makes it go down with explosions and flames. If it ever gets implemented, that is. I have my doubts.

    Anyway, what’s your take on D? Isn’t that a good contender for a C++ replacement?

  • 8. xk0der (aka Amit Singh)  |  August 21, 2008 at 12:57 pm

    A pointless rant without any meaning.

    Criticizing for the sake of criticizing doesn’t serves much purpose.

    You are comparing a compiled language to interpreted scripting languages, that’s an apples to oranges comparison. There are, and would always be, reasons to have compiled languages around, so yeah! even C would be around for long. C serves it’s own niche domain, C++ the other.

    And your absurd take on the C++0x name! They are not changing the name of C++ to C++0x or for that matter to C++09, which would be the name of the new standard.

    Every good programmer doesn’t just write code, he creates re-usable libraries at the same time. And for big projects, creating re-usable libraries would not be an option but a necessity. So, I find your argument “don’t add language features just to make the lives of library designers easier. Add features to make the average programmer’s life easier.” silly. And by the way, library designers are programmers too. Without them you won’t have anything around in any languages.

    One of the factor that decides a language’s strength is the availability of quality (and to some extent quantity ) of libraries. So, it’s a good step that they are making it even easier for library developers.

    NULL in C is a #define macro not a null pointer literal, get your basics straight! nullptr is a good feature to be introduced.

    char is for UTF8, char16_t is for UTF16, char32_t is for UTF32 … what part you didn’t get?

    I don’t even feel like rebutting your others “allegations”, they are pointless to that extent.

    From your post it’s quite evident that you haven’t used C++ much to pass on “your” judgments about it.

    The Flamefest has just began, bring ’em on! 🙂
    – xk0der

  • 9. mike  |  August 21, 2008 at 1:47 pm

    xk0der: Haskell, Ocaml, common-lisp are not interpreted
    scripting languages. They are natively compiled, have equivalent performance to C++ and are more expressive
    and more productive. C++ today is a legacy language
    with no future. The sooner most realise this and steer well
    awat from it the better.

  • 10. alex  |  August 21, 2008 at 1:56 pm

    The fact that it took them so long to add features that
    are widely available elsewhere and also better integrated
    is the sign of a rotting corpse. I am trying hard to justify using
    C++ today and i can’t come up with anything.

  • 11. Homer Simpson  |  August 21, 2008 at 2:41 pm

    Dude, you don’t know C++.

  • 12. xk0der (aka Amit Singh)  |  August 21, 2008 at 2:44 pm


    Interesting that you brought functional languages into the debate. Some may have equivalent performance to C++, but only in some cases, (most) C++ programs would be faster any day. But again, I shouldn’t be doing what the author of the post has done. Comparing functional languages to an imperative (Object Oriented) one.

    OCaml is a nice language, and one that claims to achieve the performance near to C++ (see C++ is the benchmark!). But then again, the problem with it is that it is not a pure functional language. You can very much write programs in OCaml which use no functional programming elements, or one which use them at the minimum. Not that it’s not a good language, but that it doesn’t fall into it’s category properly.

    But, I reiterate, I’m not taking anything away from OCaml, Haskell or any of the functional languages, they have their own advantages and disadvantages. I personally like Haskell 🙂

    About the expressiveness and productivity part, it’s entirely a subjective matter. If you are well versed with language “A” and know a little of language “B”, you definitely will be more productive and expressive in language A than B.

    @ alex

    Just think of the new C++0x(9?) as the new language. Now! are there any problems that it has the features of all the contemporary languages?

    @ all 🙂

    I may have been a bit hot-headed while making the first post. But the point of the debate is
    1) It’s not ideal to compare languages.
    2) C++ has changed for good.

    Scripting languages have their domain, compiled languages have their domain. I use them both.

    Hope I was able to put forth my points in a clearer manner.

    – xk0der

  • 13. Bob  |  August 21, 2008 at 3:19 pm

    You’re suffering from the delusion that every programmer has the same problems to solve as you do. Yes, Java is great for knocking out undemanding desktop apps. But what about the guys who program Photoshop? Or KDE? Or Metal Gear Solid?

    These guys have massive projects that *must have* low-level performance. They don’t want to use C or assembly because they need to ship sometime this decade, yet they need the maintainability afforded by OO. These are the people who need C++ and will welcome the improvements that C++0x

  • 14. fahad  |  August 21, 2008 at 3:48 pm

    i dont agree with u at all:)

  • 15. Patrick  |  August 21, 2008 at 4:36 pm

    As a seasoned Haskell hacker with good experience in Ocaml and Common Lisp, I have to say that none are suitable substitutes for C++ in all cases.

    No other well-supported language gives the same combination of low-level control and high-level capabilities.
    The only competitor is D, and C++0x narrows most advantage D has from being new.

  • 16. Victoria  |  August 21, 2008 at 5:07 pm

    Good work. Keep it up 🙂

  • 17. Walter Bright  |  August 21, 2008 at 5:46 pm

    The only competitor is D, and C++0x narrows most advantage D has from being new.

    Here’s a fairly exhaustive comparison of D with C++0x based on what C++0x is adding. D, however, has gone way beyond this with other capabilities.

  • 18. kL  |  August 21, 2008 at 8:56 pm

    Since I saw D and I’m not going to use C++ ever again.

    In just days of learning D I could create more complex templates that I ever managed to create in C++.

    And the syntax of D is so clean and minimalistic. And it has real arrays. No super-rigid slabs of memory, no quirky and fragile net of STL templates – just arrays!

  • 19. _ex_  |  August 22, 2008 at 12:30 am

    I was tempted to use D, but escares me the bugs in the compiler and the 2 libraries…

  • 20. Nemanja Trifunovic  |  August 22, 2008 at 1:29 am

    A very unnecessary and uninformed rant. C++ is a practical system programming language and C++ 0x is a good step to make it better. It can’t be pure or beautiful or easy to master, but it is useful for its purpose and that’s what ultimatelly maters. D may be “better” and “cleaner” and “better designed” but for all practical purposes it is non-existant. Other mentioned languages such as Haskell and Ruby simply server different purposes and comparing them to C++ makes no sense at all.

  • 21. Vivek  |  August 22, 2008 at 6:26 am

    @ xk0der
    Nice !

    Aren’t you the same Amit Singh who used to write for PC Quest India in the late 1990s and has that crazy Hanoi towers in N number of languages thing somewhere on the web?

  • 22. xk0der (aka Amit Singh)  |  August 22, 2008 at 7:48 am


    Sorry Vivek, I’m not that “Amit Singh” (unfortunately) :)… I was probably in my high-school or pre-high school, when he used to write!

  • 23. Joe  |  August 22, 2008 at 9:52 am


    “xk0der: Haskell, Ocaml, common-lisp are not interpreted
    scripting languages. They are natively compiled, have equivalent performance to C++ ”

    You have absolutely no idea what you’re talking about. This just proves that you have either

    1) never used c++;
    2) never used haskell;
    3)never used lisp or ocaml;
    4) all of the above


  • 24. Kamy Lamm  |  August 22, 2008 at 10:11 am

    In the common way c++ itself is the toughest thing till day……… so about C++0x tech……….. may make things bitter smoother and friendly to work with. Lets see and wait up to 2009………. thanks for the updation………….

  • 25. xk0der (aka Amit Singh)  |  August 22, 2008 at 10:48 am


    Whom are you replying to? me or Mike ? I assume it’s mike! 😉 (:evil grin:)

    Please reply. 🙂

    – xk0der

  • 26. Joe  |  August 22, 2008 at 2:02 pm


    yes it was mike.

  • 27. pig  |  August 22, 2008 at 4:56 pm

    This guy really doesn’t like the C++ coolaid. Strikes me as a language-du-jour waffle-boy; attracted to shiney programming languages that protect the box from the boy.
    I, for one, am a C++ programmer writing commercial apps and I welcome C++0x, whenever it gets here. I write multi-threaded code and the new concurrency features are **awesome**. I don’t plan to switch to Erlang or any other new multi-threaded language because I’m good at writing C++ code and it’ll be around for the rest of the century, provided CERN does not kill Earth next month.
    When performance counts, you can roll the dice with a language-du-jour or stick with what works. C++0x will be here shortly, improve the language and with proper application, the result will be cleaner, tighter code.
    If C++ isn’t your cup of tea, I completely understand; you’re a wuss.
    Flaming aside, the article is a thing of beauty.

  • 28. David  |  August 22, 2008 at 7:02 pm

    I really wish some of the C++0x features were available when I was doing exclusive C++ development, back in ’02.

    Comparing C++ to Haskell shows signs you are suffering from the same (unfortunately non-terminal) disease a lot of Java enterprise developers suffer from – where everything looks like a nail. Sure, your hammer does a lot better job at driving nails than my screwdriver, but its still an apples-to-oranges comparison. Its just unfortunate that you actually *could* drive a nail in with the blunt end of a screwdriver 🙂

    Non-casual game developers will move business logic into languages like LUA, but they will always stick to C++ because (microbenchmarks aside) they need the performance. They are in the position that they always need to stay competitive with the latest and greatest, and cannot take the performance hits of a late-bound type language in their core logic. Game consoles are also embedded systems, and you run into problems where you simply cannot deal with the timing and memory overheads of GC.

    Re: nullptr, its a great addition, one that is long overdue. 0 is a boolean, all integer types, and a void * to the zero address, all at the same time. This bites you hard in very arcane ways.

    Concepts are not necessarily the best name, but they bring compile-time binding of types and solve the worse of the type problems in previous C++ releases. Passing an incorrect pointer into a templated algorithm would yield a page of errors as the compiler tried to dive all the way into the code until it encountered problems. Now you will get simple errors. In a scripting language, you just get a runtime exception.

    You obviously do not like C++ (although I doubt you have ever used it). Consider yourself fortunate that you have managed to avoid it then, by specializing in a different sector of the technology industry. But for people with a real need for C++, these changes cannot come soon enough.

    Oh, and I’m not a fan of the lambda syntax either. Oh well, its usefulness outweighs its tackiness.

  • 29. GJS  |  August 22, 2008 at 7:28 pm

    I suspect we have beet trolled constantly.

  • 30. charles black  |  August 22, 2008 at 7:55 pm

    Looks like that story that you are picking apart so thoroughly was written by Danny Kalev. Why don’t you just take it up with him? For example, right at the start you take issue with his use of the work “revolution”. Well those are his words. That’s his interpretation. Why don’t you tell him directly that you think that’s a load of crap. You should have just ignored such things and gotten directly to the point instead of wasting time with your rant.

  • 31. web design company  |  August 23, 2008 at 1:36 am

    This article mimics my thoughts on C++0x exactly.

  • 32. Thomas Hansen  |  August 23, 2008 at 12:00 pm

    0x means 200x where x will become the year it was ratified. This is normal in other std efforts too like SQL99, C91 and so on…
    S++ is BTW (still) the most widely deployed programming language in the world, and fact is that you wouldn’t even get to start your car or fridge without it being at the center of your actions…
    Though standardizing C++ is very difficult because of backward compatibility towards both C++99 and C too in fact. Which many will point out to be its strengths since it makes it possible to reuse a LOT of existing code…

  • 33. Your a moron  |  August 23, 2008 at 5:37 pm

    Just another unintelligible rant from yet another Java fanboi. Please get your facts straight before writing more drivel.

  • 34. amn  |  August 24, 2008 at 5:29 pm

    Hey, I dont want your generation to program anything. The way you do it by taking the latest hardware and turning it into what your forefathers had available by using terabytes of plaintext scripts that have enough hacks themselves. You scream usability, but you forget that computer is a tool, and one with limited power, and so you can never sacrifice speed. If everyone of the ‘newschool’ coders thought that way, then each app on your desktop compromising a bit of speed, would result in unusable machine. What is next, a Java-run OS? Sure it would be cool, but we are tired of constantly having to upgrade our machines. There is nothing wrong with a C++ strings that are sequences of bytes, because that is exactly what a string is, and no matter how abstract you make it, it still remans that. And just because everybody CAN create string implementations, should not make it a drawback. It is called diversity. Life is full of it.

    1. The name of the language does not matter. People who need to use it will use it regardless. If anything, searching on generic names like Java, Ruby and Python brings up coffee, precious stornes and snakes, but you don’t hear me complaining, because I do not care. If I need to use a language I will, no matter if it is called Shit or Gold.

    2. Libraries are core of the languages. This is what makes the bulk of your program, and if it does not then you are good at reinventing the wheel. Your job as application developer is to make use of all these libraries that are available to you. But, of course average programmers reinvent the wheel all the time right?

    You are right on the spot that C++0x is inexpressive. Lambda functions could have been labeled lambda, and not [ ]…

    Still, presentations is not content. Your write beautifully and with sarcasm but it helps little when one is off track mostly.

  • 35. Pat M.  |  August 25, 2008 at 1:20 am

    There’s some commentary on reddit, where this post didn’t go over very well.

  • 36. Chris Hanson  |  August 25, 2008 at 2:27 am

    Did #23 up there really say mike was an idiot for saying Common Lisp, Haskell, et al are compiled rather than interpreted? Or that they don’t have equivalent performance to C++?

    What a moron. Learn something about your goddamn industry, fools. Just because some languages offer interactive environments doesn’t mean they’re not compiled, or that they can’t be efficiently compiled.

    Most Common Lisp implementations for the past 20-30 years have even compiled interactive code – code entered through the REPL, which people sometimes call “the interpreter” – and Lisp Machines were among the first serious high-end workstations.

    Similarly, Smalltalk environments have been compiled since the 1970s, first to bytecode and then using just-in-time compilation and optimization techniques. Sun’s HotSpot JIT for Java was originally developed by a Smalltalk company.

    And on Mac OS X, the Cocoa frameworks that most software is written in are all built in Objective-C, another highly dynamic language. Objective-C was created about the same time as C++, but instead of punting on issues like shared library semantics and run-time type information, Objective-C learned from Smalltalk’s example and embraced them. The result is a language that’s very easy to learn and use, and lets you write great software far faster while also allowing you plenty of opportunity to optimize.

    Finally, Microsoft Research created the game-matching system used by people playing Halo 3 over Xbox Live in F# — a functional language — rather than C# or C++. Why? Because the semantics of the language made it good for hardcore algorithmic work that needed to scale to huge data sets and large numbers of CPUs. Good language interoperability throws away the need for jack-of-all-trade languages, because it lets you pick the right tools for the right problems.

  • 37. S  |  August 25, 2008 at 3:16 am

    What a moron.

    So-called “cross platform” languages are run on compiled software, which does incur a performance penalty, and often does not completely abstract the under lying platform completely; there are differences between programming in Java for Windows, Linux, or both, e.g.

    This guy is just one of those sub-par factory produced coders who went to a Java school, or had to retake comp sci a few times before the prof passed him out of annoyance.

    His “points” about programming, languages, etc. aren’t even correct half the time.

    What a crock.

  • 38. Serestric  |  August 31, 2008 at 10:55 pm

    I have seen excellent and witty critiques of technology. I did not see it here. I saw the ramblings of a blithering inexperienced idiot who has no clue about the realities of the industry.

    Perhaps if he actually got a job coding for a serious, high performance coding project his ‘opinions’ would be a liitle less inane. Of course, if any prospective employer saw this article, the author would never get a job. Critical thinking skills are the most important assets in this business after all.

  • 39. G  |  September 1, 2008 at 11:40 pm

    0x is to say that it is planned for some year 200x
    I use templates in common programming, they aren’t just for libraries
    The [] notation allows some data to be put inside the brackets. Your idea of using : is purely Python, which uses that notation due to a lack of braces. The lambda expression ends after the {}
    nullptr is not NULL
    The languages you show obvious favor for are of a different paradigm. Their purpose is a different one

  • 40. SG  |  September 2, 2008 at 10:22 am

    I guess this wasn’t even an attempt to seriously discuss C++0x. So, I’m gonna try to keep my comment short:

    The hashtable & multithreading part is sort of an official catching up. Of course there have been threading libraries and hashtables around for C++ before. Though, the support for multithreading should not be underestimated. Check the paper “Memory model for multithreaded C++” which actually is not restricted to C++ at all but describes common problems like multiple levels of memory caches and how a contract between hardware manufactures and compiler/software developers could look like. Such a contract is essential. The contract they described is state-of-the-art and unmatched.

    Regarding naming of the language and the concept feature: Please do some more research next time. Informations on “why” and “how” is all over the place. Since the early days of the STL the word “concept” has been used to categorize types. This is nothing new. The new thing about it is that the compiler is now able to PARSE and CHECK such type requirements which have been previously documented via comments.

    Also, you should read at least the rules of thumb in “The design of C++0x”. It explains and rationalizes every design goal including favouring library solutions over core language extensions. Your suggestion to add a new keyword like “lambda” collides with one of those rules. BTW: The new function declaration looks different after unifying syntax with named lambdas.

    I’m going to stop addessing single points of your criticisms here. It’s obvious that you didn’t check any of the published and freely available papers that rationalize all decisions.

    C++ is your forefathers’ language that is EVOLVING. You just need to pay attention.

    Quoting B.S.: “Language comparisons are rarely meaningful and even less often fair. A good comparison of major programming languages requires more effort than most people are willing to spend, experience in a wide range of application areas, a rigid maintenance of a detached and impartial point of view, and a sense of fairness.”


About Me

I'm Patrick Thomson. This was a blog about computer programming and computer science that I wrote in high school and college. I have since disavowed many of the views expressed on this site, but I'm keeping it around out of fondness.

If you like this, you might want to check out my Twitter or Tumblr, both of which are occasionally about code.

Blog Stats

  • 709,140 hits

%d bloggers like this: