Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualHodgman

Posted 30 December 2012 - 07:16 PM

I disagree. It should be pretty conclusive at this point that (for the general case) 'pay for what you use' has decided detriments to productivity that arise from adapting the limited functionality to the different 'paid' functionality without providing meaningful optimization/performance benefits (in the general case).

Yeah, in the general case (whatever that is, I imagine writing corporate GUIs...), C++ isn't the most productive language, especially for junior staff to be using (they can actually be reducing instead of increasing the project's progress...)

 

However, "pay for what you use" is exactly what makes C++ the most productive choice for the small sub-set of problems where it is (one of) the most productive language to choose from.

e.g. If it didn't have manual memory management, then it would be a very unproductive choice in memory-constrained embedded systems. Manual memory management (the fact memory isn't abstracted away, and a GC forced upon you) is a key feature of the language that enhances it's productivity (in the specific case)!

 

But I would not use wordings like "cure for the symptom" or "crutch" for the memory management in C++ because that is really not what it is. It's a deliberate design decision.

QFE -- for a particular class of situations, it's a very, very useful decision.

 

 

Screw the 'general case'; I'm an engine programmer. I still measure system RAM in MiB, not GiB, and running out of RAM is a real concern, so I need to be able to track every single byte that's used. I need to be able to look at my high-level code and have a pretty good guess at what kind of assembly will be generated from it (and be able to debug with the two interleaved to confirm those guesses). I need to be able to treat memory as bytes and use memcpy. I need to be able to read data off disk and cast it to known structures without parsing/deserializing it. I have to make a lot of low-level optimizations, and make heavy use of the "pay for what you use" idea.

I also need to be able to support a productive "game programming" language, such as Lua or C#, but that comes after getting the foundations right wink.png


#2Hodgman

Posted 30 December 2012 - 07:14 PM

I disagree. It should be pretty conclusive at this point that (for the general case) 'pay for what you use' has decided detriments to productivity that arise from adapting the limited functionality to the different 'paid' functionality without providing meaningful optimization/performance benefits (in the general case).

Yeah, in the general case (whatever that is, I imagine writing corporate GUIs...), C++ isn't productive.

 

However, "pay for what you use" is exactly what makes C++ the most productive choice for the small sub-set of problems where it is (one of) the most productive language to choose from.

e.g. If it didn't have manual memory management, then it would be a very unproductive choice in memory-constrained embedded systems. Manual memory management (the fact memory isn't abstracted away, and a GC forced upon you) is a key feature of the language that enhances it's productivity (in the specific case)!

But I would not use wordings like "cure for the symptom" or "crutch" for the memory management in C++ because that is really not what it is. It's a deliberate design decision.

QFE -- for a particular class of situations, it's a very, very useful decision.

 

Screw the 'general case'; I'm an engine programmer. I still measure system RAM in MiB, not GiB, and running out of RAM is a real concern, so I need to be able to track every single byte that's used. I need to be able to look at my high-level code and have a pretty good guess at what kind of assembly will be generated from it (and be able to debug with the two interleaved to confirm those guesses). I need to be able to treat memory as bytes and use memcpy. I need to be able to read data off disk and cast it to known structures without parsing/deserializing it. I have to make a lot of low-level optimizations, and make heavy use of the "pay for what you use" idea.

I also need to be able to support a productive "game programming" language, such as Lua or C#, but that comes after getting the foundations right wink.png


#1Hodgman

Posted 30 December 2012 - 07:03 PM

I disagree. It should be pretty conclusive at this point that (for the general case) 'pay for what you use' has decided detriments to productivity that arise from adapting the limited functionality to the different 'paid' functionality without providing meaningful optimization/performance benefits (in the general case).

Yeah, in the general case (whatever that is, I imagine writing corporate GUIs...), C++ isn't productive.

 

However, "pay for what you use" is exactly what makes C++ the most productive choice for the small sub-set of problems where it is (one of) the most productive language to choose from.

e.g. If it didn't have manual memory management, then it would be a very unproductive choice in memory-constrained embedded systems. Manual memory management (the fact memory isn't abstracted away, and a GC forced upon you) is a key feature of the language that enhances it's productivity (in the specific case)!


PARTNERS