Slashdot Mirror

That all said, when NASA switched to the PSP and TSP, their bug rate dropped by almost 90%, and they had to generate far less documentation. Just because you have a team with an amazing record doesn't mean there isn't a better way. NASA has learned this several times.

I assume you're including the functionality of specialist preprocessors in that list, but even so you have listed a few items of which I was previously unaware. A quick Google search for lambda expressions in C++ brings up preprocessors such as Clamp, which seem rather interesting indeed.

Clamp notwithstanding, actually no: I don't consider preprocessors other than the one that's part of the language as a fair candidate for talking about what a language can do. For pure-C++ lambda, the best (though not the only) example is Boost Lambda.

That said, I have to be careful here. A while ago, I pointed out that one of the advantages of Python over Java was its mutable classes (which could also potentially be a disadvantage as well, but I digress). The person I was discussing this pointed out this wasn't the case, informing me that one could dynamically alter a class at runtime by altering the JVM bytecode. Whilst this was technically true, there's a large difference in practicality between a single line of "Foobar.new_method = method_impl", and a page of Java code manipulating the bytecode of a class.

I agree with you: whoever was discussing with you is taking what I believe to be an unreasonable stance, namely that of suggesting the alteration of the binary as a candidate for a language feature. That said, in C++ what you want to do is relatively easy to replicate, provided that if it's a function you know the signature you're calling (it's possible, but harder, if you don't;) just keep a map or a hash to Boost::Any (or if you need to be stabbed in the stomach, void pointers,) fill it with members and function pointers, and then overload operator-> .

This is why I think C++'s flexibility is vastly underrated: things like that are easy to hack, if you're comfortable with the language.

I'm interested in the compile-time metaprogramming you mention. Perhaps you could point me toward some resources?

I don't actually know of any good ones online, though I've not looked for them. By far the best example I'm aware of is the book Modern C++ Design, which is both an excellent book and which covers quite a few other tremendously powerful techniques, such as template-based policy modules, typelists and type traits, and a whole bunch of other stuff.

I'm aware of the capabilities of templates

With all due respect, I used to say the same thing, and I was just dead wrong. For example, compile-time metaprogramming is accomplished using templates. What most people don't realize - what I didn't realize until I read that book - is that templates are when carefully used in fact a fully distinct third language within C++ (the first two being c++ itself and the macro preprocessor,) and that they create a radically different environment than traditional C++ does.

Do you know of many more preprocessors like Clamp? I'm something of a language nut, and learning something new about a language I thought I was reasonably familiar with is always very interesting.

I refuse to use tools like Clamp. Just a personal thing. Besides, C++ is large enough that, despite having 7 years of heavy industrial use under my belt, I'm still learning things in it at just a remarkable rate.

That all said, I still disagree with your assertion. Runtime metaprogramming can be very useful, especially with higher level functions (or partial functions, as some people apparently refer to them).

My assertion was simply that C++ is more powerful than most people expect. Runtime metaprogramming, well, I've never seen a definition of runtime metaprogramming which I was able to get much traction out of. Each time, people will give me an example, I'll show them how to do that in traditional languages, and they'll tell me I'm missing the point, which I quite possibly am.

The germane difficulty is that compile-time metaprogrammin

What advantage does C++ have over, say, Java for programming web applications in?

Well, the comparison was between C++ and RoR. The advantages I was citing are equally well held by Java. The advantages I believe in as regards C++ versus Java are typical holy war nonsense (I dislike Java.) There is a minor but not significant advantage for C++ in terms of the number of available libraries. That said, Java fills out my statements to the grandparent post in the same way that C++ does. Actually, there's a good argument that Java is better suited to the web than C++, because of its deep integration of sockets and things like Tomcat and Beans. I would tend to argue what I just said, but it is a viable argument and is contextually appropriate.

The issue I was citing was compiled languages versus quick-assembly toolkits, on terms that large applications would benefit far more from strict static analysis than they would from a quick grammar and extant boilerplate. In this way, C++, Java, Delphi, C#, ASP.Net and quite a few other languages offer the same set of referred-to advantages.

The other difficulty I have with C++ is that it's not particularly powerful, in terms of syntax and control structures, as some other languages, such as Python or Ruby.

I just don't agree. C++'s syntax is so powerful that many major language features have been implemented directly in native syntax, something I've never seen in any other language except Lisp and Lisp descendants, including aspects, properties, the lambda calculus, closures, compile-time metaprogramming, coroutines, inline lexing, message-based concurrency and so on.

I recommend highly that you familiarize yourself with modern C++ methods. It's quite a bit more powerful language than most people realize. A good book to start with is Modern C++ Design.

When you don't particularly need the efficiency that C++ offers, why favour a more syntaxically restrictive language?

Well, for one I don't believe it's syntactically restricted. However, syntax is a comparatively minor component of a language; more important in this case is the specific advantage I cited, that of very strict static analysis. On these terms, very few languages can compete with C++; it is one of the strictest languages on Earth, when used skillfully.

In my experience, very few bugs disappear.

Er. How many times have you actually replaced a rapid-development web toolkit with a fully statically compiled application? I don't mean to seem rude, but this is experience that almost nobody has in the first place.

However, if you find that this is the case, why use dynamically typed languages such as PHP and Erlang?

Because different tools are appropriate for different jobs. I wouldn't use PHP for a large web application. Erlang is a very special case, and has such a weird benefit/detriment pattern that I don't honestly want to get into it. Suffice it to say that I'd use Erlang where pattern analysis, list comprehensions, or linear scaling across a huge number of users were my primary concerns.

And there are surely languages that have stricter rulesets than C++; Eiffel, for instance, which is compiled, and strongly and statically typed, with design-by-contract built in

Contracts are easily implemented in C/C++, and actually, no, Eiffel is nowhere near as strict as C++ is. Yes, there are a few languages stricter than C++ is, such as Clean, Mozart/OZ and Forth; however, what I was trying to do was to make an example, and given that most people are at least passingly familiar with C++, it just makes a better example.

To be plain, I'm Joseph Conrad. It doesn't matter if my native language is Polish; I'm in America, so I write in English. Sure, there are better examples than C++, but they're too little known (in my opinion) to make good examples.

C++'s weak static

so it really does not matter if it is lisp or c++ or whatever, although since you have so much c++ material on your blog, you have to promote it(i guess).

The blog is relatively new. Try looking at the base site, http://sc.tri-bit.com/. You'll find I have material up there for PHP, C, C++, Delphi, Erlang, FormulaONE, Lua, and occasional smatterings of various other languages. I'm not promoting C++ for large-scale web applications because I'm a C++ zealot. I'm doing it because I genuinely believe the strictness of C++ is more valuable than the convenience of Rails. In fact, I believe the difference is dramatically one-sided.

i'm sure as c++ coder rails would not work for you

Actually, my native languages are Pascal and LISP. Please do not attempt to dismiss my opinions by guessing at what my languages of preference are. I use more than a dozen languages on a regular basis, and my arguments are well-founded regardless of my personal practices.

instead of complaining about particular language implementation try to find out if code that you are looking at is compliant to language desirable maintainability practices.

I'm sorry, but I don't believe that I did any such thing. I made specific comparisons of specific advantages of each methodology, and came to a concrete conclusion based on my beliefs. I've made no random complaints, and the things I said are not in fact related to code quality.

in fact, if i would want my stff to work in c++, i would first write it in some other language, like perl or ruby or php, and then rewrite it in c++, just so i dont have to babysit my compiler.

If you make your tool selection based on a fifteen second compile and link pass, then it's no wonder we disagree so strongly. You don't appear to have actually read what I said, and you seem to be arguing by the attempt to incorrectly pigeonhole me into a stereotype based on guesses. I believe this conversation ends here; I do not enjoy being told that I'm wrong because you're guessing what language I use most often.

The reason my blog and wiki have a bunch of C and C++ on them is because they're written for Nintendo programmers, and because C and C++ are almost the only languages available to them. It's got nothing to do with my personal preferences; I use several languages more often than I use C++. Enough with the stereotyping. It's ugly and offensive. If you can't discuss what someone said on the merits of what was said, but rather feel the need to treat them like one-trick ponies, I'd appreciate it if you didn't speak with me anymore.

Industry statistics suggest that hard-nosed engineering outperforms agile dramatically. Maybe Agile works better for you, but when fifteen thousand programmers have been measured and more than 95% end up doing better with real metrics, and when these engineers are some of the best on earth (the first military software house to hit CMM5, the Boeing 747 software team, etc,) it's a fair guess that you're the exception rather than the rule. Believe it or not, genuine formal engineering does exist for software, and the training isn't all that expensive.

Is it possible you would do better with up-front planning once you were familiar with a formal method like PSP / TSP? It turns out that saying you're planning hard then writing a bunch of stuff down isn't actually as good as learning statistical methods and keeping years of data from which to make schedules using mathematical models derived from tens of millions of man-hours of detailed real-world data. When the 747 software team sees a 60% time to market drop, a 95% testing time drop and two known bugs in a million and a half lines of code on an 18 month project (as compared to 228 on the previous iteration, by the same people,) it's time to consider whether to learn what it is that's helping them so much. After all, they're actually pretty good at their jobs.

Just a thought.

Industry statistics suggest that hard-nosed engineering outperforms agile dramatically. Maybe Agile works better for you, but when fifteen thousand programmers have been measured and more than 95% end up doing better with real metrics, and when these engineers are some of the best on earth (the first military software house to hit CMM5, the Boeing 747 software team, etc,) it's a fair guess that you're the exception rather than the rule. Believe it or not, genuine formal engineering does exist for software, and the training isn't all that expensive.

Is it possible you would do better with up-front planning once you were familiar with a formal method like PSP / TSP? It turns out that saying you're planning hard then writing a bunch of stuff down isn't actually as good as learning statistical methods and keeping years of data from which to make schedules using mathematical models derived from tens of millions of man-hours of detailed real-world data. When the 747 software team sees a 60% time to market drop, a 95% testing time drop and two known bugs in a million and a half lines of code on an 18 month project (as compared to 228 on the previous iteration, by the same people,) it's time to consider whether to learn what it is that's helping them so much. After all, they're actually pretty good at their jobs.

Just a thought.

Whereas I agree with you, there is a consideration here for terms of pure pragmatism - early career coders aren't able to do the kind of planning which ends one up with that kind of long-term maintainable software. Even with proper planning in something like the PSP / TSP, it often just takes someone with real experience to be able to knock something like that out in the first place. You can't begrudge them the experience that their own naïveté has taught them.

Whereas I agree with you, there is a consideration here for terms of pure pragmatism - early career coders aren't able to do the kind of planning which ends one up with that kind of long-term maintainable software. Even with proper planning in something like the PSP / TSP, it often just takes someone with real experience to be able to knock something like that out in the first place. You can't begrudge them the experience that their own naïveté has taught them.

The saddest thing about this is how correct you are, and how it hinders you. If you and another team developed Product X, and both went 33% over schedule, the other team would hit early milestones, declare progressive success, change the schedule to fit the new needs, allow bloat, hammer in new features to justify the lag, and end up coming in 200% over budget. You would come in 33% over budget, but since you didn't dance around acting like the schedule was the only important thing, your lean and nearly on-time product would be seen as disasterously over-budget, and you wouldn't be allowed to manage again.

It's a pity that what you said is correct, because it encourages a kind of myopic and nearly religious devotion to what is really just a measuring tool, and the results are a massive drop in actual quality in exchange for the feeling of success. What you said is right, but remarkably counterintuitive, and it is my belief that what you're correct about is the primary basis for most of the problems in this industry today.

I wish more people were like you, and were willing to take the up-front hit instead of playing self-deception games to feel better about slippage. You plus a real estimating tool like the PSP/TSP (see propoganda video) are exactly what this industry needs, but facing the problem is so difficult and fixing it so superficially expensive-looking (despite the remarkable cost benefits in the long run) that I think your kind of actual observant development is a long time in coming.

Pat yourself on the back. You've made all the old people proud today.

The saddest thing about this is how correct you are, and how it hinders you. If you and another team developed Product X, and both went 33% over schedule, the other team would hit early milestones, declare progressive success, change the schedule to fit the new needs, allow bloat, hammer in new features to justify the lag, and end up coming in 200% over budget. You would come in 33% over budget, but since you didn't dance around acting like the schedule was the only important thing, your lean and nearly on-time product would be seen as disasterously over-budget, and you wouldn't be allowed to manage again.

It's a pity that what you said is correct, because it encourages a kind of myopic and nearly religious devotion to what is really just a measuring tool, and the results are a massive drop in actual quality in exchange for the feeling of success. What you said is right, but remarkably counterintuitive, and it is my belief that what you're correct about is the primary basis for most of the problems in this industry today.

I wish more people were like you, and were willing to take the up-front hit instead of playing self-deception games to feel better about slippage. You plus a real estimating tool like the PSP/TSP (see propoganda video) are exactly what this industry needs, but facing the problem is so difficult and fixing it so superficially expensive-looking (despite the remarkable cost benefits in the long run) that I think your kind of actual observant development is a long time in coming.

Pat yourself on the back. You've made all the old people proud today.

The emphasis on fast devlopment is justified, at least from a business perspective, because first to market gives a huge advantage in software, not to mention the network effect.

Tell that to Yahoo! Groups and Friendster. When the quality of your service suffers, a competitor will take your userbase away. Things like RoR may be great for getting to market first (and that's in fact fairly arguable when you get past trivially simple example code,) but they quickly turn into a ball-and-chain when you start having to face extensibility and performance concerns. People drastically overvalue arbitrary equations like Metcalfe's law, and turn away from the actual statistical data sitting right in front of them. Yahoo's got something like 350m users, and you still almost never see anyone who complains about their 255 user friend list limit. Squaring the user count is just stupid; so is taking its logarithm. Neither of those are based on real world data.

Real world data suggests that almost nobody keeps track of fewer than 10 people or more than 150 people. If you're treating the value of the userbase as growing at anything other than the linear arithmetic mean of 98 users per user (and even then that's arguably much too high,) then you're in for a nasty shock.

If you want a web tool which gets you to market fast and keeps you there, you need to look at PHP or Erlang. No two ways about it. It just isn't worth the ten extra percent speed in development to have to gut it and start over a second time. Besides, unless your whole staff is already deeply familiar with the tools, there's a pretty good chance you'll lose that entire advantage in training time and new-language bugs.

If you're more comfortable in RoR than other tools, and if you're going to pull a Fred Brooks and "plan to throw one away, because you will anyway," then RoR is admittedly a pretty useful prototyping tool. That said, in that arena, in my opinion, LISP just completely owns RoR, as do Erlang, Python and PHP. Erlang and PHP have the advantages of being legitimate places to build a production-level tool.

But, I'll tell you up-front: you do not want a RoR application when you're planning to scale into a large-userbase product. It just falls apart. Flame-suit on, as I'm sure there are a lot of fanboys who are about to tell me I'm full of it and that their game has almost a thousand users or some nonsense like that. I've built services that deal with more than a thousand people simultaneously. I'm not talking out of my ass. I know what hurts when you get into that area, and I know that RoR is just not where I'd want to be.

If you ever get into that kind of place, do yourself a favor and fake the service. Benchmark it. You'll thank me later.

Similiarily start-ups don't care about these issues since they plan on being bought out before they matter.

That kind of startup doesn't get bought out. Surprisingly, the people who can afford to put up eight digits for a product will send in their own engineers to find out if the product is going to be a problem in the long run. If it is, the investor just fights you, instead of buying you; it's cheaper, it's faster, and if your product is a shoddy, thrown-together mess, it'll keep the audience better in the long run.

Besides, these days it's almost impossible to find a startup without ten competitors in the same market space. Odds are damned good that at least one of those competitors did a good job.

Yes these attitudes create serious problems and lead to poorly made software, but what can you do about it?

Compete in the open marketplace, and win. It happens every day. Either make software which isn't of poor quality, or expect to go nowhere. Arguably the best thing about the internet marketplace is that you have access to tens of thousands of vendors. You just don't have to work with someone who cuts corners,

Hey, he is a much-loved industry figure from the 1980s.

Well, he is from the 1980s. He might also be much loved by the fans. He was not much loved within the industry. Game thieves never are.

I remember with fondness disassembling GridRunner on the VIC-20 by hand...

Okay. Go grab the demo from his webpage. You'll be surprised to learn that it's just enemy behavior from Centipede and Galaga, without the mushrooms or enemy formations that made the other two games good, and with a screen saver for a background. He doesn't even try to hide it - at level 9, he starts using graphics stolen from Galaxian (in the PC version of gridrunner++, it starts at 15 instead.) They're not the only ones, but they're the easiest to get to quickly - not that the game is even remotely difficult.

The only real difference between this game and Centipede, besides the progressive level constraints and the stupid sheep jokes, is that Centipede (at least back then) required a trackball.

Your blog does not immediately say what authority you speak from.

Yes, it does. Read it again.

That said, it doesn't really matter who I am; what I say is factual, even if I'm some nobody from under a rock (which I'm not.)

Admittedly when I said hi to phil harrison on wednesday night he blanked me, so i guess I won't get any sony party invites soon unless I tag on with someone else.

Well, if you see me at E3 next year, tell me who you are, and I'll introduce you. Phil and I have gotten along well ever since I met him at one of the panels three years ago, when one of the panellists said something snarky about one of his decisions (he was in the audience, not on the panel, so I just got a chance to speak before he did.) We're not bosom buddies by any stretch of the imagination, but I'm relatively easy to remember by sight - I'm a very large person with very long hair - so he still gets me into doors when he sees me.

I'm honestly getting a little tired of these fanboy reporters wasting what could have been productive interviews by instead parroting the rantings of a clone-factory also-ran. There's a reason nobody can name a game of Jeff's that isn't a sequel or a ripoff: they don't exist. Why is Sony arrogant for not tipping their hand? They've cornered what was a thoroughly dominated market in under two years and held it for more than a decade. Yes, the price is high, but Sony knows how to handle markets; their seven year old PS2 is outselling Microsoft's brand new XBox360 in every territory, even though the 360 is the only one of the next-gen consoles available, and probably will be so until at least Christmas.

News flash: Jeff Minter is Nobody. Film at never.

(His two famous games are a Robotron ripoff and a sequel to someone else's game which is essentially a graphics upgrade and a speed boost. Most people have to look him up online to even come up with another one of his games. C'mon. Arrogant means to exaggerate your own worth in an overbearing manner, and here's some guy who has released 40 games, the sum total of which don't outsell even one game in the Playstation2 Top 100, talking about Sony's full of it because he doesn't like their new price line? Pots and kettles, man.)

I'm honestly getting a little tired of these fanboy reporters wasting what could have been productive interviews by instead parroting the rantings of a clone-factory also-ran. There's a reason nobody can name a game of Jeff's that isn't a sequel or a ripoff: they don't exist. Why is Sony arrogant for not tipping their hand? They've cornered what was a thoroughly dominated market in under two years and held it for more than a decade. Yes, the price is high, but Sony knows how to handle markets; their seven year old PS2 is outselling Microsoft's brand new XBox360 in every territory, even though the 360 is the only one of the next-gen consoles available, and probably will be so until at least Christmas.

News flash: Jeff Minter is Nobody. Film at never.

(His two famous games are a Robotron ripoff and a sequel to someone else's game which is essentially a graphics upgrade and a speed boost. Most people have to look him up online to even come up with another one of his games. C'mon. Arrogant means to exaggerate your own worth in an overbearing manner, and here's some guy who has released 40 games, the sum total of which don't outsell even one game in the Playstation2 Top 100, talking about Sony's full of it because he doesn't like their new price line? Pots and kettles, man.)

It is ironic then that the editors are trying to stoke up discussion on what represents a reasonable limit to copyright while unintentionally demonstrating why the law as it currently stands is horribly broken.

You must be talking about the the Alanis Morissette version of irony, not what irony really is.

That's not what irony means, you low grade Piquepaille douchebag.

Estimation is complex and difficult. All four of the major methods today involve keeping significant statistical data on past performance and using it to mathematically generate estimates. This is remarkably accurate - using the PSP and TSP, I've managed to whittle my estimates down to +- 20%. The inventor of the process made a video about eight years ago describing it; in lots of ways it's kind of quaint, since it talks about how big the internet is going to be (for example,) but it also gives a lot of surprising hard data. Since the training courses are several thousand dollars per person and require the whole team, you might want to start by reading the books (Intro to PSP and Intro to TSP) to make sure it's something you like and which is appropriate to your business model.

PSP and TSP are appropriate for up front engineered projects - application sequels, industrial software, military software (it's originally a DoD system,) et cetera. If you're writing business software or games, PSP and TSP aren't for you - they don't allow for the kind of rapid change that characterizes those designs. They can be bent into it, but there are better tools. Extreme Programming (start with Explained then read installed) are built for rapid-change environments, and were built on the Chrysler C4 project. They're industrial-ready, but they spend a lot of time on post-organization. You want that if your project is changing a lot, like an application you're building for a client who isn't sure what they want. You don't want that when you know exactly what you're building, like a realtime control system which has to respond to an exact list of inputs.

When you're somewhere inbetween those two poles - say, the new version of an office suite, or a game sequel, where you know most of the features and most of the format, but have to add some small and jazzy new stuff to get an upgrade, you might want to work with a thrash control process. The idea with thrash control processes is to start with a really wide (25-400%) range, and progressively whittle that down as the project takes shape. This is a very good process for when you have a fairly good idea what you're going to do, but when there's still a significant amount of mystery. For that you want the Microsoft axis, largely characterized by McConnell's Software Project Survival Guide and Sullivan's UPOT. Thrash control processes have a very nasty tendency to suffer detrimental early optimism, and they're already in a dangerous place for second system syndrome since they're mostly for reasonably well defined projects, so you'd do well to get some cold blanket advice from The Mythical Man-Month if you go this route.

And then, there's the hard-nosed engineer camp. They tend to use things like formal estimation based on code points and function points, systemal analysis and big models like COCOMO. This kind of thing is appropriate for large projects. You can get a clearer understanding of formal estimating practices, instead of just that one practice, from Software Estimation: Demystifying the Black Art.

That should get you started. There are a lot of real approaches to this sort of thing which aren't "zomg double your estimate" or "totally refuse." This is something business needs, and it needs to be done right. There are programmers and there are software engineers. Regardless of what your co

Estimation is complex and difficult. All four of the major methods today involve keeping significant statistical data on past performance and using it to mathematically generate estimates. This is remarkably accurate - using the PSP and TSP, I've managed to whittle my estimates down to +- 20%. The inventor of the process made a video about eight years ago describing it; in lots of ways it's kind of quaint, since it talks about how big the internet is going to be (for example,) but it also gives a lot of surprising hard data. Since the training courses are several thousand dollars per person and require the whole team, you might want to start by reading the books (Intro to PSP and Intro to TSP) to make sure it's something you like and which is appropriate to your business model.

PSP and TSP are appropriate for up front engineered projects - application sequels, industrial software, military software (it's originally a DoD system,) et cetera. If you're writing business software or games, PSP and TSP aren't for you - they don't allow for the kind of rapid change that characterizes those designs. They can be bent into it, but there are better tools. Extreme Programming (start with Explained then read installed) are built for rapid-change environments, and were built on the Chrysler C4 project. They're industrial-ready, but they spend a lot of time on post-organization. You want that if your project is changing a lot, like an application you're building for a client who isn't sure what they want. You don't want that when you know exactly what you're building, like a realtime control system which has to respond to an exact list of inputs.

When you're somewhere inbetween those two poles - say, the new version of an office suite, or a game sequel, where you know most of the features and most of the format, but have to add some small and jazzy new stuff to get an upgrade, you might want to work with a thrash control process. The idea with thrash control processes is to start with a really wide (25-400%) range, and progressively whittle that down as the project takes shape. This is a very good process for when you have a fairly good idea what you're going to do, but when there's still a significant amount of mystery. For that you want the Microsoft axis, largely characterized by McConnell's Software Project Survival Guide and Sullivan's UPOT. Thrash control processes have a very nasty tendency to suffer detrimental early optimism, and they're already in a dangerous place for second system syndrome since they're mostly for reasonably well defined projects, so you'd do well to get some cold blanket advice from The Mythical Man-Month if you go this route.

And then, there's the hard-nosed engineer camp. They tend to use things like formal estimation based on code points and function points, systemal analysis and big models like COCOMO. This kind of thing is appropriate for large projects. You can get a clearer understanding of formal estimating practices, instead of just that one practice, from Software Estimation: Demystifying the Black Art.

That should get you started. There are a lot of real approaches to this sort of thing which aren't "zomg double your estimate" or "totally refuse." This is something business needs, and it needs to be done right. There are programmers and there are software engineers. Regardless of what your co

Estimation is complex and difficult. All four of the major methods today involve keeping significant statistical data on past performance and using it to mathematically generate estimates. This is remarkably accurate - using the PSP and TSP, I've managed to whittle my estimates down to +- 20%. The inventor of the process made a video about eight years ago describing it; in lots of ways it's kind of quaint, since it talks about how big the internet is going to be (for example,) but it also gives a lot of surprising hard data. Since the training courses are several thousand dollars per person and require the whole team, you might want to start by reading the books (Intro to PSP and Intro to TSP) to make sure it's something you like and which is appropriate to your business model.

PSP and TSP are appropriate for up front engineered projects - application sequels, industrial software, military software (it's originally a DoD system,) et cetera. If you're writing business software or games, PSP and TSP aren't for you - they don't allow for the kind of rapid change that characterizes those designs. They can be bent into it, but there are better tools. Extreme Programming (start with Explained then read installed) are built for rapid-change environments, and were built on the Chrysler C4 project. They're industrial-ready, but they spend a lot of time on post-organization. You want that if your project is changing a lot, like an application you're building for a client who isn't sure what they want. You don't want that when you know exactly what you're building, like a realtime control system which has to respond to an exact list of inputs.

When you're somewhere inbetween those two poles - say, the new version of an office suite, or a game sequel, where you know most of the features and most of the format, but have to add some small and jazzy new stuff to get an upgrade, you might want to work with a thrash control process. The idea with thrash control processes is to start with a really wide (25-400%) range, and progressively whittle that down as the project takes shape. This is a very good process for when you have a fairly good idea what you're going to do, but when there's still a significant amount of mystery. For that you want the Microsoft axis, largely characterized by McConnell's Software Project Survival Guide and Sullivan's UPOT. Thrash control processes have a very nasty tendency to suffer detrimental early optimism, and they're already in a dangerous place for second system syndrome since they're mostly for reasonably well defined projects, so you'd do well to get some cold blanket advice from The Mythical Man-Month if you go this route.

And then, there's the hard-nosed engineer camp. They tend to use things like formal estimation based on code points and function points, systemal analysis and big models like COCOMO. This kind of thing is appropriate for large projects. You can get a clearer understanding of formal estimating practices, instead of just that one practice, from Software Estimation: Demystifying the Black Art.

That should get you started. There are a lot of real approaches to this sort of thing which aren't "zomg double your estimate" or "totally refuse." This is something business needs, and it needs to be done right. There are programmers and there are software engineers. Regardless of what your co

Estimation is complex and difficult. All four of the major methods today involve keeping significant statistical data on past performance and using it to mathematically generate estimates. This is remarkably accurate - using the PSP and TSP, I've managed to whittle my estimates down to +- 20%. The inventor of the process made a video about eight years ago describing it; in lots of ways it's kind of quaint, since it talks about how big the internet is going to be (for example,) but it also gives a lot of surprising hard data. Since the training courses are several thousand dollars per person and require the whole team, you might want to start by reading the books (Intro to PSP and Intro to TSP) to make sure it's something you like and which is appropriate to your business model.

PSP and TSP are appropriate for up front engineered projects - application sequels, industrial software, military software (it's originally a DoD system,) et cetera. If you're writing business software or games, PSP and TSP aren't for you - they don't allow for the kind of rapid change that characterizes those designs. They can be bent into it, but there are better tools. Extreme Programming (start with Explained then read installed) are built for rapid-change environments, and were built on the Chrysler C4 project. They're industrial-ready, but they spend a lot of time on post-organization. You want that if your project is changing a lot, like an application you're building for a client who isn't sure what they want. You don't want that when you know exactly what you're building, like a realtime control system which has to respond to an exact list of inputs.

When you're somewhere inbetween those two poles - say, the new version of an office suite, or a game sequel, where you know most of the features and most of the format, but have to add some small and jazzy new stuff to get an upgrade, you might want to work with a thrash control process. The idea with thrash control processes is to start with a really wide (25-400%) range, and progressively whittle that down as the project takes shape. This is a very good process for when you have a fairly good idea what you're going to do, but when there's still a significant amount of mystery. For that you want the Microsoft axis, largely characterized by McConnell's Software Project Survival Guide and Sullivan's UPOT. Thrash control processes have a very nasty tendency to suffer detrimental early optimism, and they're already in a dangerous place for second system syndrome since they're mostly for reasonably well defined projects, so you'd do well to get some cold blanket advice from The Mythical Man-Month if you go this route.

And then, there's the hard-nosed engineer camp. They tend to use things like formal estimation based on code points and function points, systemal analysis and big models like COCOMO. This kind of thing is appropriate for large projects. You can get a clearer understanding of formal estimating practices, instead of just that one practice, from Software Estimation: Demystifying the Black Art.

That should get you started. There are a lot of real approaches to this sort of thing which aren't "zomg double your estimate" or "totally refuse." This is something business needs, and it needs to be done right. There are programmers and there are software engineers. Regardless of what your co

Estimation is complex and difficult. All four of the major methods today involve keeping significant statistical data on past performance and using it to mathematically generate estimates. This is remarkably accurate - using the PSP and TSP, I've managed to whittle my estimates down to +- 20%. The inventor of the process made a video about eight years ago describing it; in lots of ways it's kind of quaint, since it talks about how big the internet is going to be (for example,) but it also gives a lot of surprising hard data. Since the training courses are several thousand dollars per person and require the whole team, you might want to start by reading the books (Intro to PSP and Intro to TSP) to make sure it's something you like and which is appropriate to your business model.

PSP and TSP are appropriate for up front engineered projects - application sequels, industrial software, military software (it's originally a DoD system,) et cetera. If you're writing business software or games, PSP and TSP aren't for you - they don't allow for the kind of rapid change that characterizes those designs. They can be bent into it, but there are better tools. Extreme Programming (start with Explained then read installed) are built for rapid-change environments, and were built on the Chrysler C4 project. They're industrial-ready, but they spend a lot of time on post-organization. You want that if your project is changing a lot, like an application you're building for a client who isn't sure what they want. You don't want that when you know exactly what you're building, like a realtime control system which has to respond to an exact list of inputs.

When you're somewhere inbetween those two poles - say, the new version of an office suite, or a game sequel, where you know most of the features and most of the format, but have to add some small and jazzy new stuff to get an upgrade, you might want to work with a thrash control process. The idea with thrash control processes is to start with a really wide (25-400%) range, and progressively whittle that down as the project takes shape. This is a very good process for when you have a fairly good idea what you're going to do, but when there's still a significant amount of mystery. For that you want the Microsoft axis, largely characterized by McConnell's Software Project Survival Guide and Sullivan's UPOT. Thrash control processes have a very nasty tendency to suffer detrimental early optimism, and they're already in a dangerous place for second system syndrome since they're mostly for reasonably well defined projects, so you'd do well to get some cold blanket advice from The Mythical Man-Month if you go this route.

And then, there's the hard-nosed engineer camp. They tend to use things like formal estimation based on code points and function points, systemal analysis and big models like COCOMO. This kind of thing is appropriate for large projects. You can get a clearer understanding of formal estimating practices, instead of just that one practice, from Software Estimation: Demystifying the Black Art.

That should get you started. There are a lot of real approaches to this sort of thing which aren't "zomg double your estimate" or "totally refuse." This is something business needs, and it needs to be done right. There are programmers and there are software engineers. Regardless of what your co

Estimation is complex and difficult. All four of the major methods today involve keeping significant statistical data on past performance and using it to mathematically generate estimates. This is remarkably accurate - using the PSP and TSP, I've managed to whittle my estimates down to +- 20%. The inventor of the process made a video about eight years ago describing it; in lots of ways it's kind of quaint, since it talks about how big the internet is going to be (for example,) but it also gives a lot of surprising hard data. Since the training courses are several thousand dollars per person and require the whole team, you might want to start by reading the books (Intro to PSP and Intro to TSP) to make sure it's something you like and which is appropriate to your business model.

PSP and TSP are appropriate for up front engineered projects - application sequels, industrial software, military software (it's originally a DoD system,) et cetera. If you're writing business software or games, PSP and TSP aren't for you - they don't allow for the kind of rapid change that characterizes those designs. They can be bent into it, but there are better tools. Extreme Programming (start with Explained then read installed) are built for rapid-change environments, and were built on the Chrysler C4 project. They're industrial-ready, but they spend a lot of time on post-organization. You want that if your project is changing a lot, like an application you're building for a client who isn't sure what they want. You don't want that when you know exactly what you're building, like a realtime control system which has to respond to an exact list of inputs.

When you're somewhere inbetween those two poles - say, the new version of an office suite, or a game sequel, where you know most of the features and most of the format, but have to add some small and jazzy new stuff to get an upgrade, you might want to work with a thrash control process. The idea with thrash control processes is to start with a really wide (25-400%) range, and progressively whittle that down as the project takes shape. This is a very good process for when you have a fairly good idea what you're going to do, but when there's still a significant amount of mystery. For that you want the Microsoft axis, largely characterized by McConnell's Software Project Survival Guide and Sullivan's UPOT. Thrash control processes have a very nasty tendency to suffer detrimental early optimism, and they're already in a dangerous place for second system syndrome since they're mostly for reasonably well defined projects, so you'd do well to get some cold blanket advice from The Mythical Man-Month if you go this route.

And then, there's the hard-nosed engineer camp. They tend to use things like formal estimation based on code points and function points, systemal analysis and big models like COCOMO. This kind of thing is appropriate for large projects. You can get a clearer understanding of formal estimating practices, instead of just that one practice, from Software Estimation: Demystifying the Black Art.

That should get you started. There are a lot of real approaches to this sort of thing which aren't "zomg double your estimate" or "totally refuse." This is something business needs, and it needs to be done right. There are programmers and there are software engineers. Regardless of what your co

Estimation is complex and difficult. All four of the major methods today involve keeping significant statistical data on past performance and using it to mathematically generate estimates. This is remarkably accurate - using the PSP and TSP, I've managed to whittle my estimates down to +- 20%. The inventor of the process made a video about eight years ago describing it; in lots of ways it's kind of quaint, since it talks about how big the internet is going to be (for example,) but it also gives a lot of surprising hard data. Since the training courses are several thousand dollars per person and require the whole team, you might want to start by reading the books (Intro to PSP and Intro to TSP) to make sure it's something you like and which is appropriate to your business model.

PSP and TSP are appropriate for up front engineered projects - application sequels, industrial software, military software (it's originally a DoD system,) et cetera. If you're writing business software or games, PSP and TSP aren't for you - they don't allow for the kind of rapid change that characterizes those designs. They can be bent into it, but there are better tools. Extreme Programming (start with Explained then read installed) are built for rapid-change environments, and were built on the Chrysler C4 project. They're industrial-ready, but they spend a lot of time on post-organization. You want that if your project is changing a lot, like an application you're building for a client who isn't sure what they want. You don't want that when you know exactly what you're building, like a realtime control system which has to respond to an exact list of inputs.

When you're somewhere inbetween those two poles - say, the new version of an office suite, or a game sequel, where you know most of the features and most of the format, but have to add some small and jazzy new stuff to get an upgrade, you might want to work with a thrash control process. The idea with thrash control processes is to start with a really wide (25-400%) range, and progressively whittle that down as the project takes shape. This is a very good process for when you have a fairly good idea what you're going to do, but when there's still a significant amount of mystery. For that you want the Microsoft axis, largely characterized by McConnell's Software Project Survival Guide and Sullivan's UPOT. Thrash control processes have a very nasty tendency to suffer detrimental early optimism, and they're already in a dangerous place for second system syndrome since they're mostly for reasonably well defined projects, so you'd do well to get some cold blanket advice from The Mythical Man-Month if you go this route.

And then, there's the hard-nosed engineer camp. They tend to use things like formal estimation based on code points and function points, systemal analysis and big models like COCOMO. This kind of thing is appropriate for large projects. You can get a clearer understanding of formal estimating practices, instead of just that one practice, from Software Estimation: Demystifying the Black Art.

That should get you started. There are a lot of real approaches to this sort of thing which aren't "zomg double your estimate" or "totally refuse." This is something business needs, and it needs to be done right. There are programmers and there are software engineers. Regardless of what your co

Estimation is complex and difficult. All four of the major methods today involve keeping significant statistical data on past performance and using it to mathematically generate estimates. This is remarkably accurate - using the PSP and TSP, I've managed to whittle my estimates down to +- 20%. The inventor of the process made a video about eight years ago describing it; in lots of ways it's kind of quaint, since it talks about how big the internet is going to be (for example,) but it also gives a lot of surprising hard data. Since the training courses are several thousand dollars per person and require the whole team, you might want to start by reading the books (Intro to PSP and Intro to TSP) to make sure it's something you like and which is appropriate to your business model.

PSP and TSP are appropriate for up front engineered projects - application sequels, industrial software, military software (it's originally a DoD system,) et cetera. If you're writing business software or games, PSP and TSP aren't for you - they don't allow for the kind of rapid change that characterizes those designs. They can be bent into it, but there are better tools. Extreme Programming (start with Explained then read installed) are built for rapid-change environments, and were built on the Chrysler C4 project. They're industrial-ready, but they spend a lot of time on post-organization. You want that if your project is changing a lot, like an application you're building for a client who isn't sure what they want. You don't want that when you know exactly what you're building, like a realtime control system which has to respond to an exact list of inputs.

When you're somewhere inbetween those two poles - say, the new version of an office suite, or a game sequel, where you know most of the features and most of the format, but have to add some small and jazzy new stuff to get an upgrade, you might want to work with a thrash control process. The idea with thrash control processes is to start with a really wide (25-400%) range, and progressively whittle that down as the project takes shape. This is a very good process for when you have a fairly good idea what you're going to do, but when there's still a significant amount of mystery. For that you want the Microsoft axis, largely characterized by McConnell's Software Project Survival Guide and Sullivan's UPOT. Thrash control processes have a very nasty tendency to suffer detrimental early optimism, and they're already in a dangerous place for second system syndrome since they're mostly for reasonably well defined projects, so you'd do well to get some cold blanket advice from The Mythical Man-Month if you go this route.

And then, there's the hard-nosed engineer camp. They tend to use things like formal estimation based on code points and function points, systemal analysis and big models like COCOMO. This kind of thing is appropriate for large projects. You can get a clearer understanding of formal estimating practices, instead of just that one practice, from Software Estimation: Demystifying the Black Art.

That should get you started. There are a lot of real approaches to this sort of thing which aren't "zomg double your estimate" or "totally refuse." This is something business needs, and it needs to be done right. There are programmers and there are software engineers. Regardless of what your co

Estimation is complex and difficult. All four of the major methods today involve keeping significant statistical data on past performance and using it to mathematically generate estimates. This is remarkably accurate - using the PSP and TSP, I've managed to whittle my estimates down to +- 20%. The inventor of the process made a video about eight years ago describing it; in lots of ways it's kind of quaint, since it talks about how big the internet is going to be (for example,) but it also gives a lot of surprising hard data. Since the training courses are several thousand dollars per person and require the whole team, you might want to start by reading the books (Intro to PSP and Intro to TSP) to make sure it's something you like and which is appropriate to your business model.

PSP and TSP are appropriate for up front engineered projects - application sequels, industrial software, military software (it's originally a DoD system,) et cetera. If you're writing business software or games, PSP and TSP aren't for you - they don't allow for the kind of rapid change that characterizes those designs. They can be bent into it, but there are better tools. Extreme Programming (start with Explained then read installed) are built for rapid-change environments, and were built on the Chrysler C4 project. They're industrial-ready, but they spend a lot of time on post-organization. You want that if your project is changing a lot, like an application you're building for a client who isn't sure what they want. You don't want that when you know exactly what you're building, like a realtime control system which has to respond to an exact list of inputs.

When you're somewhere inbetween those two poles - say, the new version of an office suite, or a game sequel, where you know most of the features and most of the format, but have to add some small and jazzy new stuff to get an upgrade, you might want to work with a thrash control process. The idea with thrash control processes is to start with a really wide (25-400%) range, and progressively whittle that down as the project takes shape. This is a very good process for when you have a fairly good idea what you're going to do, but when there's still a significant amount of mystery. For that you want the Microsoft axis, largely characterized by McConnell's Software Project Survival Guide and Sullivan's UPOT. Thrash control processes have a very nasty tendency to suffer detrimental early optimism, and they're already in a dangerous place for second system syndrome since they're mostly for reasonably well defined projects, so you'd do well to get some cold blanket advice from The Mythical Man-Month if you go this route.

And then, there's the hard-nosed engineer camp. They tend to use things like formal estimation based on code points and function points, systemal analysis and big models like COCOMO. This kind of thing is appropriate for large projects. You can get a clearer understanding of formal estimating practices, instead of just that one practice, from Software Estimation: Demystifying the Black Art.

That should get you started. There are a lot of real approaches to this sort of thing which aren't "zomg double your estimate" or "totally refuse." This is something business needs, and it needs to be done right. There are programmers and there are software engineers. Regardless of what your co

Actually, that sort of phrasing is highly desirable, and found throughout our legal system. The reason is that it's therefore easy to update the definition to reflect changing social mores or newly available variations on a theme, without actually changing the law. This means that the law itself can be interpreted in a uniform fashion without attempting to refer to specifics of definitions and without any risk of these references tainting or damaging the law based on one individual judge's beliefs (this used to be a runaway problem in the United States, during its first 50 years.)

In an odd way, I feel programmers will best understand it in terms of object orientation. Don't bother with the flames; I know that it's at best a shaky metaphor and at worst patently silly. Still, I like it, and I think it gets the point across.

Think of these definitions as Alexandrescu-style policy classes. This means that we can spend time shaking down the law (the host class,) debugging it, extending it, profiling (huhu) it, gold-plating it and so on. We can link that law to other laws. Whatever. When the implementation details change, we don't want to have to go back and re-debug the law; therefore we isolate fungible details like specific definitions of terms as policies, and snap them in as needed.

See, definitions change /a/ /lot/. Ob Simpsons reference, "between Moneybags and Scrooge McDuck, all the best ankle is taken." There was a point in this country where showing bare ankle in public was considered indecent. Now we have sideboob on NBC, as well as asses. Once upon a time, a TV exec would get fired if they didn't fire a writer who wrote nigger; now, it's virtually a staple not only of crime dramas and documentaries, but of comedies and even cartoons ("Now that's what I'm talking about. We do not say the N-word in this house!" "Grandpa, you said nigger 47 times yesterday. I counted." "Nigga hush.") Once upon a time, the head executive at paramount was almost fired for showing a couple's bedroom with a single bed, instead of two beds as was the self-deception of the day (think I'm kidding? Go watch Turner Classic Movies.) Now, soap operas are essentially soft-porn, showing sex onscreen and making it legal by leaving the covers over the actors.

Once upon a time, we actually had laws to take children away from single mothers who weren't widowers, because they were immoral and would ruin the children.

The point is, though, the above law is essentially good. If a mother is unfit to the point where she is a risk to her children, the children do need to be taken away. In fact, the above law is still in effect; however, since the definitions can be updated seperately of the law, we've been able to remove the nonsense about single mothers, and to add stuff to cover (for example) cocaine and drunk driving, neither of which existed in primordeal Boston.

Because the definitions have been able to be changed to keep up with our social mores, the laws don't need to be reimplemented, re-tested, loopholes don't get opened, legitimate convictions don't get overturned, et cetera. Yes, you're right to point out that the definition isn't well had; however, it shouldn't be in the law either way. And, actually, this is the norm for this kind of law: first you generate the law, then when people might be breaking it, you take their asses to court and let juries decide. That sets precedent, which essentially anneals a definition of the term.

The reason this is important? Let's pretend that there wasn't a bunch of precedent that made this law a paper tiger. Let's pretend that this was the first time these issues had ever come up. If that were the case, then suddenly this law would be a real threat. The people railing on and on about the first amendment don't know what the hell they're talking about; the constitution is specifically structured to allow the states to set rules governing decency

That's not what irony means.

Well, at that point he should be thanking his school, because you're not getting irony either.

Repeat after me: Irony Is A Form Of Wordplay.

Ajax doesn't matter until we get raw headers and server push. Until then, it's limited to server-pull, polling, and web servers.

This is nonsense. I had sort of a long and aggravated response, so I posted it on my blog instead.

Short version: it's not Walmart versus Reasonable Viewpoints, it's Wikipedia versus All Viewpoints. NPOV isn't about hearing all viewpoints, it's about hearing none. An encyclopedia is a collation of information, not a presentation of judgements.

Whitedust is just missing the point.

No, You Can't Have a Pony.. well, maybe on April 1st.

If they can simulate something else than a virus (because I don't think viruses are intelligent) could they by this way obtain intelligence by simulating an intelligent animal?

This argument made Kuhn famous in the 1950s. You may be entertained to read Artificial Intelligence: the Very Idea, which addresses this line of thinking, both how it can be supported and how it can be denied. The book isn't neutral; it takes both sides in the effort to give you material to come to your own beliefs, and in my opinion succeeds admirably.

1. The word is several hundred years older than that,
2. The Baroque is a time period, and therefore it would be inappropriate to attribute to it an action, and
3. That's not what irony means.

You know, Halo 2 sold really well, but, meh, I preferred Halo. The biggest advantage was being able to play online, but my friends who own it quickly tired of playing with random assholes online.

From my perspective, Halo 2 was sold by a massive marketing campaign and the success of Halo. However, it delivered less value than the first game. Especially with the Part1/Part2 campaign split lack of an ending in the orginal game. If Halo 3 hurts the PS3 it will simply be because of the amount of money Microsoft throws behind it. I'm not sure if they can top the launch for Halo 2, though. That was definitely the most expensive game launch in history, what with giving away free copies of the game and system to practically every TV news team in North America.

Seems almost ironic doesn't it?

No, it doesn't. Not at all.

It seems hypocritical, actually.

Maybe this will help next time.

Time and time again security through obscurity has proven to be a fallacy.

An impossibility, one might say, but certainly not a fallacy. Fallacies are invalid supporting logic.

Considering that I run two profitable anti-Bush stores, that I campaign publically against the ethical practices of the republican party (have been on television for it,) and that I've held public office, I think you'd do well to investigate someone's background before calling them complacent. Chances are very good that I've done a hell of a lot more about the situation than anyone you know personally. Perhaps instead of lashing out at anyone who disagrees with you or points out your hypocrisy, you could begin to do something more productive than pointing fingers.

By the way, that's called Argumentum ad Hominem - trying (and failing) to make your point by attacking the person to whom you speak.

Buttsecks?

Of course, the fallacy of the comparison is

It's a falsehood, not a fallacy. They're very different things, and cannot be used exchangably. The falsehood is that the several OSes are equivalent and may be lumped together. Given that there is no argument being made, no fallacy is possible at all.

Bzzt. The person to whom you're replying is in fact quite correct. Using the word decimate in any sense other than to destroy a tenth of is a signator of a low quality of education.

In fact, I'd venture to say that perhaps one native English speaker in a hundred is even aware of the other definition, and that your post just sounds really weird to the other 99.

Are you really attempting to argue that the word decimate's meaning is anything other than painfully obvious? If so, your grasp of the language isn't really strong enough to be criticizing other people, much less to the degree of challenging whether or not someone else speaks it as a first language.

You strike me as the sort of person who attempts to defend bad definitions of irony just because it's what they grew up with. Here's a hint: ignorance is not linguistic drift, and just because you hang out with ignorami who don't know how to speak using words in a proper fashion doesn't mean that the language has changed to suit you.

Before you get off onto some predictable rant about how language changes and how anything you and your buddies do wrongly is a reflection of progress in English, please take some classes on linguistics. It turns out that generations tend to have mistakes which neither their parents nor their children reflect. Your dad almost certainly doesn't make the mistake with the word decimate that you do; it's a foul error that the media started making in the early 1980s, around the same time they bollocksed up the words indicted, alleged and translucent.

Please stop feigning a deep familiarity with English; it ain't there. That you (claim to) make a living writing suggests to me that either your editor is desperately overworked or appallingly underskilled.

Bzzt. The person to whom you're replying is in fact quite correct. Using the word decimate in any sense other than to destroy a tenth of is a signator of a low quality of education.

In fact, I'd venture to say that perhaps one native English speaker in a hundred is even aware of the other definition, and that your post just sounds really weird to the other 99.

Are you really attempting to argue that the word decimate's meaning is anything other than painfully obvious? If so, your grasp of the language isn't really strong enough to be criticizing other people, much less to the degree of challenging whether or not someone else speaks it as a first language.

You strike me as the sort of person who attempts to defend bad definitions of irony just because it's what they grew up with. Here's a hint: ignorance is not linguistic drift, and just because you hang out with ignorami who don't know how to speak using words in a proper fashion doesn't mean that the language has changed to suit you.

Before you get off onto some predictable rant about how language changes and how anything you and your buddies do wrongly is a reflection of progress in English, please take some classes on linguistics. It turns out that generations tend to have mistakes which neither their parents nor their children reflect. Your dad almost certainly doesn't make the mistake with the word decimate that you do; it's a foul error that the media started making in the early 1980s, around the same time they bollocksed up the words indicted, alleged and translucent.

Please stop feigning a deep familiarity with English; it ain't there. That you (claim to) make a living writing suggests to me that either your editor is desperately overworked or appallingly underskilled.

+ DS cartridges cost less than PSP UMDs (the UMD uses more plastic and metal in the casing alone than the DS cartridge does as a whole).

I wonder what gave you this idea. The manufacturing cost of a minimum size DS cartridge (64 megabits) is marginally cheaper than UMD, including case. As the size goes up, so does the cost; by the time you've hit 256 megabits, you're more expensive than a UMD.

Disks mean load times.

Certainly true, and a much bigger issue than most people admit.

+ Blu-Ray disks are not inexpensive to manufacture, when you add in the $2 million cost per production line (assuming all Blu-Ray lines will be adapted from existing DVD lines) that will get funnelled down to consumers.

This is pretty silly. You think that the Matrix Semiconductor 3d FRAM plant costs less to make than the UMD plant? (By the way, blu-ray is the next gen DVD format, not what the PSP uses. They're fundamentally different.)

+ Nintendo DS's current market share is more and more becoming predominantly teen to twenty something women. The DS was launched for the older gamer, believe it or not.

Where are you getting your data? The primary market demographic for the DS is the 7-11 cross-gender range, the secondary demographic is the 13-17 male range, and the tertiary demographic is the young male range. Young adult females are well represented in comparison to consoles, but they're certainly not the platform's primary demographic, nor are they what the platform was launched for. A quick inspection of the commercials or launch titles will tell you exactly who Nintendo thought their market was.

The PSP wireless support is terrible at best. I have not played a match of Twisted Metal to completion without getting dropped.

Yeah, that's more about your wifi hardware than the PSP. The vendors of the Nintendo and Sony wifi hardware are comparable in quality.

Also, DS supports any wi-fi connection, and provides a universal network, a-la Xbox Live, for players to connect to.

This is, admittedly, a big win. That said, they're a year late to really use it, which is a serious loss, and the libraries they ship to their developers are hamstringing in terms of the ability to use the net in any way other than a carrier to dedicated servers. To deploy actual socket-aware software would require reinventing the network stuff from the ground up, and the likelihood of Nintendo authorizing such software is near-zero.

Luckily, I'm fixing this.

Proprietary DVD format came from the fact that Nintendo agressively fights pirating, which is a hell of a lot harder to do when off-the shelf DVD-R's don't fit in your machine.

Er. The PS2 format was proprietary too. As far as off the shelf DVD-Rs, sure, the DVD-R Minis fit just fine. The primary problems with piracy in the GameCube are that 1) the discs are encrypted in a fashion that was (thank god) never broken, and 2) the discs are spun in the opposite direction of normal discs, requiring custom firmware, a laser realignment and a new motor for a writer, something well outside of the ability of most pirates.

By the time Mortal Kombat was released, Sega was already semi-dominant. Sega had a commanding lead at the beginning of the 16-bit era, which only closed in the latter years of that generation.

There's argument about this. I won't say you're wrong, but I will say I disagree with you. Many people believe the big nail that started Sega's coffin was the nonsense confusion about the saturn and the sega cd. Nintendo closed the gap primarily on software dominance; people who agree with me tend to believe that Nintendo started closing the gap about two years after the release of the SNES, primarily on total RPG and fighter dominance (go ahead, name two Genesis RPGs other than Sword of Vermillion without looking online for cues. No need to reply to do so; it's a thought exercise.) Many people believe

Heck, I wouldn't even build notepad for Linux if I thought it would cause people to leave my main product.

Maybe not, but apparently they have their own version of vi.

You're a little late, but you needn't make up for it with rudeness.

I find it quite cathartic to speak down to people who are speaking down to others from platforms of ignorance. If you dislike that, you have three options: put me in my place, admit what I believe about your comprehension, or don't reply.

No. Theory only predicts that there is likely to be a 'selection' if there is a means for the selection (variation) and a reason for the selection (preference). An organ may be useless, but if there's no variation, or if its cost is minimal compared to other selection factors, then selection isn't expected to occur.

In fact, that was exactly my point, hinged on the fairly obvious contention that maintaining a five pound slab of meat is very expensive in terms of food and immunological cost.

No. We don't lack gills simply because they take energy to grow and therefore children without gills somehow survive more easily.

Oh really? Because we used to have them. Where'd they go? And why, if not because maintaining two oxygen blood exchange systems is fantastically expensive? (Hint: after the brain, the skin and the liver, the lungs are the most expensive organs to maintain. Lungs and lung-analogs will be the fourth to go.)

You fall prey to the same fallacy as everyone else, assuming that because an organ is useless in your eyes, it will be useless in the virtual eye of natural selection.

1) That's not what a fallacy is.

2) That's one of the critical underpinnings of natural selection - maintenance cost as an environmental stress. You brought natural selection up, not me. Now you want to say it's off of the point?

If it did come with guarantees, that might almost be proof of a Creator, who would have designed the process with a goal in mind.

Yes yes, trying to make me out to seem like a religious nut (that's called a Straw Man, by the way) is cute and all, but I never said or even implied anything about perfection. I was quite clear to couch my predictions in terms of statistical significance. If you don't know statistics, you may not understand what that means, but it's quite poison to this notion of perfection of yours. It's a big dice game, nothing more. That said, over the course of the fossil record, and recently in life, we have evidence of this sort of thing happening hundreds of thousands of times.

If you evolve AIs in a lab, and then have them meet real-world gamers, you're introducing an entirely new, foreign constraint to them.

Look, I don't know where you're getting this stuff. A human can't give a chess game any different inputs than another chess game can. It's chess rules, pure and simple. I'm sure you're trying to make some point that the way a human plays chess is somehow significantly different an input, but that's just baloney. That's like suggesting that the vicar's wife method is significantly different than the bingo cage method for picking random numbers. It's malarky.

You can go ahead and wave your hands all you want, but projects like Blondie24 have shown several times that annealing generates admirable opponents even when trained against its own. You can insist there are subtle qualitative differences, but experience suggests otherwise, so I'll wait for your examples until I give any credence to your appeals.

Give me citations, not assertions.

Furthermore, if you try to hurry things up in the lab by keeping only the top z% of the agents (cream of the cream), it's entirely possible that your population will skew in a random direction -- butterfly effect, essentially.

Only in the complete absence of an evolutionary pressure. Have you ever even done one of these systems? And why didn't you answer when I asked you if you'd read Darwin's books?

Without continuous outside testing and some way of rectifying these anomalies, you may in the end have AIs that are

I agree with the sentiment, but that's not what irony means.

If you want to worry about the exposure of impressionable young minds to bad information, I suggest you begin by learning the difference between fallacy and falsehood.

No, in the absence of any measures, information ceases to exist. Fail to remember, fail to record it, fail to anything with it and it doesn't exist.

Nature records information all the time. There will always be information available to any who wish to retrieve it.

How is it that you get from "in the absence of measures" to "nature is making recordings?" There are two things to which you might be referring. A more careful selection of language reveals them both to be fundamentally broken arguments.

One is that an active process of nature creates a derivative product of information with long-term storage characteristics. One can make this non-argument for cases like fossils, where the information of the creature's structure can be determined occasionally billions of years after the organism itself disappears. The problem is, this isn't the lack of measures to maintain information to which the grandparent referred; there requires some active process, such as sedimentation or water fossilization (petrifaction) in order to occur. In the absence of such a mechanism, which is extremely rare (there's a reason there are so few fossils,) creatures do not leave significant information behind.

The other case is more difficult to explain. There is the argument that information is retreivable through some or another forensic process. Examples include using carbon patterns to determine the nature and temperature of fires or lava, gulleys to divine the presence of water on Mars, and pretty much anything you'd see on CSI: Miami which isn't a self serving pablumessage about the evils of racism or profiteering or some damned thing. There are those who would try to cast this as Nature or The World or something "recording information" which the intrepid researcher can come back and re-discover. Find something rotting? Plot out the progress of the putrifaction and you can (mostly) reconstruct the corpse's original state.

The problem is, that's not recording information at all. That's an incomplete loss of information. In many ways you can think of the physical world as an immensely error correcting signal. This is a fundamentally false analogy, but it serves my explanatory purpose, so run with it anyway. What we're doing when we walk back through partial information to reconstruct the original information is not finding other recordings of that information. What we're doing is looking for correlary effects which when summed give us the complete set of original information. It may sound like the same thing, but there's a critical semantic difference: we're not relocating, we're recreating. Granted it's the same information. Still, it's information lost and remade from evidence, not information located through crafty means.

The difference is quite real. I'm not just playing semantics. Consider The Einstein Puzzle as a good example of a way to recreate lost information, whose goal can only be reached thus.

"Information wants to be free" may not be as accurate as "people generally want to share information and make it available", but sounds a bit more philosophicalisticalish.

If you choose your phrasing to make yourself sound smart instead of to accurately convey information, then you deserve the opinion of ignorance other people aim your way. Besides, philosophy literally translates as "the love of knowledge;" even if the word meant what you seem to think it means, the bit about sharing would be far more in tune with the word than some vacuous notion about the supposed intent of recorded state.

there is nothing that the government can do even half as efficiently as the collective power of tens of millions of people with nothing better to do with their time than plink.

Exactly what do you think the government is, if not the collective power of tens of millions of people with nothing better to do with their time than solve tasks? (Yes, tens of millions. The government employs more than 5% of this nation, and the nation's around 300 million these days.)

The hardware's superior

No, it isn't. The X-Box is. The reason Nintendo can sell the GC so cheap is that it's not nearly as powerful, and therefore it doesn't cost as much to make. Don't get me wrong; I love Nintendo like family. But, look at the specs.

DSlinux.org and Gamemaker port for the win!

DSLinux is no less a cute toy than the GBA Java VM or GBA Contiki, until we have connectivity.

where's the PS2 titles?

I presume you mean PS3 titles, since the PS2 has thousands of games on the market today. That said, the PS3 has demoed roughly the same amount that the 360 has; it's just that Microsoft is better at marketing than Sony is. If you had gone to E3, you would have seen a lot of fairly one three three seven PS3 stuff.

Maybe developers are having problems dealing with a CPU that has terrible integer performance and a wacky memory system with too little local memory to do a few algorithms like say... collision detection on the SPEs?

Maybe you shouldn't guess at what part of programming is hard until you're a programmer. What you just said is equivalent to "maybe the spark plugs fire so hot that the engine block expands and grinds to a halt" - that is to say, something that sounds superficially reasonable until you know the actual tolerances involved.

Plus, it's sorta ironic, that what goes around comes around.

That's not what irony means.

Sorta "we're the Big N, we're King. If you want to be allowed to develop for our console, you worthless insignifficant peon, sign there that you're not allowed to _ever_ publish _any_ game for any other system."

Yeah, and you could only publish five games a year, too. They did that for a good reason. It was harsh, and they kept it up too long, but that's what salvaged video gaming. It's also the reason there was a Robbie the Robot.

See, the problem was, Nolan Bushnell didn't know how to keep a tight leash. He treated his programmers like crap (wouldn't even put their names in the manuals, even when it was a two-person job back then, ffs.) As a result, a big block of his programmers split off and formed the first independant game software company, Activision; they were quickly followed by several other outfits.

Now, by the standards of their day, Activision kept their shit together for a while. They were about the only ones. Suddenly, there were 30 ripoff pacmans on the market. Some would crash; a few wouldn't even boot. The market was flooded with crap.

Much like the reaction to the immense mass of crap FPSes in the mid to late 90s (RoTT comes to mind,) parents began to balk, to return too many games; publishers went under. There wasn't this huge mass of other genres to fall back on, like there was with the FPSes; it was the whole market, that time. Quickly, the only games that would sell were games attached to big names, such as movies, since they had the budgets to follow through a four man team for 6 months. (Those were the days.)

Then, ET went big. Much bigger than anyone expected. Way, way too late in the year. The person who managed to get the contract was already spread far too thin. He contracted a single individual to write that game in six weeks, including the art support and writing the manual. Remember, this was pure-ASM days, and it's not easy to write a game for a machine which has no video ram; updating the raster on the h-blank costs you nearly all of the almost-zero CPU time that thing had to throw around.

The result, as you can imagine, was crap. 'Course, you don't need to imagine; everyone throws this game around as an example of the worst game in history, though in fact there are far worse; even though the game sucks, it has no major flaws outside of that it sucks: no crashing bugs, no accidental impossible levels, etc.

Nonetheless, every parent on earth had gotten ET for the 2600 for their kids for christmas. Because the movie had such wide appeal to both kids and parents, the parents often sat down and tried to play it with their kids.

As the old phrase goes, it was the straw that broke the camel's back. It turns out that the game had been made with some fantastically bad decisions: for example, twice as many carts were made as there were systems in circulation, because someone actually believed that that game would singlehandedly drive console circulation to double based on the popularity of the movie. (Had the game not sucked, there's a reasonable chance it might have gone halfway that far.) Furthermore, Sears had been hornswaggled into a contract which made them take the bullet for returns, instead of the publisher, something unheard of in the retail industry.

They lost tens of millions of dollars. Remember, Sears Roebuck was in the seventies what Walmart is now - the 800 lb gorilla whose word made or broke you. When sears trashed all consoles that february, video gaming looked like its first generation was at an end.

It was two years before retail took consoles seriously again. Nintendo was who pulled it off, and they pulled it off by both understanding and duping the retailers, in addition to being at the right technology place at the right time. This required three things:

1) It was the era where RAM dropped to the price point where fu

Huhuhuhu. Just you wait until the bounty succeeds - when the amateur community has TCP/IP, gaming changes overnight.

<whore type="money" style="tired">Donate now!</whore>