The correct term for stun guns and pepper spray is "less lethal". People HAVE died from stun guns. I don't know about pepper spray, but I could imagine a fatal allergy or a blinded/stunned person taking a fatal fall. (Leaving aside the flammable propellant problem, which AFAIK is no longer an issue.)
That said, I would prefer more stun guns and fewer firearms on the streets, so if I were the judge I'd rule they were at least as protected as modern firearms are. OTOH, I'd *also* prefer all weapons regulated with mandatory background checks and waiting periods at the very least.
2. Party in power manipulates poll hours and ID requirements so that working poor and other groups can't vote without taking time off work, standing in long lines, triple-checking their papers, etc.
3. Working poor, etc., not only still have no voice but owe money for being excluded from voting.
(4. PROFIT!)
We need to make voting as easy and transparent as possible, not to impose rules the disenfranchised can't follow.
To all the people who say "women don't want to work in tech", note that women were the MAJORITY in the early days of computing, right up until the advent of personal computers. (Source) From the article: "... families were much more likely to buy computers for boys than for girls — even when their girls were really interested in computers."
So it's quite probable women WOULD go into tech fields... if they had encouragement, a pleasant working atmosphere, and at least some assurance that motherhood wouldn't throw them completely off their career track.
Weather is also a factor. Our power has gone out sporadically (usually preceded by the loud pop of something getting fried), and it usually comes back within an hour or two of my calling. Except during the Great Dallas Ice Storm which happens *every year* and which *nobody* seems to plan for. The last two years the power has been out for days, which is especially fun with an elderly invalid. The fact that the city/county response to ice is to toss some sand and ice on it, compounded with Dallasites inability to drive even during good weather, prolongs response times even further. But I still blame Oncor.
To my mind, the best managers set up conditions for their staff to succeed and defend them against higher-level managers. That's it. Managers should take care of head-count and hiring and meetings and all the other boring but apparently necessary stuff; they shouldn't be responsible for *any* analysis and design, let alone coding. Because all the "boring" stuff will eat up someone's time, and better the designated victim, I mean manager, than someone responsible for making progress.
The *worst* managers, in my not-too-atypical experience, are the rock-stars, micromanagers, timekeepers, and corporate climbers. True rock-star programmers should be writing code, not going to meetings... and if they can't cooperate with the rest of the team they shouldn't be on the project at all. Micromanagers second-guess their staff and the staff waste valuable work time indulging the boss. Management by Gantt chart is even worse, since estimates in software are rough guesses, not contractual commitments; the work takes as long as it takes, for a set amount of work, and forcing the staff to work harder to satisfy a bogus schedule only makes work later (or buggier). Worst of all are the managers who are simply mouthpieces and boot-licks for their bosses, because they'll throw you under the bus for any perceived failure and claim credit for all your successes, often both at the same time.
It depends which parts are "agile" and which are "waterfall". From my not-exactly-vast experience, whatever mix you choose has to address four concerns:
1. WHAT ARE YOU BUILDING? Seriously. This is where the extra planning of "waterfall" -- itself a misunderstanding of someone else's comments -- comes in. One of my first jobs was a derivatives trading app in a perpetual tug of war between an outspoken exotic derivatives trader, back office and compliance folks wanting to automate trade reconciliation, risk managers wanting to manage risk, and the rest of the trading desk who just wanted to price whatever deal they were trying to do (vanilla or not). The end result was a kludgey mess that everyone hated.
2. HOW DO YOU ALLOW FOR GROWTH? There are right ways and wrong ways. Agile has a good tip: build only what you need, and as cleanly as you can. Better said than done, of course, and sometimes (as the Pragmatic Programmers have said) you *know* there will be a database in there sooner or later, so plan your architecture accordingly even if it's a little awkward short-term. Then there's the wrong way, which I saw in one project: build a "flexible" architecture with "configurable" components so that you can do "anything"! 1) KNOW WHAT YOU'RE BUILDING, even in broad strokes (see above). 2) For software to be reusable, it must first be usable for *something*. 3) If your "flexible" and "configurable" architecture takes more time to modify than writing straightforward code would take, it has failed; start over. 4) It's better to use open-source architecture than build it yourself. (Buying is also better, but beware of vendor lock-in and every-increasing fees, especially if you only use a small part of an elaborate framework.)
3. HOW DO STAKE-HOLDERS REQUEST CHANGES? No specification will be adequate out of the gate, and unless you're working for NASA or the military people CAN and WILL request changes, sometimes while you're building the product and certainly once people begin using it. Do you jump when they say how high? Do you have a long and slow review process? Do you work individual tickets? Do you have potentially disruptive "projects", and if so how do you integrate them back into the main project? Different applications have different rates of change and different tolerance for defects, but it's best to work out change process before the complaints come in.
4. WHEN AND HOW DO YOU CUT YOUR LOSSES? Despite your best efforts the whole thing will become obsolete or unmaintainable, sooner or later (hopefully later). As in point #1, have some idea which you're building, and at what point do you deprecate it to build something better. (This is the hardest part for many organizations; why can't the floor wax also be a salad dressing?) At some point make a plan, refactor your code base -- over time! -- to separate the parts you'll keep from the parts you don't need, and toss out the latter. If a radical rewrite is the only way to go, bite the bullet and do it, with appropriate safe-guards like regression tests. If you can't evolve or replace your product, a competitor -- maybe within your own organization -- will do it for you.
That's my long-winded advice, from someone who's watched many "successful" and "unsuccessful" projects die. Nearly all in-house software is a Potemkin village designed to keep the tzars happy. If the tzars aren't happy, the fake village is set ablaze and you, the fake peasants, go to Siberia. The only real question is how to keep your frantic peasant dance going as long as possible without dying of exhaustion or being sent to Siberia.
TL;DR: Plan the limits, goals, requirements, and large-scale architecture up front (erroneously called "waterfall"). But planning never really ends; stay agile to correct your course or take advantage of opportunities... and be willing to throw the whole thing away if warranted. Also, keep your resume updated.
"On average, girls are - for whatever reason - less interested in math, physics, chemistry.... Likely, these preferences are based in biology..."
The Code.org article said none of this. In fact, it freely acknowledged social pressures that discourage women from entering or staying in tech. It's not unreasonable to suppose stories from women in tech discourage the next generation from even attempting to enter computer-related fields. It helps to read the freaking article.
As others have said, people -- mostly male upper-class Europeans -- have used biology to justify slavery, denying women/minorities the vote, giving harsher sentences to black or Eastern European defendants, and so on. (And I'm not even Godwinning.) Read Steven J. Gould's _The Mismeasure of Man_, then read Carol Tavris's _The Mismeasure of Woman_.
*People* are different, and like different things. Men and women, however, aren't that different (roles in reproduction excepted), so a statistically significant difference points to a social or psychological cause, not biology.
That said, the PC isn't itself the problem, as the TFA -- or maybe just the summary -- seems to imply. Looking at other professions with gender imbalances, though, one can posit a few underlying causes. a) Secretaries were once men who helped important people with important matters; once the typewriter came in, women seized on typing as a "respectable" way to support themselves and the modern secretarial pool was born. (See http://www.stuffmomnevertoldyou.com/podcasts/why-is-secretary-the-most-common-job-for-women-in-the-u-s/) b) Blechley Park and earlier research projects employed female "computers" before they developed electric ones because women worked hard and worked cheap. All the mathematical whizzes, however, were upper-class men; who would pay for a woman's education, when they would just get married and pop out kids? (See also Disney animators.)
Obviously somebody needs to do solid research, but one could hypothesize that the PC coincided with three trends: the growth of male-dominated "hacker" culture, the use of PCs by Serious Men for Serious Business, and the decline of mainframes (i.e. server rooms in which nobody knew or cared women worked). Without hard data, though, this is mere conjecture. Loads better than "women don't like computers", though.
Legacy properly describes a software system, not a language. Languages rise and fall in popularity. Sometimes a language has inherent limits, sometimes the implementation stinks, sometimes the syntax or paradigm no longer become fashionable. Sometimes languages and platforms disappear only to re-emerge years later. Back in the late 1990's NeXTSTEP/OPENSTEP was turning into a "legacy platform"... yet today MacOSX and iOS rely on Objective-C and descendants of the NeXT APIs. Even if a language fades completely from the mainstream its ideas inspire new languages: Java borrowed from Objective-C and C++; Ruby borrowed from Perl, Smalltalk, and a little from Eiffel.
Stay in the industry long enough, you'll see everything come back.
Is this a valid analogy? In short, no. A bit longer answer: NOOOOOOO. For a full explanation, read on.
I can't speak to how construction works, but I know how software development and developers work. Usually software breaks not because of a bad developer, but because of integration issues and subtle interactions which are hard to detect, and even harder to assign "blame" to without a lot of investigation. The investigation is generally the hardest part, so you'll have to charge time already spent.
Worse, your boss is proposing a "blame game" where every defect is somebody's fault, almost always somebody on the current development team. Far from encouraging better software, this will keep developers from entering their own bugs (or any bugs) into the bug tracking system, and encourage finger-pointing rather than collaboration. Meanwhile, your boss thinks he'll save money by making developers work for free "on their own time". In the worst case, the person who touched a piece of code is IT, whether it's a legitimate mistake or a weird edge case. What you'll get is a workplace full of egos, fiefdoms ("don't mess up MY code"), and destructive competition.
[I]Spirit of the Century[/I] technically uses the Open Gaming License, but it has no actual content from the d20 SRD. It just uses the text of the OGL for compatibility with FUDGE (which does the same), and in turn to make the core of the FATE system free for others to build upon.
See http://zork.net/~nick/loyhargil/fate3/fate3.html for the license (and the entire FATE 3/SotC SRD, as it currently exists).
Want a low-magic world centered on non-magical heroes, like most pre-D&D fantasy fiction? Chop out 3/4ths or more of the PHB. Better yet, write your own rules to make fighters cool (*cough*[I]Iron Heroes[/I]*cough*), because all you've got left are Fighters, Rogues, Barbarians, and maybe Rangers and Monks.
Want realistic heroes who don't shrug off dagger thrusts as they gain experience? Find a "grim and gritty" hit point and damage system "patch" on RPGNow, because it's not in the "kernel".
Those are the two big problems I have with D&D. That's why I find myself gravitating to "generic" or rules-light systems... they're made for tinkering.
- RuneQuest, Call of Cthulhu, and Basic Roleplaying: pretty much the same system,
- GURPS: character creation is a right pain, but after that it's smooth sailing. (Also a descendant of Steve Jackson's Melee/Wizard, which first lured me away from D&D.)
- FATE, especially its current incarnation [I]Spirit of the Century[/I]: a fast and light system that actually makes combat fun and interesting without giving other parts of the game short shrift.
- PDQ: a really lightweight game engine, with a more abstract "narrativist" approach to combat... not really suited to grim-and-gritty settings, but it's beauty is its simplicity and flexibility.
For someone condemning invective, you're pretty harsh on PZ. I perused his website, and didn't find any egregious or unwarranted insults.
Having followed the skeptical movement for a while, though, I have noted that many of them, at some point, stop being polite and just tear into beliefs, or occasionally people. Read James Randi's site (www.jref.org) for some prime examples. I suspect it's because, after seeing the same foolishness repeated over and over again with snazzy new names and charismatic new proponents, their frustration becomes unbearable.
I haven't even read TFA, but I know that gperf isn't for command lines; getopt() (in its various forms) more than adequately does its job.
One real use of gperf and perfect hashes that I know of is in TAO (The ACE ORB), an implementation of CORBA. Since CORBA includes the class and method names as strings, a perfect hash speeds up each lookup of the actual routine to call.
In modern times, I can imagine gperf (or a Java/C#/Ruby/whatever port) speeding up SOAP or other XML-based protocols.
Actually, I think it was an Outer Limits episode (the old series). Could be "Wolf 359", but it's been ages since I've seen the series, and I'm only going by the plot synopsis on Wikipedia.
The problem I have is with pathnames. On my machine, Java, Ruby, and Emacs are compiled for Windows and use the 'c:\...' convention. Cygwin tools understand only forward slashes, and consider '/' to be 'C:/cygwin/' and 'C:\' to be '/cygdrive/c/'. So all my shell scripts have to convert paths, and I have to run Ruby scripts in CMD.COM because it can't find/cygdrive/c/ruby/...
Plus, programs compiled with Cygwin's GCC only work within a Cygwin shell. I've yet to link to mingw successfully, though.
BTW, the creator is also the director of The Call of Cthulhu, an independent film based on Lovecraft's story, which I highly recommend to Lovecraft fans and people who can deal with low-budget effects.
But see also http://onestepback.org/articles/TddMeetsDbc by the same author, who presents a combined DbC/Unit Testing framework for Ruby. (Unfortunately, it relies on Ruby syntax to create a mini-language within Ruby itself.)
Apart from "it's too hard", I think Unit Testing has overtaken DbC as an approach.
- You can write unit tests in any language, with or without a framework. (I saw a "mini-framework" for C that consisted of three macros and a coding convention.)
- In a test, you can specify assertions before and after each method call. It's a little more tedious to represent classic DbC assertions, but the Abstract Test pattern among others allows you to collect common code.
- You can strip out assertions in production code simply by leaving test code out of the product.
- Unit tests also run scenarios automatically, without an extra "test driver".
The one thing Unit Testing *can't* do is check production code as it's running. On the one hand, that's great at catching conditions you never thought of. On the other hand, customers tend to get annoyed if their app shuts down. I'm sure there's some work on partial in the Eiffel world, but so far I haven't seen any.
I worry more about the already laboring tabletop RPG and CCG markets. How long before they get pushed to the edges of the floor, or segregated into their own smaller room? Two years? One year? Five seconds?
ComiCon (in San Diego, Chicago, and everywhere else) have absorbed the media presence, so the original supporters of GenCon might be all right... but World of Warcraft is even better crack than Magic: The Gathering.
Companies like RPGNow.com, DriveThruRPG.com, Indie Press Revolution, and even Lulu.com offer everything from OGL/d20 supplements to wholly new and innovative RPGs that someone running a business would never take a risk on. Lowering the barriers and eliminating middlemen does increase the amount of crap... but then pen-and-paper gamers will rely on online reviews and well-known columnists instead of what Wizards of the Coast, Steve Jackson Games, White Wolf, or some other game company decides to push.
Online distribution sucks for the old-time publishers, and for the game stores which already have to diversify into puzzles, traditional games, and How To Host Your Own Murder... but even if it's just a few sad geezers who still remember arcane skills like "throwing dice", "using your imagination", and "reading" the RPG as a hobby won't die.
Slashdot Mirror
The correct term for stun guns and pepper spray is "less lethal". People HAVE died from stun guns. I don't know about pepper spray, but I could imagine a fatal allergy or a blinded/stunned person taking a fatal fall. (Leaving aside the flammable propellant problem, which AFAIK is no longer an issue.)
That said, I would prefer more stun guns and fewer firearms on the streets, so if I were the judge I'd rule they were at least as protected as modern firearms are. OTOH, I'd *also* prefer all weapons regulated with mandatory background checks and waiting periods at the very least.
Did no one learn from Ray Milland in _The Man with the X-Ray Eyes_?
1. Voting becomes compulsory.
2. Party in power manipulates poll hours and ID requirements so that working poor and other groups can't vote without taking time off work, standing in long lines, triple-checking their papers, etc.
3. Working poor, etc., not only still have no voice but owe money for being excluded from voting.
(4. PROFIT!)
We need to make voting as easy and transparent as possible, not to impose rules the disenfranchised can't follow.
To all the people who say "women don't want to work in tech", note that women were the MAJORITY in the early days of computing, right up until the advent of personal computers. (Source) From the article: "... families were much more likely to buy computers for boys than for girls — even when their girls were really interested in computers."
So it's quite probable women WOULD go into tech fields ... if they had encouragement, a pleasant working atmosphere, and at least some assurance that motherhood wouldn't throw them completely off their career track.
It all started with this business of writing things down. People can't remember epics anymore! -- some old Greek dude
Weather is also a factor. Our power has gone out sporadically (usually preceded by the loud pop of something getting fried), and it usually comes back within an hour or two of my calling. Except during the Great Dallas Ice Storm which happens *every year* and which *nobody* seems to plan for. The last two years the power has been out for days, which is especially fun with an elderly invalid. The fact that the city/county response to ice is to toss some sand and ice on it, compounded with Dallasites inability to drive even during good weather, prolongs response times even further. But I still blame Oncor.
To my mind, the best managers set up conditions for their staff to succeed and defend them against higher-level managers. That's it. Managers should take care of head-count and hiring and meetings and all the other boring but apparently necessary stuff; they shouldn't be responsible for *any* analysis and design, let alone coding. Because all the "boring" stuff will eat up someone's time, and better the designated victim, I mean manager, than someone responsible for making progress.
The *worst* managers, in my not-too-atypical experience, are the rock-stars, micromanagers, timekeepers, and corporate climbers. True rock-star programmers should be writing code, not going to meetings ... and if they can't cooperate with the rest of the team they shouldn't be on the project at all. Micromanagers second-guess their staff and the staff waste valuable work time indulging the boss. Management by Gantt chart is even worse, since estimates in software are rough guesses, not contractual commitments; the work takes as long as it takes, for a set amount of work, and forcing the staff to work harder to satisfy a bogus schedule only makes work later (or buggier). Worst of all are the managers who are simply mouthpieces and boot-licks for their bosses, because they'll throw you under the bus for any perceived failure and claim credit for all your successes, often both at the same time.
It depends which parts are "agile" and which are "waterfall". From my not-exactly-vast experience, whatever mix you choose has to address four concerns:
1. WHAT ARE YOU BUILDING? Seriously. This is where the extra planning of "waterfall" -- itself a misunderstanding of someone else's comments -- comes in. One of my first jobs was a derivatives trading app in a perpetual tug of war between an outspoken exotic derivatives trader, back office and compliance folks wanting to automate trade reconciliation, risk managers wanting to manage risk, and the rest of the trading desk who just wanted to price whatever deal they were trying to do (vanilla or not). The end result was a kludgey mess that everyone hated.
2. HOW DO YOU ALLOW FOR GROWTH? There are right ways and wrong ways. Agile has a good tip: build only what you need, and as cleanly as you can. Better said than done, of course, and sometimes (as the Pragmatic Programmers have said) you *know* there will be a database in there sooner or later, so plan your architecture accordingly even if it's a little awkward short-term. Then there's the wrong way, which I saw in one project: build a "flexible" architecture with "configurable" components so that you can do "anything"! 1) KNOW WHAT YOU'RE BUILDING, even in broad strokes (see above). 2) For software to be reusable, it must first be usable for *something*. 3) If your "flexible" and "configurable" architecture takes more time to modify than writing straightforward code would take, it has failed; start over. 4) It's better to use open-source architecture than build it yourself. (Buying is also better, but beware of vendor lock-in and every-increasing fees, especially if you only use a small part of an elaborate framework.)
3. HOW DO STAKE-HOLDERS REQUEST CHANGES? No specification will be adequate out of the gate, and unless you're working for NASA or the military people CAN and WILL request changes, sometimes while you're building the product and certainly once people begin using it. Do you jump when they say how high? Do you have a long and slow review process? Do you work individual tickets? Do you have potentially disruptive "projects", and if so how do you integrate them back into the main project? Different applications have different rates of change and different tolerance for defects, but it's best to work out change process before the complaints come in.
4. WHEN AND HOW DO YOU CUT YOUR LOSSES? Despite your best efforts the whole thing will become obsolete or unmaintainable, sooner or later (hopefully later). As in point #1, have some idea which you're building, and at what point do you deprecate it to build something better. (This is the hardest part for many organizations; why can't the floor wax also be a salad dressing?) At some point make a plan, refactor your code base -- over time! -- to separate the parts you'll keep from the parts you don't need, and toss out the latter. If a radical rewrite is the only way to go, bite the bullet and do it, with appropriate safe-guards like regression tests. If you can't evolve or replace your product, a competitor -- maybe within your own organization -- will do it for you.
That's my long-winded advice, from someone who's watched many "successful" and "unsuccessful" projects die. Nearly all in-house software is a Potemkin village designed to keep the tzars happy. If the tzars aren't happy, the fake village is set ablaze and you, the fake peasants, go to Siberia. The only real question is how to keep your frantic peasant dance going as long as possible without dying of exhaustion or being sent to Siberia.
TL;DR: Plan the limits, goals, requirements, and large-scale architecture up front (erroneously called "waterfall"). But planning never really ends; stay agile to correct your course or take advantage of opportunities ... and be willing to throw the whole thing away if warranted. Also, keep your resume updated.
"On average, girls are - for whatever reason - less interested in math, physics, chemistry. ... Likely, these preferences are based in biology ..."
The Code.org article said none of this. In fact, it freely acknowledged social pressures that discourage women from entering or staying in tech. It's not unreasonable to suppose stories from women in tech discourage the next generation from even attempting to enter computer-related fields. It helps to read the freaking article.
As others have said, people -- mostly male upper-class Europeans -- have used biology to justify slavery, denying women/minorities the vote, giving harsher sentences to black or Eastern European defendants, and so on. (And I'm not even Godwinning.) Read Steven J. Gould's _The Mismeasure of Man_, then read Carol Tavris's _The Mismeasure of Woman_.
*People* are different, and like different things. Men and women, however, aren't that different (roles in reproduction excepted), so a statistically significant difference points to a social or psychological cause, not biology.
That said, the PC isn't itself the problem, as the TFA -- or maybe just the summary -- seems to imply. Looking at other professions with gender imbalances, though, one can posit a few underlying causes. a) Secretaries were once men who helped important people with important matters; once the typewriter came in, women seized on typing as a "respectable" way to support themselves and the modern secretarial pool was born. (See http://www.stuffmomnevertoldyou.com/podcasts/why-is-secretary-the-most-common-job-for-women-in-the-u-s/) b) Blechley Park and earlier research projects employed female "computers" before they developed electric ones because women worked hard and worked cheap. All the mathematical whizzes, however, were upper-class men; who would pay for a woman's education, when they would just get married and pop out kids? (See also Disney animators.)
Obviously somebody needs to do solid research, but one could hypothesize that the PC coincided with three trends: the growth of male-dominated "hacker" culture, the use of PCs by Serious Men for Serious Business, and the decline of mainframes (i.e. server rooms in which nobody knew or cared women worked). Without hard data, though, this is mere conjecture. Loads better than "women don't like computers", though.
Legacy properly describes a software system, not a language. Languages rise and fall in popularity. Sometimes a language has inherent limits, sometimes the implementation stinks, sometimes the syntax or paradigm no longer become fashionable. Sometimes languages and platforms disappear only to re-emerge years later. Back in the late 1990's NeXTSTEP/OPENSTEP was turning into a "legacy platform" ... yet today MacOSX and iOS rely on Objective-C and descendants of the NeXT APIs. Even if a language fades completely from the mainstream its ideas inspire new languages: Java borrowed from Objective-C and C++; Ruby borrowed from Perl, Smalltalk, and a little from Eiffel.
Stay in the industry long enough, you'll see everything come back.
Is this a valid analogy? In short, no. A bit longer answer: NOOOOOOO. For a full explanation, read on.
I can't speak to how construction works, but I know how software development and developers work. Usually software breaks not because of a bad developer, but because of integration issues and subtle interactions which are hard to detect, and even harder to assign "blame" to without a lot of investigation. The investigation is generally the hardest part, so you'll have to charge time already spent.
Worse, your boss is proposing a "blame game" where every defect is somebody's fault, almost always somebody on the current development team. Far from encouraging better software, this will keep developers from entering their own bugs (or any bugs) into the bug tracking system, and encourage finger-pointing rather than collaboration. Meanwhile, your boss thinks he'll save money by making developers work for free "on their own time". In the worst case, the person who touched a piece of code is IT, whether it's a legitimate mistake or a weird edge case. What you'll get is a workplace full of egos, fiefdoms ("don't mess up MY code"), and destructive competition.
[I]Spirit of the Century[/I] technically uses the Open Gaming License, but it has no actual content from the d20 SRD. It just uses the text of the OGL for compatibility with FUDGE (which does the same), and in turn to make the core of the FATE system free for others to build upon.
See http://zork.net/~nick/loyhargil/fate3/fate3.html for the license (and the entire FATE 3/SotC SRD, as it currently exists).
D&D imposes its own assumptions on game worlds.
... they're made for tinkering.
Want a low-magic world centered on non-magical heroes, like most pre-D&D fantasy fiction? Chop out 3/4ths or more of the PHB. Better yet, write your own rules to make fighters cool (*cough*[I]Iron Heroes[/I]*cough*), because all you've got left are Fighters, Rogues, Barbarians, and maybe Rangers and Monks.
Want realistic heroes who don't shrug off dagger thrusts as they gain experience? Find a "grim and gritty" hit point and damage system "patch" on RPGNow, because it's not in the "kernel".
Those are the two big problems I have with D&D. That's why I find myself gravitating to "generic" or rules-light systems
Actually I moved past D&D back in the early 80s.
... not really suited to grim-and-gritty settings, but it's beauty is its simplicity and flexibility.
A few favorite systems:
- RuneQuest, Call of Cthulhu, and Basic Roleplaying: pretty much the same system,
- GURPS: character creation is a right pain, but after that it's smooth sailing. (Also a descendant of Steve Jackson's Melee/Wizard, which first lured me away from D&D.)
- FATE, especially its current incarnation [I]Spirit of the Century[/I]: a fast and light system that actually makes combat fun and interesting without giving other parts of the game short shrift.
- PDQ: a really lightweight game engine, with a more abstract "narrativist" approach to combat
For someone condemning invective, you're pretty harsh on PZ. I perused his website, and didn't find any egregious or unwarranted insults.
Having followed the skeptical movement for a while, though, I have noted that many of them, at some point, stop being polite and just tear into beliefs, or occasionally people. Read James Randi's site (www.jref.org) for some prime examples. I suspect it's because, after seeing the same foolishness repeated over and over again with snazzy new names and charismatic new proponents, their frustration becomes unbearable.
I haven't even read TFA, but I know that gperf isn't for command lines; getopt() (in its various forms) more than adequately does its job.
One real use of gperf and perfect hashes that I know of is in TAO (The ACE ORB), an implementation of CORBA. Since CORBA includes the class and method names as strings, a perfect hash speeds up each lookup of the actual routine to call.
In modern times, I can imagine gperf (or a Java/C#/Ruby/whatever port) speeding up SOAP or other XML-based protocols.
Actually, I think it was an Outer Limits episode (the old series). Could be "Wolf 359", but it's been ages since I've seen the series, and I'm only going by the plot synopsis on Wikipedia.
Frank
The problem I have is with pathnames. On my machine, Java, Ruby, and Emacs are compiled for Windows and use the 'c:\...' convention. Cygwin tools understand only forward slashes, and consider '/' to be 'C:/cygwin/' and 'C:\' to be '/cygdrive/c/'. So all my shell scripts have to convert paths, and I have to run Ruby scripts in CMD.COM because it can't find /cygdrive/c/ruby/ ...
Plus, programs compiled with Cygwin's GCC only work within a Cygwin shell. I've yet to link to mingw successfully, though.
I think this has been posted previously, but there's always this replica of the computers from Brazil: http://www.ahleman.com/Props/ElectriClerk.html
BTW, the creator is also the director of The Call of Cthulhu, an independent film based on Lovecraft's story, which I highly recommend to Lovecraft fans and people who can deal with low-budget effects.
But see also http://onestepback.org/articles/TddMeetsDbc by the same author, who presents a combined DbC/Unit Testing framework for Ruby. (Unfortunately, it relies on Ruby syntax to create a mini-language within Ruby itself.)
Apart from "it's too hard", I think Unit Testing has overtaken DbC as an approach.
/ DbcAndTesting.html and particularly the postscript.
- You can write unit tests in any language, with or without a framework. (I saw a "mini-framework" for C that consisted of three macros and a coding convention.)
- In a test, you can specify assertions before and after each method call. It's a little more tedious to represent classic DbC assertions, but the Abstract Test pattern among others allows you to collect common code.
- You can strip out assertions in production code simply by leaving test code out of the product.
- Unit tests also run scenarios automatically, without an extra "test driver".
The one thing Unit Testing *can't* do is check production code as it's running. On the one hand, that's great at catching conditions you never thought of. On the other hand, customers tend to get annoyed if their app shuts down. I'm sure there's some work on partial in the Eiffel world, but so far I haven't seen any.
See also http://onestepback.org/index.cgi/Tech/Programming
I worked briefly at a shop that used C and C++ for CGI. They were still struggling with memory errors in their in-house string libraries.
But really, Ruby's for more than just Web stuff. (As is Python and the rest.)
I worry more about the already laboring tabletop RPG and CCG markets. How long before they get pushed to the edges of the floor, or segregated into their own smaller room? Two years? One year? Five seconds?
... but World of Warcraft is even better crack than Magic: The Gathering.
ComiCon (in San Diego, Chicago, and everywhere else) have absorbed the media presence, so the original supporters of GenCon might be all right
Companies like RPGNow.com, DriveThruRPG.com, Indie Press Revolution, and even Lulu.com offer everything from OGL/d20 supplements to wholly new and innovative RPGs that someone running a business would never take a risk on. Lowering the barriers and eliminating middlemen does increase the amount of crap ... but then pen-and-paper gamers will rely on online reviews and well-known columnists instead of what Wizards of the Coast, Steve Jackson Games, White Wolf, or some other game company decides to push.
... but even if it's just a few sad geezers who still remember arcane skills like "throwing dice", "using your imagination", and "reading" the RPG as a hobby won't die.
Online distribution sucks for the old-time publishers, and for the game stores which already have to diversify into puzzles, traditional games, and How To Host Your Own Murder