Lots of people seem to be of the opinion that the "length" of a game from start to finish should somehow stack up against the price. I disagree. I think the amount of time spent playing is more important. Unreal Tournament: length of a single "game" is less than ten minutes. I've played this game for many many hours.
Civilization 4: length of a single "game" is longer (depending on settings too), from a few hours to 20 hours for a marathon game. Again, I've played this game for countless days.
The length "problem" is a problem only if replay value is bad. This can have several causes: very linear game play with no options - why would you play it again? Or non-linear game play, but long dull segments you cannot avoid - it's not enough fun to play again. I personally do not like a lot of "long" games (games that take a long time for a single play-through). I did not get through Zelda: Twilight Princess, bailed on the Baldur's Gate PC RPGs half way through, etc., because at a certain point I had seen all the gameplay and it no longer captured my interest. I played 10 minutes of a Final Fantasy demo one time, and it already bored me to tears with its gameplay, and nothing could entice me to keep going just for the story. If I want a great story, I'll read a great book instead - because nearly all of the time those stories are much better than even the best in computer games.
A Slideshow of artwork could have been presented by Romero with a multiple-choice question on how to continue, and it would still be cooler than Doom3.
And no matter how many times you tell management this, they will continue to prefer to pay the higher cost later.
Because the earlier ship date may make them more money by the extra sales and potentially cornering the market early than the "higher" cost to fix the remaining bugs later.
Or, the old simple adage: "Do you want it good? Or do you want it thursday?".
(Which I actually picked up from a musical composer, not a software developer....)
Colleague of mine used to have the following sig: "Write code as if the person who will be maintaining it is a violent psychopath who knows where you live."
The example of your mother, whilst valid, does not counter my argument - as you said yourself, she's never been proficient with computers, therefore I could only agree that she finds it easier to use.
You are thinking about this in the wrong direction - years of mouse and keyboard (ab)use have trained us to completely miss what is truly "easy to use". Do you remember first learning to type? I do, it was hell with lots of repetition to get any kind of speed (touch typing). Do you remember first learning to use a mouse? I do - it didn't make spatial sense at all for a good while. Do you remember learning how to drive stick shift? I do - it was one of the most strangely hard things I've ever done.
Now think of predictive texting - T9. Do you "get" that? I sure don't! I think it's a royal pain in the ass, and I HATE the fact that my "smart" internet TV requires me to use that abomination to enter text without supporting USB or wireless keyboards. Yet all around me are teenagers getting WPM counts close to my touch typing on these things, and they think I'm a fossil that doesn't get it.
After all those years of use, many hard things are now completely second nature to us. We don't think of them as difficult or even easy, they are just facts of life. However if I think back honestly I cannot claim that these things were easy to learn.
My two-year old cousin was playing with an iPad. He "got it" almost immediately. He's *two years old*. No matter how much we detest these gimmicky things because we can do so much with our keyboards and mice, they really are simpler to use with much less training.
That's the old JIT argument, and while in theory it might have some merit, in the last decade it shown not to.
Hence the "mostly academic" heading of my post. You agree with me that in theory a JIT compiler could be faster, thus C++ is not "necessarily" faster, but "practically" it is (when the code is well-written).
It may be unintuitive and a mostly academic argument, but you are wrong - C++ is always necessarily compiled to a set of specific hardware targets which may be sub-optimal for the actual hardware the program is executed on. A JIT-compiled language can target the actual machine you are running on, enabling more specific optimizations. A JIT-compiled program may also end up running faster than before as the JIT-compiler is upgraded, on the same machine, without any action of the original program developer.
On a whole I think most programs nowadays should be written in a managed language; the performance gap just doesn't matter for most things.
I've been developing professionally (disclaimer: in C++;-) ) for 10 years now, I've put up with people saying exactly this for 10 years, and for 10 years it hasn't been generally true at all.
I don't mean to say managed languages have no place - I love using Python for scripting, and we've started doing GUI work in C#/.Net (oh no!) at my company as well, but there's always a dark performance corner where you end up having to go back to a language that gives you more low-level control. The performance gap doesn't matter in "some" things, but it matters at least once in every project I have worked on.
More technically specific:
malloc() can't hope to be in that same league
So you write custom memory allocators for the specific cases that you need that perform better than malloc or indeed the generic allocator of any managed language. Note "allocators" - plural, we have more than one custom allocator for specific cases. I absolutely concur with Google though that this is "at a level of sophistication that would not be available to the average programmer.'"
You know, that sounds like the argument Microsoft developers were making for years and years, until with Windows Vista Microsoft finally admitted that "run all apps as admin" was a lousy idea and implemented UAC (and there was much wailing and gnashing of teeth).
App Developers should write their apps to use the smallest possible amount of permissions to provide the user experience needed, instead of performing a permissions "land grab" just in case. The default should be "you don't have access to anything", and getting more access should require asking really really nicely.
If the app crashes / shuts down / otherwise fails miserably because it's trying, for example, to write temporary files to a system folder, or anything else that should NOT be expected of a well-behaved app, the app developer deserves every single last awful review they get. Getting to the point where developers actually think about that stuff requires transitioning through a period of pain - just like the Windows Vista failure which actually turned into a success by changing a few colours and calling it "Windows 7" (slight exaggeration possible;-) ).
Slashdot Mirror
Lots of people seem to be of the opinion that the "length" of a game from start to finish should somehow stack up against the price. I disagree. I think the amount of time spent playing is more important. Unreal Tournament: length of a single "game" is less than ten minutes. I've played this game for many many hours. Civilization 4: length of a single "game" is longer (depending on settings too), from a few hours to 20 hours for a marathon game. Again, I've played this game for countless days.
The length "problem" is a problem only if replay value is bad. This can have several causes: very linear game play with no options - why would you play it again? Or non-linear game play, but long dull segments you cannot avoid - it's not enough fun to play again. I personally do not like a lot of "long" games (games that take a long time for a single play-through). I did not get through Zelda: Twilight Princess, bailed on the Baldur's Gate PC RPGs half way through, etc., because at a certain point I had seen all the gameplay and it no longer captured my interest. I played 10 minutes of a Final Fantasy demo one time, and it already bored me to tears with its gameplay, and nothing could entice me to keep going just for the story. If I want a great story, I'll read a great book instead - because nearly all of the time those stories are much better than even the best in computer games.
A Slideshow of artwork could have been presented by Romero with a multiple-choice question on how to continue, and it would still be cooler than Doom3.
As evidenced by the roaring success of Daikatana.
Just imagine the bragging rights when you can say "I picked up an ultracool brown dwarf on my way to Sirius".
Heads, I win.
Tails, you lose.
For the low, low price of $0.02 per buzzword, you can buy access to the buzzword explanation!
Those people, who ordinarily would keep their faith to themselves, get pissed off at the trolls and fight back.
Who are you to judge that this Pastafarian doesn't actually believe the tenets of his religion? Who is truly mocking who here?
google sought a green light from sun
Not surprising they didn't get it, since sun's light is white.
And no matter how many times you tell management this, they will continue to prefer to pay the higher cost later.
Because the earlier ship date may make them more money by the extra sales and potentially cornering the market early than the "higher" cost to fix the remaining bugs later.
Or, the old simple adage: "Do you want it good? Or do you want it thursday?".
(Which I actually picked up from a musical composer, not a software developer....)
Ohh, and it does what the customer expected...or was that part optional?
What? Fart butterflies, magically deduce what they actually wanted to do and print money at the same time?
Colleague of mine used to have the following sig: "Write code as if the person who will be maintaining it is a violent psychopath who knows where you live."
The example of your mother, whilst valid, does not counter my argument - as you said yourself, she's never been proficient with computers, therefore I could only agree that she finds it easier to use.
You are thinking about this in the wrong direction - years of mouse and keyboard (ab)use have trained us to completely miss what is truly "easy to use". Do you remember first learning to type? I do, it was hell with lots of repetition to get any kind of speed (touch typing). Do you remember first learning to use a mouse? I do - it didn't make spatial sense at all for a good while. Do you remember learning how to drive stick shift? I do - it was one of the most strangely hard things I've ever done.
Now think of predictive texting - T9. Do you "get" that? I sure don't! I think it's a royal pain in the ass, and I HATE the fact that my "smart" internet TV requires me to use that abomination to enter text without supporting USB or wireless keyboards. Yet all around me are teenagers getting WPM counts close to my touch typing on these things, and they think I'm a fossil that doesn't get it.
After all those years of use, many hard things are now completely second nature to us. We don't think of them as difficult or even easy, they are just facts of life. However if I think back honestly I cannot claim that these things were easy to learn.
My two-year old cousin was playing with an iPad. He "got it" almost immediately. He's *two years old*. No matter how much we detest these gimmicky things because we can do so much with our keyboards and mice, they really are simpler to use with much less training.
Be glad it didn't steal your porn collection. At least 2 decades of spanking the monkey down the drain in an instant.
That's the old JIT argument, and while in theory it might have some merit, in the last decade it shown not to.
Hence the "mostly academic" heading of my post. You agree with me that in theory a JIT compiler could be faster, thus C++ is not "necessarily" faster, but "practically" it is (when the code is well-written).
>
BTW, one subtle difference between C and C++ is in templates.
Subtle, yes, if "a turing-complete sub-language" is considered subtle :-)
C++ will always necessarily be faster to execute
It may be unintuitive and a mostly academic argument, but you are wrong - C++ is always necessarily compiled to a set of specific hardware targets which may be sub-optimal for the actual hardware the program is executed on. A JIT-compiled language can target the actual machine you are running on, enabling more specific optimizations. A JIT-compiled program may also end up running faster than before as the JIT-compiler is upgraded, on the same machine, without any action of the original program developer.
On a whole I think most programs nowadays should be written in a managed language; the performance gap just doesn't matter for most things.
I've been developing professionally (disclaimer: in C++ ;-) ) for 10 years now, I've put up with people saying exactly this for 10 years, and for 10 years it hasn't been generally true at all.
I don't mean to say managed languages have no place - I love using Python for scripting, and we've started doing GUI work in C#/.Net (oh no!) at my company as well, but there's always a dark performance corner where you end up having to go back to a language that gives you more low-level control. The performance gap doesn't matter in "some" things, but it matters at least once in every project I have worked on.
More technically specific:
malloc() can't hope to be in that same league
So you write custom memory allocators for the specific cases that you need that perform better than malloc or indeed the generic allocator of any managed language. Note "allocators" - plural, we have more than one custom allocator for specific cases. I absolutely concur with Google though that this is "at a level of sophistication that would not be available to the average programmer.'"
What they are saying is that ICD-10 is implemented through ID-10-T managment?
That's stretched pretty tin.
I hear the evidence was forged.
In denial?
You're still 3 times as likely to get hit by lightning and 250 times as likely to die in a fiery car crash.
Except if you're on the phone while driving.
I bet you think I do not possess the awesome skills of dryly delivered humor!
Want a real world example today? Stock market. This is why automated make-money tools don't work nearly as well as they should.
My printing press is working just fine, thanks.
Yours truly,
The Federal Reserve.
You know, that sounds like the argument Microsoft developers were making for years and years, until with Windows Vista Microsoft finally admitted that "run all apps as admin" was a lousy idea and implemented UAC (and there was much wailing and gnashing of teeth). ;-) ).
App Developers should write their apps to use the smallest possible amount of permissions to provide the user experience needed, instead of performing a permissions "land grab" just in case. The default should be "you don't have access to anything", and getting more access should require asking really really nicely.
If the app crashes / shuts down / otherwise fails miserably because it's trying, for example, to write temporary files to a system folder, or anything else that should NOT be expected of a well-behaved app, the app developer deserves every single last awful review they get. Getting to the point where developers actually think about that stuff requires transitioning through a period of pain - just like the Windows Vista failure which actually turned into a success by changing a few colours and calling it "Windows 7" (slight exaggeration possible