Wow, I guess some folks aren't playing UT2003 tonight after all!
Depending on which box you're planning on, you may want to wait for a graphics hardware rev from Apple. The new ATI 9700 isn't yet available for Mac, but will probably be coming out soon. Given the performance step these cards offer over the current generation, you may want to hold off (either to buy the new card, or buy the discounted older model.) NVidia will also be shipping a next-generation card (Nv30) sometime Q4/Q1.
OS X is great - especially coming from the dark ages of old Mac OS. My wife has an iMac, and a friend of mine has an iBook - both are pretty nice systems.
My only gripe with Apple is that Mac's CPU and chipset is still behind the times. I've heard rumours of OS X running on Intel hardware - now, wouldn't that be a kick in the head?
Perhaps our evolutionary successors have beat us to it: gas-hoggin' worms?
Playing armchair scientist for a moment (and damning the worms to worm-juice) - mine that baby! Aside from the immediate, relatively clean energy supply, the experience of undersea methane hydrate mining would be good to have for future space-based mining.
Re:Preserve the genre? Is my old copy of Chainmail
on
Layoffs at WotC
·
· Score: 2, Insightful
More like a puff of litigation, once the Lawyer/Paladins (multiclass) get the scent of toner!
"Elbereth Habeas Corpus!", cried the Armani-clad knight as he swung his +3 Firebrand (tm, registered, patent pending, copyright) down upon the arms of the bespectacled Mage, which at that moment were holding an open Holy Tome over one of the Demonic alters - a shaft of light and a macabre hum emanating from it's heart. A single word, "Xerox", emblazoned on the front...
There's a lot of insinuation about WoTC executive greed/money-grubbing going on - which may be the case, but it is also a very hard time for any business to stay afloat. Still, with the relative success of the d20 system, I expected WoTC to be in the black for some time (although I've heard it said that they only make money on the sales of Player's Handbooks - don't quite follow why.)
Monte Cook's rant has some fine points, but no specific names or facts about WoTC. It does seem that somebody has decided to squeeze the venerable D&D turnip, or perhaps killing the goose is a better analogy - ok, they're doing something they shouldn't be with farmyard items - let's leave it at that.
Over the past 20 years (where are them wooden teeth, dad-gum-it!) I've had the pleasure of playing the following gaming systems:
AD&D 1st and 2nd Edition (missed out on Chainmail!)
Gamma World
Traveler
Top Secret
Paranoia
Gangsters
Chill
Arms Law/Claw Law/Spell Law
Empire of the Petal Throne
GURPS
AD&D 3rd Edition
Some others, but my Alzheimer's is acting up again...
Some of these games/rule systems were remarkably complete (sometime to a fault) - others were extremely simple. Still, the success of a given game never depended on just the rule system - it required a creative, fair, and well-paced DM (or what have you) to make it all work.
So, what's my point? (Hey, this is/., do I need one?) Forget the gaming system. Get a good group of creative people together, crank out your own house-brew, and battle on.
I suspect our disagreement is due, at least in part, to differences in the definition of "documentation". I'm primarily refering to API documentation - which is most certainly NOT "write once and forget"! You said yourself that "I'm constently extending and improving the api of my personal libraries as I learn more or need more out of the api."
This is best accomplished by writing and editing documentation for all public methods, and class/library level documentation, including variables, overloads, side effects, etc. at the time of implementation whether or not this is a new class, or just a bugfix. The longer you wait, the more you forget. If that doesn't happen to you, congratulations - wish I had your memory. Still, you'll be the one individually training in every new coder for the next N years.
I also have found that writing API documentation during implementation often causes me to consider aspects of the problem that hadn't surfaced before, because it forces me to think (not in code) about how a client will be using the code. Once high-level design is done, my strategy is:
Write unit test
Write class/lib API documentation
Write implementation
Lather, rinse, repeat
It's certainly true that some organizations use outdated, overzealous, and under-tooled documentation procedures as a crutch for process and auditing purposes. If your documentation isn't electronic, doesn't refer directly to active source code, and isn't stored isn't the same source code control system, chances are good that it will get left behind during implementation. This doesn't seem so important in the "fog of implementation", but is ultimately a major loss, and can drastically shorten the life-cycle of software.
Environments like this cause documentation to get a bad rap, and cause engineers resort to drastic measures to fob off "documentation" work to new hires, interns, or frustrated bosses. Understandable, because it isn't adding much value if it's so divorced from the development cycle.
Some code is self-explanatory, but the vast majority is not. While I personally feel that Literate Programming goes too far afield, programmers should document the interfaces (minimally) to their code to the best of their abilities, and be responsible for the state of the documentation. To my mind, this is no different than expecting architects to place measurements on their blueprints. You can argue that it's unnecessary, because the information is already there in the scale drawing - but it's more efficient and reliable to use multiple representations (text and geometry) to communicate the information.
Don't bother keeping code documentation up to date because somebody may write code assuming the documentation is up to date? I'm getting dizzy...
I'm surprised that anyone would attempt to argue the merits of using any computer language as the appropriate mechanism for communicating the intent of an algorithm/function/method. The code is for the machine, not for humans! It's more precise, but only because it's so much more constrained. If you want to quickly port it, or have any hopes of releasing your work as an API for somebody else to code to (or test against), you've simply got to have good documentation.
In your scenario, the problem was not simply that the documentation was out of date. If you're operating in a shop where a change can be made in a core component without triggering regression testing, or core components can have their functionality change without revving the API, you need to fix your process.
It is bad to have out of date documentation, but this typically occurs because it's too far away from implementation. Making documentation coincident with implementation, either by convention (embedding comments), or by language design (Literate Programming languages) is an improvment.
In general, I prefer less high-level documentation and more at the class and library level. I know I'd much rather have a well documented class header and methods (with code fragment examples) and a good unit test than having to dive into an implementation and reverse engineer somebody else's code.
For that matter, for C++ I prefer incorporating documentation into the code itself, and use packages like Doxygen or Cocoon to extract it (there are many more, I'm sure).
BTW, now in danger of getting on topic, Leo does look pretty interesting... esp. for web work.
Slashdot Mirror
Depending on which box you're planning on, you may want to wait for a graphics hardware rev from Apple. The new ATI 9700 isn't yet available for Mac, but will probably be coming out soon. Given the performance step these cards offer over the current generation, you may want to hold off (either to buy the new card, or buy the discounted older model.) NVidia will also be shipping a next-generation card (Nv30) sometime Q4/Q1.
OS X is great - especially coming from the dark ages of old Mac OS. My wife has an iMac, and a friend of mine has an iBook - both are pretty nice systems.
My only gripe with Apple is that Mac's CPU and chipset is still behind the times. I've heard rumours of OS X running on Intel hardware - now, wouldn't that be a kick in the head?
Playing armchair scientist for a moment (and damning the worms to worm-juice) - mine that baby! Aside from the immediate, relatively clean energy supply, the experience of undersea methane hydrate mining would be good to have for future space-based mining.
"Elbereth Habeas Corpus!", cried the Armani-clad knight as he swung his +3 Firebrand (tm, registered, patent pending, copyright) down upon the arms of the bespectacled Mage, which at that moment were holding an open Holy Tome over one of the Demonic alters - a shaft of light and a macabre hum emanating from it's heart. A single word, "Xerox", emblazoned on the front...
There's a lot of insinuation about WoTC executive greed/money-grubbing going on - which may be the case, but it is also a very hard time for any business to stay afloat. Still, with the relative success of the d20 system, I expected WoTC to be in the black for some time (although I've heard it said that they only make money on the sales of Player's Handbooks - don't quite follow why.)
Monte Cook's rant has some fine points, but no specific names or facts about WoTC. It does seem that somebody has decided to squeeze the venerable D&D turnip, or perhaps killing the goose is a better analogy - ok, they're doing something they shouldn't be with farmyard items - let's leave it at that. Over the past 20 years (where are them wooden teeth, dad-gum-it!) I've had the pleasure of playing the following gaming systems:
- AD&D 1st and 2nd Edition (missed out on Chainmail!)
- Gamma World
- Traveler
- Top Secret
- Paranoia
- Gangsters
- Chill
- Arms Law/Claw Law/Spell Law
- Empire of the Petal Throne
- GURPS
- AD&D 3rd Edition
- Some others, but my Alzheimer's is acting up again...
Some of these games/rule systems were remarkably complete (sometime to a fault) - others were extremely simple. Still, the success of a given game never depended on just the rule system - it required a creative, fair, and well-paced DM (or what have you) to make it all work.So, what's my point? (Hey, this is /., do I need one?) Forget the gaming system. Get a good group of creative people together, crank out your own house-brew, and battle on.
If you see an Orc in the road, kill it.
This is best accomplished by writing and editing documentation for all public methods, and class/library level documentation, including variables, overloads, side effects, etc. at the time of implementation whether or not this is a new class, or just a bugfix. The longer you wait, the more you forget. If that doesn't happen to you, congratulations - wish I had your memory. Still, you'll be the one individually training in every new coder for the next N years.
I also have found that writing API documentation during implementation often causes me to consider aspects of the problem that hadn't surfaced before, because it forces me to think (not in code) about how a client will be using the code. Once high-level design is done, my strategy is:
It's certainly true that some organizations use outdated, overzealous, and under-tooled documentation procedures as a crutch for process and auditing purposes. If your documentation isn't electronic, doesn't refer directly to active source code, and isn't stored isn't the same source code control system, chances are good that it will get left behind during implementation. This doesn't seem so important in the "fog of implementation", but is ultimately a major loss, and can drastically shorten the life-cycle of software.
Environments like this cause documentation to get a bad rap, and cause engineers resort to drastic measures to fob off "documentation" work to new hires, interns, or frustrated bosses. Understandable, because it isn't adding much value if it's so divorced from the development cycle.
Some code is self-explanatory, but the vast majority is not. While I personally feel that Literate Programming goes too far afield, programmers should document the interfaces (minimally) to their code to the best of their abilities, and be responsible for the state of the documentation. To my mind, this is no different than expecting architects to place measurements on their blueprints. You can argue that it's unnecessary, because the information is already there in the scale drawing - but it's more efficient and reliable to use multiple representations (text and geometry) to communicate the information.
I'm surprised that anyone would attempt to argue the merits of using any computer language as the appropriate mechanism for communicating the intent of an algorithm/function/method. The code is for the machine, not for humans! It's more precise, but only because it's so much more constrained. If you want to quickly port it, or have any hopes of releasing your work as an API for somebody else to code to (or test against), you've simply got to have good documentation.
In your scenario, the problem was not simply that the documentation was out of date. If you're operating in a shop where a change can be made in a core component without triggering regression testing, or core components can have their functionality change without revving the API, you need to fix your process.
It is bad to have out of date documentation, but this typically occurs because it's too far away from implementation. Making documentation coincident with implementation, either by convention (embedding comments), or by language design (Literate Programming languages) is an improvment.
In general, I prefer less high-level documentation and more at the class and library level. I know I'd much rather have a well documented class header and methods (with code fragment examples) and a good unit test than having to dive into an implementation and reverse engineer somebody else's code.
For that matter, for C++ I prefer incorporating documentation into the code itself, and use packages like Doxygen or Cocoon to extract it (there are many more, I'm sure).
BTW, now in danger of getting on topic, Leo does look pretty interesting... esp. for web work.