I second that. Having spent almost a decade writing commercial C++ code, I recognize everything horrific about the language as documented in the FQA.
The thing is, it doesn't matter. The fact that it's the leading language in your domain is much more important than its abstract quality. Availability of libraries, co-workers who understand it, examples of how to solve common domain problems in the language, these all outweigh the pitfalls and ugliness of the syntax.
Don't be seduced by the language wars. It's like spending days optimising a function that only takes 10% of your run time. Unless you're interested in the learning exercise (which I'm not knocking if you have time) pick one of the dominant languages in your domain, and spend your time worrying about everything else.
Why is C++ suddenly "fine" when you have no other options? There could easily be a language with all the close-to-the-metal advantages and none of the baroque, redundant complexity of C++; why must we be content to use the same language as everyone else in the industry, rather that scratching this itch and building a newer, more productive one?
"Newer" isn't necessarily better or more productive. Especially given the monumental task of having to write a game without the benefit of any of the libraries developed over the past few decades.
Perhaps the reason there are no other viable options is because C++ is pretty well suited to the task?
Why would you have to lose the libraries? .so files are .so files; it doesn't matter what language they were written in, as long as they expose an API that can be cleanly wrapped by your own language.
... and a standard ABI, otherwise you will never be able to link. C++ did not have standard name-mangling conventions until recently, which forced you to use the very same compiler to compile both your libraries and your own code. This is still unfortunately very much a concern with all these legacy systems out there. Your only solution is to expose your API as a C library or distribute your source code.
> Why is C++ suddenly "fine" when you have no other options? There could easily be a language with all the close-to-the-metal advantages and none of the baroque, redundant complexity of C++
A lot of that "baroque, redundant complexity" comes from standards committee's refusal to make things easier on programmers at the cost of any smidgen of performance.
And for certain tasks, like the highly competitive video game industry, uncompromising performance is exactly what the doctor ordered. You can always hire smarter programmers if you have to. On the other hand, it's hard to sell a game that runs or looks like crap at 60 fps.
The complexity is "baroque" because, in modern times, we've invented ways around it. Type inference would kill half of the pain involved in C++ without sacrificing performance. Cleaning up the syntax enough that definitions could be found context-free would eliminate the need for declarations, and in most cases .h/hpp files.
The complexity is redundant because they included features of C that they should have deprecated in favor of the C++ equivalents. String literals should be (const) basic_strings, and there should be no way to access stdio's horribly-easy-to-buffer-overflow machinations now that there's iostream. For that matter, boost should be adopted at a much more formal level: the default syntax for pointer variable allocation should allocate smart pointers, and one should have to go out of their way to get a dumb one. None of these things sacrifices performance; they're just artefacts of the fact that C++ wants to pretend it's still 1970 and that it's being used for systems programming in a mélange with C.
Type-inference is needed in C++ (and is already part of the next standard, you can enable the auto keyword with gnu gcc already). But it's needed for entirely different purposes than what scripting languages use it for: it's a feature for writing better templates.
It's confusing because there are two types of type-inference (run-time and compile-time). You do lose performance with run-time type-inference, which is what most interpreted languages use. C++ already has compile-time type-inference in the form of templates. They are...complex. But they're also faster than anything similar. There's a reason that C++'s sort is usually faster than C's qsort for complex types.
C++ doesn't have run-time type-inference and probably won't. The performance loss is too big to build it into the language everywhere, and unless you do that it's pretty pointless. You can tack it on with boost::any or RTTI, for example, but you'll generally find that it's not the correct decision from an engineering standpoint. Scripting languages have run-time type-inference built in everywhere -- but they do it at the cost of performance.
Now, as far as the problems of C++'s dependence on C...well, you're right. It's a feature of C++'s history. If someone could come along and invest the millions of man hours required in making a performance-critical high-level language without the C-baggage (and then market it!), it would be a great thing. But that's a pipe dream. The best we're going to do on that front is Java.
If someone could come along and invest the millions of man hours required in making a performance-critical high-level language without the C-baggage
As long as it also had C syntax, and something close to the C memory model, and was recognizably object oriented and/or functional. And came with a lot of libraries. And 3D graphics engines. And physics engines.
Unless some independent game developer does something in a new language that other developers can't easily duplicate with their current ecosystem (not that it couldn't be done in C++), and it catches on, there's no incentive to do anything other than continue to evolve things in the most backwards compatible way. There are always more C++ programmers coming off the assembly lines who want nothing more than to work on games.
According to the very Wikipedia article you cited, there is no such thing as "runtime type inference". What you described as such is a way of implementing dynamic type checking: checking at runtime that the types of the various parts of an expression actually match. You should actually read your sources.
So, "type checking" isn't always performed at compile time.
Type checking is a little different, and refers to some safety measures done at compile time that theoretically guard against certain types of errors. Scripting languages don't do them, and don't miss out on much programming correctness as far as I can tell.
Full run time type inference in C++ is about having a container of something -- let's say void pointers that just point to memory locations, and figuring out what sort of thing they're pointing at. Or similarly, you have a base-class pointer and want to figure out which derived version of the object is being pointed at.
I replied to you above, but I'll reply to your specific example here. Your example is really not how PL people talk about type inference. However, you're right that you wouldn't call this example type-checking either... it would probably be a fuzzier term such as "reflection" or "introspection". But certainly not type inference. Do you understand what the wikipedia article you linked is about? Because it's NOT about introspecting the type of a contained object within a container. It's about statically making proofs of the type of a variable based on its usage.
A quick read of this page and its top link strongly suggest that runtime type inference is an optimization designed to speed up the interpretation of dynamically typed programs. It sounds very useful for JIT compilation (to make appropriate code specializations). It's also likely too complex to be implemented in simple interpreters (like Lua's).
Note that this term isn't very widely used: we are already in second position at your link.
So, unlike ML-style compile-time type inference, runtime type inference is implementation specific. Your earlier statement "Scripting languages have run-time type-inference built in everywhere" is actually ill-typed. However, if you had said "checking" instead of "inference", your sentence would have been correct.
Hence my "Err, by "runtime type inference", you actually mean runtime type checking, right?"
Type checking is what you say when the compiler makes sure that you've used all your types correctly, and spits out an error when you don't. It's there to prevent you from trying to assign an int to a string, for example.
"Runtime type checking" is the same thing at runtime. Errors and exceptions get thrown, your program stops. So no, that's not what we're talking about.
There is such a thing, but it has a different meaning than how I believe you used it.
You said "scripting languages have run-time type inference built in everywhere". I don't think that's true for most scripting languages. Inference refers to determining facts which were not explicitly provided, and usually implies a statically typed programming language where inference is done at compilation time. "Runtime type inference" might be used for, e.g., Python's Psyco project, where the just-in-time compiler infers properties about a particular variable (such that it's always an integer) and can therefore compile out boxing, unboxing, runtime type checks and so on.
Speaking of runtime type-checking, I inferred that that's what you meant when you said "runtime type inference". Type-checking IS something that happens at runtime almost everywhere in dynamic languages. It is also more closely associated with RTTI -- a dynamic_cast in C++ would not be termed type inference (the previous and new types are known), but a type check does occur at runtime.
That's kind of the point, isn't it? I use the languages that I am most familiar with, because I am far more effective with them than I am with whatever this year's new awesome language is.
If I had been doing Ruby from the beginning, then I should continue doing Ruby, and not use C++ just because someone else says so. Likewise, if I've been doing C++ for as long, it doesn't make sense for me to switch to Ruby just because someone else doesn't like C++.
This stuff is so much nonsense. I think I will start using programming language evangelism as a reliable marker of a less experienced programmer.
Unwillingness or inability to shift between development tools where appropriate is also something I've noticed characterises less experienced programmers (often evangelism can be driven by this).
Using your example languages. I can think of situations where using C++ rather than Ruby would be idiotic, and likewise situations where the reverse is true.
Because, from what I've seen, a lot of people can be very excellent programmers in one language, but be unable to learn to program in another.
Actually, I don't think it's really "less experienced programmers". Several of my computer science peers (I'm 23) -- inexperienced as professionals, but very smart -- will try the same problem in four or five languages, just to learn the language, and have no fears about jumping into a new language to start a new project. On the other hand, I know some excellent older programmers (late 40s) who know C++ super well, are willing to apply jaw-droppingly complex template metaprogramming, but who only reluctantly use Python and won't touch Ruby or Scala. It's probably more of a cultural thing.
I don't think it's cultural, or even generational; it's just the byproduct of working in a domain for a long time.
Inexperience doesn't mean a person isn't smart, or that they aren't good or that they aren't clever. All it means is that they haven't developed a significant body of familiarity with something.
So, your peers are learning several languages -- maybe superficially, maybe not -- but they aren't yet developing the familiarity with one or a couple of languages that allows them to feel comfortable mentally solving any given problem in the language they're most familiar with. Thus, you have "Ruby" problems, "Python" problems, "C++" problems, and so on.
Those older'n-dirt programmers on the other hand have already solved a huge number of problems in C++. That doesn't mean they're a better programmer, but it does mean they're more experienced. So, if you ask them if they could write X or Y or Z, they'll say sure -- and in their head, they're probably already gathering the familiar pieces that they would need to solve it.
Or, to put it another way: if you went to pg and asked him to write software to run a forum like this, he would probably choose to do it in Lisp, and that would be a good choice for him. If you asked me, I would do it in PHP. If you asked DHH, he would do it in Ruby (on Rails).
None of those are wrong.
The only wrong choices would be me coding in Lisp.
