Quote: Original post by Katie
One could argue that the competitors to C++ are not languages which "stay out of the way". They have, for example, no multiple inheritance or operator overloading not through a technical limitation but exactly because they want to limit the power of the user.

What's wrong with operator overloading? "operator overloading is too dangerous, because it's possible to define operator+ to do subtraction"? That's just silly. Java allows me to write a function named "add" that subtracts. Clearly, named functions should be banned from programming languages, because there is no way to ensure that the function actually does what the name suggests ;-)

Quote: Original post by DevFred
What's wrong with operator overloading? "operator overloading is too dangerous, because it's possible to define operator+ to do subtraction"? That's just silly. Java allows me to write a function named "add" that subtracts. Clearly, named functions should be banned from programming languages, because there is no way to ensure that the function actually does what the name suggests ;-)

i think their point was agreeing with you. They were saying that languages like java that don't allow operator overloading are getting in the way of the developers.

Quote: You've missed the point, and to be fair, I phrased it badly. The top guys don't need to be uber-productive. They write the infrastructure that allows the rest of us to productive. This article explains it better.

You indeed phrased it badly; the article in no way says that productivity is not important. Only, writing good code is more important. If C++ is the only language that can possibly do the job, then of course it is the better choice. You seem to imply, however, that using C++ has merit of its own, forgetting that it's merely a tool like many other. If the same results could be achieved using a more productive language/method of development, then yes, switching to that language/method is critical, no matter how 1337 you think C++ is.

Tim Sweeney at least thinks that productivity is a good thing, and keeps an open mind about the tools he's using.

Quote: One could argue that the competitors to C++ are not languages which "stay out of the way". They have, for example, no multiple inheritance or operator overloading not through a technical limitation but exactly because they want to limit the power of the user.

That's not really "staying out of the way".

C++ doesn't have higher order functions, garbage collection, a decent standard library, type safety, transactional memory, built-in concurrency primitives, proper tail recursion, working encapsulation or any number of features those other languages have.

Does that mean that C++ is trying to limit the power of the user? Of course not. It just means that you don't write code exactly the same way in C++ as in those other languages. Saying that language X is less powerful because it doesn't have operator overloading is just stupid. Is C++ less powerful than Haskell because I can't use it to work on infinite lists, or less powerful than Lisp because I can't use it to manipulate its own parse tree?

People have been predicting the downfall of C++ for years now... It hasn't happened yet. C++ will be around and thriving for a long while yet, I think.

brainwashing+english>C++

now I just have to figure out a new I/O device for the human brain so we can send and receive the data fast enough...

Quote: Original post by Valderman

Quote: You've missed the point, and to be fair, I phrased it badly. The top guys don't need to be uber-productive. They write the infrastructure that allows the rest of us to productive. This article explains it better.

You indeed phrased it badly; the article in no way says that productivity is not important. Only, writing good code is more important.

I also never said that productivity wasn't important, merely that for a small subset of developers, productivity is less important that other considerations.

Quote: Original post by Valderman
If C++ is the only language that can possibly do the job, then of course it is the better choice. You seem to imply, however, that using C++ has merit of its own, forgetting that it's merely a tool like many other.

If there is a situation where "C++ is the only language that can possibly do the job" then clearly C++ has merit over another tool in that situation

Quote: Original post by Valderman
If the same results could be achieved using a more productive language/method of development, then yes, switching to that language/method is critical, no matter how 1337 you think C++ is.

Oh FFS, are you done with your petty Ad Hominems yet? [rolleyes]

For the last time, I do not think C++ is l337, leet or any other ridiculous combination of letters. I do think it is useful in certain environments. But equally, I just wouldn't use it myself anymore, as it's simply not necessary/productive for the work I do.

Quote: Original post by Valderman
Tim Sweeney at least thinks that productivity is a good thing, and keeps an open mind about the tools he's using.

Your argument would be that much stronger if the very article you linked to didn't state that Gears of War uses 500,000 lines of C++ between game and engine.

Yes, using the right language for the right job is A GOOD THING. Yes, C++ lacks a lot of language features, but sometimes it's still the right tool.

Quote: Original post by Valderman
C++ doesn't have higher order functions, garbage collection, a decent standard library, type safety, transactional memory, built-in concurrency primitives, proper tail recursion, working encapsulation or any number of features those other languages have.

First, what are you on about with C++ not having type safety? Also, the latest C++ does have higher order functions and built-in concurrency primitives (and the current/not-latest C++ provides these through de-facto standard libraries)...

But anyway, the point is that C++ is a systems-level language that you would use to implement these kinds of features (if you have to), and then expose them at a suitable level to your users.
This might mean a C++ game engine with garbage-collection and STM, exposed to game programmers writing Lua.

Or as at Epic, a C++ engine with UnrealScript game code...

[Edited by - Hodgman on June 2, 2010 10:23:12 PM]

I just want to add one thing to the discussion, and that is just wait. The new standard will be out in less than a year hopefully, and with that their should be a new life pumped back into C++.

The new features that were missing that many other languages have have actually been there the whole time you just needed to know how to get them. Other new features such as auto go a long way toward making the development experience quicker and cleaner allowing the lines of code to be cleaned up and easier to read.

Mind you that the auto keyword will be spoken bad of because you now lose the explicit meaning of a type and don't know for sure what it is without referring back to the original definition, but at the same time it will make code re-factoring quicker and allow easier minor changes.

Quote: Original post by Hodgman

Quote: Original post by Valderman
C++ doesn't have higher order functions, garbage collection, a decent standard library, type safety, transactional memory, built-in concurrency primitives, proper tail recursion, working encapsulation or any number of features those other languages have.

First, what are you on about with C++ not having type safety?

Would you really call a language that lets you cast pointers back and forth at will type safe?

Quote: Also, the latest C++ does have higher order functions and built-in concurrency primitives (and the current/not-latest C++ provides these through de-facto standard libraries)...

But anyway, the point is that C++ is a systems-level language that you would use to implement these kinds of features (if you have to), and then expose them at a suitable level to your users.
This might mean a C++ game engine with garbage-collection and STM, exposed to game programmers writing Lua.

Or as at Epic, a C++ engine with UnrealScript game code...

Exactly the point I was making. C++ doesn't lack these features because it sucks/lacks power/etc. but because the language designers think they shouldn't be there, just as other languages lack some of the features of C++ because their designers feel that those features shouldn't be in their language. That's why "language X doesn't have feature Y so it's less powerful than language Z which has that feature" is such a stupid line of reasoning.

Quote: If there is a situation where "C++ is the only language that can possibly do the job" then clearly C++ has merit over another tool in that situation

Uh, exactly that's what I wrote, isn't it?

Quote: Oh FFS, are you done with your petty Ad Hominems yet?

I don't think that word means what you think it means. Why are you getting this upset over a friggin' language?

Quote: Your argument would be that much stronger if the very article you linked to didn't state that Gears of War uses 500,000 lines of C++ between game and engine.

No it wouldn't, as I'm not saying that you shouldn't use sepples for game development. I'm merely saying that, contrary to popular belief, C++ isn't the One True Language for game development and that seeking alternatives is worthwhile. That talk wouldn't exist if C++ was as rosy as some people like to think.

Quote:
For the last time, I do not think C++ is l337, leet or any other ridiculous combination of letters. I do think it is useful in certain environments. But equally, I just wouldn't use it myself anymore, as it's simply not necessary/productive for the work I do.
/../

Yes, using the right language for the right job is A GOOD THING. Yes, C++ lacks a lot of language features, but sometimes it's still the right tool.

Agreed.

Quote: Original post by Valderman

Quote: Original post by Hodgman
what are you on about with C++ not having type safety?

Would you really call a language that lets you cast pointers back and forth at will type safe?

Uh, yes. C++ has strong type safety, but also gives you mechanisms to circumvent this system if you need to. Some of these mechanisms still check for invalid type conversions to an extent (static_cast) while others hand over trust completely (reinterpret_cast, C). It largely prevents type errors, and when it doesn't prevent them it still discourages them - the one flaw here is that C-style syntax can still be used instead of the rightfully-ugly reinterpret_cast syntax.

Simply adding the mechanism for circumvention doesn't remove the rest of they type system -- you may as well argue that C# is a buggy language because you can *choose* to access a null reference.

Quote:

Quote: Oh FFS, are you done with your petty Ad Hominems yet?

I don't think that word means what you think it means. Why are you getting this upset over a friggin' language?

He knows what it means -- you made a personal attack against his character by implying that he's arguing against you simply because he "thinks C++ is leet" -- attacking the person not the argument. Now on top of that you're attacking his vocabulary for no reason. FFS indeed.

Quote: That's why "language X doesn't have feature Y so it's less powerful than language Z which has that feature" is such a stupid line of reasoning.

Ok... but no one said that. Stop being belligerent.