While I certainly agree that maintaining the normal semantics of operators is very important, I'm not entirely sure I agree with your specific counterexamples here.
Overloading assignment is probably a necessary evil in a language as flexible as C++, because in general it's not clear whether you should deep or shallow copy any data members. The meaning of assignment in C++ generally varies with the use of a class, and what assignment implies (if it's not simply a direct copy of a value type) really has to be described as part of a class's interface documentation. Of course, you can argue that other languages are better because they do not allow this level of complexity, and thus avoid the problem. Others would then argue that other languages are worse because they do not allow that level of flexibility, and thus miss the opportunities. And before anyone says it, yes, auto_ptr is frankly weird, and yes, its bizarre semantics are responsible for a few of the biggest screw-ups in C++.
Much the same goes for casting operators. You can argue -- and I might well agree with you -- that implicit conversions are basically a Bad Thing, causing more trouble than they are worth. However, given that they exist in C++, you basically need casting operators and/or conversion constructors for much the same reasons that you need overloaded assignment.
Somebody should have slapped Stroustrup good and hard for overloading the left and right shift operators to be cute.
I don't know if it was originally his idea, but yes, the perp should indeed be slapped good and hard. However, they should be slapped mostly because the whole I/O streams structure that results codifies what should be data, and thus fundamentally inhibits portability where string translation matters. A stupid use of operator overloading, truly heinous crime that it may be, is not really on the same level.
I know religious wars are traditional here on Slashdot, but saying that Python is better than Java, or that Java is better than Python, well, it's like saying Audis are better than BMW's.
But Audis are better than BMWs...;-)
Seriously, though, I disagree with your claim about personal taste in programming languages. Of course personal preferences matter, but there can be objective differences between languages: some have stronger underlying models, in the sense of providing better abstraction tools, for example. Given what we know of programmer behaviour, a language that provides a more concise representation of a problem will, other things being equal, be a more productive tool.
In the particular case of Java vs. Python, I'm not sufficiently expert to identify all the significant differences. However, in general, while all Turing-complete languages may be isomorphic on some level, they certainly are not all equal as development tools.
Many Python programmers are (often former) Perl programmers who are fed up with Perl's expressiveness (i.e., TMTOWTDI).
/me points to current.sig and smiles quietly.:-)
The white space thing is virtually a non-issue.
To an extent, I agree; personally I find languages like C and Java over-punctuated. However, I think the grandparent made a valid point that to get good readability you (or at least, he and I) often want to line up related code fragments vertically, which may be inhibited if whitespace serves a punctuation role. Visible punctuation does serve a useful purpose in moderation!:-)
It never ceases to amaze me when languages take something simple like applying a function to everything in a collection, and clutter it up with objects, blocks and/or iterators. What's more amazing is how many people think doing so is clever...
The standard library of Java is, IMHO, one of the strongest around.
The standard library of Java is, IMHO, one of the largest around. However, that is not at all the same thing.
The collections libraries you mention, for example, have a reasonable underlying model (though nothing special that I've ever seen) but often rather inelegant syntax. Unfortunately, that's a bit of a trademark for Java, the platform where 17.6 layered objects are needed to input a string from STDIN.:-)
As you say, there are myriad redundancies and confusing aspects to the Java libraries. They "evolved" too fast, without the kind of peer review and developer culture that supports other examples as diverse as Perl's CPAN and C++'s Boost. Consequently, for many things there aren't really any standards; you have a variety of mediocre options, where it would have been much better had there been just one choice that was well-designed from the start.
Why not write a function that takes the two args? This way a maintainer will not see a - b; and just pass on by, they will see something like subdate(a, b); with the next logical step for a maintainer obviously being to check the function subdate() see what it does, and what value it returns.
Because the approach doesn't scale, that's why.
To use an obvious example of sensible operator overloading, suppose I'm working with mathematical matrices and vectors, with the * and + operators overloaded in the usual mathematical sense of matrix multiplication and addition. A typical multiply-and-add on a vector x (as in M*x+y) could be written like this:
Add(Multiply(M, x), y)
Or it could be written as... oh, wait, I already showed you the version with operator overloading.
There is no doubt in my mind -- as someone who uses mathematical concepts with overloaded operators in C++ all day -- that a judicious use of overloading can make for much more readable code than the unnatural, prefixified mess you get without it. Just don't overload operator^ to mean "to the power of", because that's not what that operator means in C++, and the precedence is wrong as a result; trying to force new meanings on operators (cout << "Ahem!") is when it all goes wrong. Otherwise, why not use the natural, obvious notation, and save functions for more specialised things that don't have ready-made natural notations, like Inv or Det in the matrix example?
You can make a similar case for many uses of op-overloading in mathematical contexts, for container classes (using operator[] in C++), for pointer-style classes (using operator* and operator->), and so on. Used sparingly and in the right context, they make things much easier to read, and indeed decrease the learning curve as a result.
While it may be true that idiots and beta software don't mix, Microsoft has actively adjusted the meaning of the term "beta" well beyond a last round of testing before release. Sending beta software out the door, even charging for it, is now their standard MO.
Now, that's a business decision, and if their customers are prepared to accept it, fair enough. However, if you're going to treat betas as real products like that, you have to support them as such as well. For a start, that means not sending something out via auto-update that isn't compatible with a beta but tries to install itself anyway and screws a system up as a result.
What's happening at present is that MS is just releasing everything as a beta, which is a cheap excuse for shipping sub-standard, unsupported software and then passing the buck if anything goes wrong. You can't do that and then not expect to take a PR hit when, inevitably, something does.
If you'd bothered to read the links -- which apparently I was far from the only person to find and submit earlier -- you'd have found plenty of hard information supporting those statistics. Ignore the BBC link and go straight to SANS to start with.
I was using xfig yesterday to prepare figures for a new paper. My coauthor in Australia has limited bandwidth; I used ps2pdf to turn the postscript file to a pdf file for her.
That's funny, I was using the same tools on Windows XP just the other day.
SMS' to "premium numbers" are annoying and don't require massive mobile bandwith to work.
They do, however, require both the programmable technology to install/run and, in this case, the user to deliberately acknowledge the existence of something installing/running. You have been told.:-)
I think the point is that we are starting to see a return of 'perks' as an incentive for talent as the job market gets better.
But what kind of perks? You can separate several distinct types:
Flexi-time is a good bet in this industry: it's of great value to many employees, and costs the employer almost nothing (and they probably more than recoup whatever they lose in increased productivity anyway).
Share options are the other way around: they may have great value to the employee, or they may have none at all, but they could cost the company significantly. They can still be worth something -- I've just made a little on some for the first time -- but I doubt many people would consider them much of a perk after what happened post-.com-boom, unless getting in early with a very promising start-up.
Health care, gym membership, etc. are somewhere in the middle: they may have a value to some employees, but probably quite a few would rather just have the money to spend as they want instead. I've never really understood this kind of perk.
As an employee, things like flexitime and "pillow days" are great for me. Options are nice as-well-as but not instead-of your regular package -- I'd be very unlikely to accept a below-par salary/bonus package in exchange for options. I have no interest in the third kind of perk, and would much rather have the money to spend on my first home, since houses are ludicrously expensive around here.
I'm not sure this discussion makes much sense until you've identified what sort of thing you're going to call a "perk".
I'd mod you guys informative if I weren't posting; I've been looking for a good way to do this for ages. (In fact, a separate FAT32 partition for data exists on my hard drive precisely so when I finally install a serious version of Linux, I can do this sort of thing.)
Unfortunately, AFAICS, the approach on texturizer.net still leaves you with two separate copies of prefs.js, which aren't in sync. Your mail folders might be in the same place, which is certainly a good start, but I suspect some (but not all) of the other preferences should also be shared; I can't imagine wanting anything other than the UI-related stuff to be different on the two platforms. That's obviously going to be more work for the development guys, so I can understand why it hasn't happened, but hopefully at some point the number of us dual-booting will be significant enough to justify a more complete solution to this problem.
FWIW, I imported all my folders from Outlook 2002 into Thunderbird 0.7.1 pretty effortlessly at work. I can't comment on the address books, filtering rules and so on, because part of the reason for moving was that Outlook is just plain screwed up in the number of bugs it has in these two areas, so I deliberately started from scratch in TBird.
No, taint is a great feature, at least up to a point. It's certainly a good idea, and it (particularly the way you untaint things) fits in pretty well with the general framework of the language. There are a couple of problems with taint mode, though.
Firstly, it's not obligatory. Now, you can reasonably argue that any competent Perl programmer will switch it on where it's needed, as indeed we (my colleagues and I) would, and that making it obligatory would be operate against the convenience of Perl and its TMTOWTDI philosophy. However, you can likewise argue that any competent C++ programmer will never suffer from buffer over-runs or memory leaks since the idioms to avoid them are common knowledge amongst such developers, or that anyone competent to write scripts to drive databases won't allow SQL injection because they'll always prepare their statements and filter everything first. Unfortunately, personal experience suggests that the majority of programmers actually aren't all that competent; they can get the basics done, but the difference in knowledge and ability between them and a good (not even expert) programmer is very significant. If anything, Perl suffers worse from this, because you can (and many people do) easily pick up just the basics from looking at a few sample scripts and scanning the introductory electronic docs, without ever realising that taint mode even exists.
Secondly, even when switched on, it isn't completely foolproof. See the problem of using exec with a list, for example.
And of course, not all languages with eval functionality support a taint mode; in fact, AFAIK this is unique to Perl at present.
The problems of code injection
on
Gosling on Computing
·
· Score: 4, Interesting
Once they do that we'll only have to worry about stuff like SQL injection (which can result in execution of arbitrary code), which can be reduced/near eliminated by making people use prepared statements.
Yep, that's a serious problem, and one that gets far less "press" than the sort of buffer over-run vulnerabilities you get in careless C or C++.
The one that always astounds me is that languages with an eval-type statement -- that is, ones which can parse and execute an arbitrary string at run-time -- don't get slated for their security problems way more often. We use Perl to write CGI scripts all the time, and its variable interpolation can be waaaaay more dangerous than any potential pointer nasties in C!
It's notable that Java does not have such a function. It does, however, have the usual problem with allowing arbitrary strings to be interpreted as statements through its SQL API, but given the nature of SQL I'm not sure how realistic it is to address that anyway...
The 4MB size of the complete Mozilla browser is smaller than many of Microsoft's IE updates have been.
Sure, but tell that to the poor guy who's using a 56k modem to download it, and has finite on-line time in a month before it starts costing him more. Not everyone has broadband, not by a long shot.
Even without that, the hassle of the updating process is just too much for your average user -- or even most power user geeks -- to put up with for long.
I think the problem with TA:Kingdoms was simply the gameplay.
In fairness, it had a lot to live up to. The original TA was, at the time, in a class of its own in terms of unit diversity, simple but effective resource system, tech trees, etc. By taking the name, we expected similar things from TA:Kingdoms, but somehow it just never had the same "bang" factor.
In TA, there was always that moment of horror the first time a superior opponent managed to build a group of level 2 units, and they appeared on the edge of your base and started taking out your HLTs before you had any serious firepower to counter them. In TA, when I'm hitting an area hard, I get an image of devastation, as provided by a nuke making it through, or better still several heavy artillery units pounding a base from half a screen away in a desperate race against the superior air force your foe is sending to take them out. When I'm building a base, I want the satisfaction of seeing all his little level one lemmings coming into range just as my Annihilator is completed, and then watching a whole attack wave wiped out as my investment in the right unit at the right time pays off.
TA:Kingdoms just doesn't have any of this. It had so much potential. I'm a fan of "sword and sorcery", and of RTSes in general, and was eagerly awaiting it. And then what did I get? I got a cannon tower with all the punching power of a five year old to guard my castle, armies full of units who couldn't fight unless they could get on top of the other guy, and an interesting spell system that somehow never quite worked. There should have been awesome battles as my knights rode out to fight the wizard unleashing fireballs and ice storms upon -- or maybe over -- the walls of my castle. Instead, we got rather limp hack and slash. They seemed to be on the right lines, as magical units could to some extent have their automatic behaviour coded in, but they just weren't smart enough and if you left one in the wrong place for a couple of seconds, a baby would come and eat it. Whatever it is that makes a great game, TA had it, and TA:Kingdoms somehow didn't.
I'm still waiting for my "perfect" RTS, but one thing that's certain is that the gameplay will be far more important than the fine details of graphics and sound. Personally, I'd go for something either high-tech or mythical with a few key features:
I want lots of cheap small units, but relatively few more powerful ones. Let the small ones do their thing like the lemmings they are, while the large ones have a genuine aura of power about them. Give me an awesome array of spells, or a combination of short- and long-range firepower with different weapons effective against land/air. Make strategy matter. (The hero idea in Warcraft III wasn't bad, but they only ever really had a couple in play at once. I want a whole level 2/level 3 complement of such units, which are expensive enough that you can't just throw them away against an opponent who doesn't, but cheap enough that my enemy can tremble with fear as he hears a rumble behind him, turns, and sees five supertanks roaring over the hilltop behind his base.
I want serious formation/grouping control, so I can actually use some strategy and combinations of units that make a difference. The original TA wasn't bad in this respect -- you could group units, and so on -- but it was naive when it came to, for example, sending heavy tanks in with lightweight escorts. They either overtook them in seconds and left them behind, or had to guard them, so stopping and becoming sitting ducks if the big tank died. Some of the games using fewer units have gotten quite smart with this, and it would be good to see a similar level of strategy usable in a large-scale game. Of course, it would need to be possible without having to micro-manage everything...
And here's the killer, that no-one's done yet: I want genuine configurability for the unit orders -- if a FPS can use scripting, why on earth can't we have simple scripts to determine target prio
Deus Ex seemed like quite a good game when I bought it, a little while after it came out so my hardware at the time could keep up. For me, it always suffered just a bit too much from the "one wrong move..." problem; I was always worried about doing something simple that was wrong, and never being able to recover from it, so I suspect I never committed to things I should have done to make progress. (Yeah, I hoard all the power-ups in every RPG game so I've got far too many by the final level, too.) Anyone else find that a problem in games? Am I just too cautious to do well in a game like Deus Ex? Is the game just too long for me?
That was the thing that stopped me playing NWN, too; after a fair few hours, I made the wrong comment in a conversation, somebody stopped talking to me so I apparently couldn't finish something, and I never bothered to reload a saved game from 10 hours earlier before that fateful error...
... I can keep going back to Starcraft and Warcraft II when I need a gaming fix.
And may I be the first (second? tenth?) to say "Well, Starcraft was OK, but I always preferred Total Annihilation". I still dig the latter out for a good ol' RTS FutureTankFest every now and then, and I've always regretted not buying the Core Contingency expansion pack when it was still available.
I bought Warcraft III after reading rave reviews, too, but I have to say it was up there with Neverwinter Nights on the "So what was all the hype about?" scale. I did play through the Baldur's Gate series several times, though...
I am employed, like many here, as a creative professional. I'm mostly paid to fill in the details around ideas that my employer and their clients come up with, but I am also kept on staff in the hopes that I will come up with new ideas that can be of value to my employer. Any firm that creates products or IP wants creative new ideas, and the design staff is supposed to come up with them.
Sure, of course that's a part of the equation, and a company is entitled to expect that an employee they pay to be creative does create something for them.
However, they are not entitled to expect everything the employee creates, whether or not related to their role at the office. The problem usually comes when someone decides to use an overly broad interpretation of "related to their role": if you develop word processing software in your company, the employee's state-of-the-art 3D rendering engine is not related to work, even if both are written in C++.
As an aside, I have similar reservations about "non-compete" termination clauses, where when I leave I can't work for a competitor. Again, some employers try to use that as an unfair lever, claiming that because you learned Java at their company, you can't take on any Java-related work for six months after leaving, even if the actual application is completely different. Here again, there are reasonable alternatives; an employer providing extensive and expensive training might reasonably say that if you leave within x months of taking that training, you have to repay y% of the costs they incurred.
Ultimately, this is all about the balance between a human being's default right to take advantage of everything they create, and an employer's right to a fair day's work in exchange for a fair day's pay. It's perfectly possible to balance this equation, but employers who try to skew it dramatically to their side are just asking for all the good people to leave.
If he realy had this idea prior to signing he should have listed it as an exception.
The point is that he shouldn't have to list exceptions. The default should be that the company owns what it specifically claims in your contract, not that you own what you specifically claim.
Slashdot Mirror
Transparency is a prerequisite for readability.
(In a programming context, I define readability as being easy to read with the correct understanding.)
While I certainly agree that maintaining the normal semantics of operators is very important, I'm not entirely sure I agree with your specific counterexamples here.
Overloading assignment is probably a necessary evil in a language as flexible as C++, because in general it's not clear whether you should deep or shallow copy any data members. The meaning of assignment in C++ generally varies with the use of a class, and what assignment implies (if it's not simply a direct copy of a value type) really has to be described as part of a class's interface documentation. Of course, you can argue that other languages are better because they do not allow this level of complexity, and thus avoid the problem. Others would then argue that other languages are worse because they do not allow that level of flexibility, and thus miss the opportunities. And before anyone says it, yes, auto_ptr is frankly weird, and yes, its bizarre semantics are responsible for a few of the biggest screw-ups in C++.
Much the same goes for casting operators. You can argue -- and I might well agree with you -- that implicit conversions are basically a Bad Thing, causing more trouble than they are worth. However, given that they exist in C++, you basically need casting operators and/or conversion constructors for much the same reasons that you need overloaded assignment.
I don't know if it was originally his idea, but yes, the perp should indeed be slapped good and hard. However, they should be slapped mostly because the whole I/O streams structure that results codifies what should be data, and thus fundamentally inhibits portability where string translation matters. A stupid use of operator overloading, truly heinous crime that it may be, is not really on the same level.
And how much of that is valid where beta products are concerned?
But Audis are better than BMWs... ;-)
Seriously, though, I disagree with your claim about personal taste in programming languages. Of course personal preferences matter, but there can be objective differences between languages: some have stronger underlying models, in the sense of providing better abstraction tools, for example. Given what we know of programmer behaviour, a language that provides a more concise representation of a problem will, other things being equal, be a more productive tool.
In the particular case of Java vs. Python, I'm not sufficiently expert to identify all the significant differences. However, in general, while all Turing-complete languages may be isomorphic on some level, they certainly are not all equal as development tools.
/me points to current .sig and smiles quietly. :-)
To an extent, I agree; personally I find languages like C and Java over-punctuated. However, I think the grandparent made a valid point that to get good readability you (or at least, he and I) often want to line up related code fragments vertically, which may be inhibited if whitespace serves a punctuation role. Visible punctuation does serve a useful purpose in moderation! :-)
Ruby:
Thanks, but I'll take
or, if you prefer,
It never ceases to amaze me when languages take something simple like applying a function to everything in a collection, and clutter it up with objects, blocks and/or iterators. What's more amazing is how many people think doing so is clever...
The standard library of Java is, IMHO, one of the largest around. However, that is not at all the same thing.
The collections libraries you mention, for example, have a reasonable underlying model (though nothing special that I've ever seen) but often rather inelegant syntax. Unfortunately, that's a bit of a trademark for Java, the platform where 17.6 layered objects are needed to input a string from STDIN. :-)
As you say, there are myriad redundancies and confusing aspects to the Java libraries. They "evolved" too fast, without the kind of peer review and developer culture that supports other examples as diverse as Perl's CPAN and C++'s Boost. Consequently, for many things there aren't really any standards; you have a variety of mediocre options, where it would have been much better had there been just one choice that was well-designed from the start.
Because the approach doesn't scale, that's why.
To use an obvious example of sensible operator overloading, suppose I'm working with mathematical matrices and vectors, with the * and + operators overloaded in the usual mathematical sense of matrix multiplication and addition. A typical multiply-and-add on a vector x (as in M*x+y) could be written like this:
Or it could be written as... oh, wait, I already showed you the version with operator overloading.
There is no doubt in my mind -- as someone who uses mathematical concepts with overloaded operators in C++ all day -- that a judicious use of overloading can make for much more readable code than the unnatural, prefixified mess you get without it. Just don't overload operator^ to mean "to the power of", because that's not what that operator means in C++, and the precedence is wrong as a result; trying to force new meanings on operators (cout << "Ahem!") is when it all goes wrong. Otherwise, why not use the natural, obvious notation, and save functions for more specialised things that don't have ready-made natural notations, like Inv or Det in the matrix example?
You can make a similar case for many uses of op-overloading in mathematical contexts, for container classes (using operator[] in C++), for pointer-style classes (using operator* and operator->), and so on. Used sparingly and in the right context, they make things much easier to read, and indeed decrease the learning curve as a result.
While it may be true that idiots and beta software don't mix, Microsoft has actively adjusted the meaning of the term "beta" well beyond a last round of testing before release. Sending beta software out the door, even charging for it, is now their standard MO.
Now, that's a business decision, and if their customers are prepared to accept it, fair enough. However, if you're going to treat betas as real products like that, you have to support them as such as well. For a start, that means not sending something out via auto-update that isn't compatible with a beta but tries to install itself anyway and screws a system up as a result.
What's happening at present is that MS is just releasing everything as a beta, which is a cheap excuse for shipping sub-standard, unsupported software and then passing the buck if anything goes wrong. You can't do that and then not expect to take a PR hit when, inevitably, something does.
If you'd bothered to read the links -- which apparently I was far from the only person to find and submit earlier -- you'd have found plenty of hard information supporting those statistics. Ignore the BBC link and go straight to SANS to start with.
That's funny, I was using the same tools on Windows XP just the other day.
I'll take that bet... But then I actually read the comments at the SANS site before submitting this story. :-)
They do, however, require both the programmable technology to install/run and, in this case, the user to deliberately acknowledge the existence of something installing/running. You have been told. :-)
But what kind of perks? You can separate several distinct types:
As an employee, things like flexitime and "pillow days" are great for me. Options are nice as-well-as but not instead-of your regular package -- I'd be very unlikely to accept a below-par salary/bonus package in exchange for options. I have no interest in the third kind of perk, and would much rather have the money to spend on my first home, since houses are ludicrously expensive around here.
I'm not sure this discussion makes much sense until you've identified what sort of thing you're going to call a "perk".
I'd mod you guys informative if I weren't posting; I've been looking for a good way to do this for ages. (In fact, a separate FAT32 partition for data exists on my hard drive precisely so when I finally install a serious version of Linux, I can do this sort of thing.)
Unfortunately, AFAICS, the approach on texturizer.net still leaves you with two separate copies of prefs.js, which aren't in sync. Your mail folders might be in the same place, which is certainly a good start, but I suspect some (but not all) of the other preferences should also be shared; I can't imagine wanting anything other than the UI-related stuff to be different on the two platforms. That's obviously going to be more work for the development guys, so I can understand why it hasn't happened, but hopefully at some point the number of us dual-booting will be significant enough to justify a more complete solution to this problem.
Which mail client were you using before?
FWIW, I imported all my folders from Outlook 2002 into Thunderbird 0.7.1 pretty effortlessly at work. I can't comment on the address books, filtering rules and so on, because part of the reason for moving was that Outlook is just plain screwed up in the number of bugs it has in these two areas, so I deliberately started from scratch in TBird.
No, taint is a great feature, at least up to a point. It's certainly a good idea, and it (particularly the way you untaint things) fits in pretty well with the general framework of the language. There are a couple of problems with taint mode, though.
Firstly, it's not obligatory. Now, you can reasonably argue that any competent Perl programmer will switch it on where it's needed, as indeed we (my colleagues and I) would, and that making it obligatory would be operate against the convenience of Perl and its TMTOWTDI philosophy. However, you can likewise argue that any competent C++ programmer will never suffer from buffer over-runs or memory leaks since the idioms to avoid them are common knowledge amongst such developers, or that anyone competent to write scripts to drive databases won't allow SQL injection because they'll always prepare their statements and filter everything first. Unfortunately, personal experience suggests that the majority of programmers actually aren't all that competent; they can get the basics done, but the difference in knowledge and ability between them and a good (not even expert) programmer is very significant. If anything, Perl suffers worse from this, because you can (and many people do) easily pick up just the basics from looking at a few sample scripts and scanning the introductory electronic docs, without ever realising that taint mode even exists.
Secondly, even when switched on, it isn't completely foolproof. See the problem of using exec with a list, for example.
And of course, not all languages with eval functionality support a taint mode; in fact, AFAIK this is unique to Perl at present.
Yep, that's a serious problem, and one that gets far less "press" than the sort of buffer over-run vulnerabilities you get in careless C or C++.
The one that always astounds me is that languages with an eval-type statement -- that is, ones which can parse and execute an arbitrary string at run-time -- don't get slated for their security problems way more often. We use Perl to write CGI scripts all the time, and its variable interpolation can be waaaaay more dangerous than any potential pointer nasties in C!
It's notable that Java does not have such a function. It does, however, have the usual problem with allowing arbitrary strings to be interpreted as statements through its SQL API, but given the nature of SQL I'm not sure how realistic it is to address that anyway...
Sure, but tell that to the poor guy who's using a 56k modem to download it, and has finite on-line time in a month before it starts costing him more. Not everyone has broadband, not by a long shot.
Even without that, the hassle of the updating process is just too much for your average user -- or even most power user geeks -- to put up with for long.
I think the problem with TA:Kingdoms was simply the gameplay.
In fairness, it had a lot to live up to. The original TA was, at the time, in a class of its own in terms of unit diversity, simple but effective resource system, tech trees, etc. By taking the name, we expected similar things from TA:Kingdoms, but somehow it just never had the same "bang" factor.
In TA, there was always that moment of horror the first time a superior opponent managed to build a group of level 2 units, and they appeared on the edge of your base and started taking out your HLTs before you had any serious firepower to counter them. In TA, when I'm hitting an area hard, I get an image of devastation, as provided by a nuke making it through, or better still several heavy artillery units pounding a base from half a screen away in a desperate race against the superior air force your foe is sending to take them out. When I'm building a base, I want the satisfaction of seeing all his little level one lemmings coming into range just as my Annihilator is completed, and then watching a whole attack wave wiped out as my investment in the right unit at the right time pays off.
TA:Kingdoms just doesn't have any of this. It had so much potential. I'm a fan of "sword and sorcery", and of RTSes in general, and was eagerly awaiting it. And then what did I get? I got a cannon tower with all the punching power of a five year old to guard my castle, armies full of units who couldn't fight unless they could get on top of the other guy, and an interesting spell system that somehow never quite worked. There should have been awesome battles as my knights rode out to fight the wizard unleashing fireballs and ice storms upon -- or maybe over -- the walls of my castle. Instead, we got rather limp hack and slash. They seemed to be on the right lines, as magical units could to some extent have their automatic behaviour coded in, but they just weren't smart enough and if you left one in the wrong place for a couple of seconds, a baby would come and eat it. Whatever it is that makes a great game, TA had it, and TA:Kingdoms somehow didn't.
I'm still waiting for my "perfect" RTS, but one thing that's certain is that the gameplay will be far more important than the fine details of graphics and sound. Personally, I'd go for something either high-tech or mythical with a few key features:
Deus Ex seemed like quite a good game when I bought it, a little while after it came out so my hardware at the time could keep up. For me, it always suffered just a bit too much from the "one wrong move..." problem; I was always worried about doing something simple that was wrong, and never being able to recover from it, so I suspect I never committed to things I should have done to make progress. (Yeah, I hoard all the power-ups in every RPG game so I've got far too many by the final level, too.) Anyone else find that a problem in games? Am I just too cautious to do well in a game like Deus Ex? Is the game just too long for me?
That was the thing that stopped me playing NWN, too; after a fair few hours, I made the wrong comment in a conversation, somebody stopped talking to me so I apparently couldn't finish something, and I never bothered to reload a saved game from 10 hours earlier before that fateful error...
And may I be the first (second? tenth?) to say "Well, Starcraft was OK, but I always preferred Total Annihilation". I still dig the latter out for a good ol' RTS FutureTankFest every now and then, and I've always regretted not buying the Core Contingency expansion pack when it was still available.
I bought Warcraft III after reading rave reviews, too, but I have to say it was up there with Neverwinter Nights on the "So what was all the hype about?" scale. I did play through the Baldur's Gate series several times, though...
Sure, of course that's a part of the equation, and a company is entitled to expect that an employee they pay to be creative does create something for them.
However, they are not entitled to expect everything the employee creates, whether or not related to their role at the office. The problem usually comes when someone decides to use an overly broad interpretation of "related to their role": if you develop word processing software in your company, the employee's state-of-the-art 3D rendering engine is not related to work, even if both are written in C++.
As an aside, I have similar reservations about "non-compete" termination clauses, where when I leave I can't work for a competitor. Again, some employers try to use that as an unfair lever, claiming that because you learned Java at their company, you can't take on any Java-related work for six months after leaving, even if the actual application is completely different. Here again, there are reasonable alternatives; an employer providing extensive and expensive training might reasonably say that if you leave within x months of taking that training, you have to repay y% of the costs they incurred.
Ultimately, this is all about the balance between a human being's default right to take advantage of everything they create, and an employer's right to a fair day's work in exchange for a fair day's pay. It's perfectly possible to balance this equation, but employers who try to skew it dramatically to their side are just asking for all the good people to leave.
The point is that he shouldn't have to list exceptions. The default should be that the company owns what it specifically claims in your contract, not that you own what you specifically claim.