Many of the Web design sins described by JN - splash screens, excessive bandwidth requirements, lack of user-centric design - may stem from the fact that while the people who build Web sites have a good grasp of the issues, the people who sign off on them are often marketing types who don't. The senior management who sponsor major Web developments generally learned the ropes in completely different media, and old habits die hard. All too often the sign-off is contingent on meeting glitz-and-glamour quotas.
Cold, hard figures showing the very real dollar losses associated with poor usability is just as important as expounding design rules. Jakob's website provides such figures; I'm not sure whether the book does.
OK, but I don't know that it's fair to blame AMD for this. Some of their early offerings (K5 generation, IIRC) did emphasize good architecture - pipelining, parallel execution etc - at the expense of raw MHz. And they suffered for it, because Joe Public has never heard of pipelining or parallel execution, but knows that 400 is a bigger number than 350.
Result: AMD got the message and refocused their efforts on explicitly trying to pump clock speed as high as possible. I recall an AMD exec openly saying as much some time back. Doesn't seem to have done them any harm, you must admit.
My point is: if the mass market is too dumb to care about anything but clock speed, you can't blame AMD for giving it to them. You might blame Intel, whose advertising seems to be deliberately aiming to sow confusion and ignorance about the technology they sell, but that's another story.
Penrose is NOT a "scientist of excellent pedigree". He's a mathematician. Maybe a brilliant one, I'm not qualified to judge. But no scientist, and a bloody awful philosopher.
"The Emperor's New Mind" was a piece of unmitigated drivel. All handwaving and blustering, just to con the reader into accepting Penrose's religious prejudice against the mere possibility of machine intelligence.
Sorry about the vituperative tone - actually it wasn't the worst book I've ever read, but it was the most intellectually dishonest, and it made me extremely angry.
I've never really understood what people had against Katz, but at this rate I may be converted...
I Am Not A Cryptologist, but would it be so hard to devise a crypto scheme which combined your real data with one or more sets of dummy data plus some random gunk? Then you could hand over a key which retrieves the dummy data, and I don't see how anybody could prove that it wasn't the real stuff.
At the risk of descending into techie wibble, I'd take issue with a couple of the reviewer's comments.
First, Singleton is _not_ just a misguided substitute for globals. It's an answer to the so-called "static initialization order fiasco" - the compiler doesn't guarantee that globals in different obj files are constructed in any particular order, so if the constructor for one such global requires that another one already be initialized, you either take your chances or you adopt an initialize-on-first-use idiom, i.e. Singleton. It isn't necessarily good enough to say "but there aren't any dependencies"; there might be in the future, and this is a sufficiently subtle problem that the designer should be considering it from the start.
Second, I wouldn't agree that "delete this" is primarily bad because it screws up objects on the heap. If you're using it, your class shouldn't allow heap allocation. The main problem is that it invalidates a pointer in the caller's scope without giving the caller any clue that this has happened.
with about four lines of code, you've sub-classed a 150,000 line game engine and added a new feature that will propagate to several hundred classes in that framework.
I did think Tim was overstating the "simplicity" of this, just as I think he was unfairly dissing the C++ template mechanism. You could get something a lot like this "virtual classes" behaviour by specializing a GameEngine template for (among other things) an Actor class of your choice. The STL does this kind of thing with iterator and allocator classes for the various collections.
The other thing he didn't mention is that C++'s template mechanism had performance as a MAJOR design goal. A good implementation of the STL can be every bit as fast as a hand-tuned C algorithm. There's even experimental template work going on which can beat FORTRAN at some number-crunching tasks. I don't see functional languages doing this anytime soon. Sure, the extra flexibility of functional languages is nice, but if you don't need that flexibility _at runtime_, why pay for it at runtime?
I don't honestly think that C++ templates are all that broken. The biggest beef I have is that compiler support for them is so unfriendly - all those 20-line error messages, blech.
Without drifting too far OT... the new graphics engine referred to was just a case of extremely poor ( == lazy/gullible ) journalism. The engine had some interesting aspects, but it was neither new nor impressive nor suitable for general-purpose 3D rendering. I'd also be very interested in what John has to say about next-gen rendering technologies, particularly since he's active in pushing the OpenGL standard, but couching the question in these terms is inviting a sarcastic reply at best.
At least, not always.
Many of the Web design sins described by JN - splash screens, excessive bandwidth requirements, lack of user-centric design - may stem from the fact that while the people who build Web sites have a good grasp of the issues, the people who sign off on them are often marketing types who don't. The senior management who sponsor major Web developments generally learned the ropes in completely different media, and old habits die hard. All too often the sign-off is contingent on meeting glitz-and-glamour quotas.
Cold, hard figures showing the very real dollar losses associated with poor usability is just as important as expounding design rules. Jakob's website provides such figures; I'm not sure whether the book does.
OK, but I don't know that it's fair to blame AMD for this. Some of their early offerings (K5 generation, IIRC) did emphasize good architecture - pipelining, parallel execution etc - at the expense of raw MHz. And they suffered for it, because Joe Public has never heard of pipelining or parallel execution, but knows that 400 is a bigger number than 350.
Result: AMD got the message and refocused their efforts on explicitly trying to pump clock speed as high as possible. I recall an AMD exec openly saying as much some time back. Doesn't seem to have done them any harm, you must admit.
My point is: if the mass market is too dumb to care about anything but clock speed, you can't blame AMD for giving it to them. You might blame Intel, whose advertising seems to be deliberately aiming to sow confusion and ignorance about the technology they sell, but that's another story.
Both are scientists of excellent pedigree
Penrose is NOT a "scientist of excellent pedigree". He's a mathematician. Maybe a brilliant one, I'm not qualified to judge. But no scientist, and a bloody awful philosopher.
"The Emperor's New Mind" was a piece of unmitigated drivel. All handwaving and blustering, just to con the reader into accepting Penrose's religious prejudice against the mere possibility of machine intelligence.
Sorry about the vituperative tone - actually it wasn't the worst book I've ever read, but it was the most intellectually dishonest, and it made me extremely angry.
I've never really understood what people had against Katz, but at this rate I may be converted...
Shutting up now, sir...
I Am Not A Cryptologist, but would it be so hard to devise a crypto scheme which combined your real data with one or more sets of dummy data plus some random gunk? Then you could hand over a key which retrieves the dummy data, and I don't see how anybody could prove that it wasn't the real stuff.
<sigh> - true love...
At the risk of descending into techie wibble, I'd take issue with a couple of the reviewer's comments.
First, Singleton is _not_ just a misguided substitute for globals. It's an answer to the so-called "static initialization order fiasco" - the compiler doesn't guarantee that globals in different obj files are constructed in any particular order, so if the constructor for one such global requires that another one already be initialized, you either take your chances or you adopt an initialize-on-first-use idiom, i.e. Singleton. It isn't necessarily good enough to say "but there aren't any dependencies"; there might be in the future, and this is a sufficiently subtle problem that the designer should be considering it from the start.
Second, I wouldn't agree that "delete this" is primarily bad because it screws up objects on the heap. If you're using it, your class shouldn't allow heap allocation. The main problem is that it invalidates a pointer in the caller's scope without giving the caller any clue that this has happened.
Rant over. It is a good book; take a look.
I did think Tim was overstating the "simplicity" of this, just as I think he was unfairly dissing the C++ template mechanism. You could get something a lot like this "virtual classes" behaviour by specializing a GameEngine template for (among other things) an Actor class of your choice. The STL does this kind of thing with iterator and allocator classes for the various collections.
The other thing he didn't mention is that C++'s template mechanism had performance as a MAJOR design goal. A good implementation of the STL can be every bit as fast as a hand-tuned C algorithm. There's even experimental template work going on which can beat FORTRAN at some number-crunching tasks. I don't see functional languages doing this anytime soon. Sure, the extra flexibility of functional languages is nice, but if you don't need that flexibility _at runtime_, why pay for it at runtime?
I don't honestly think that C++ templates are all that broken. The biggest beef I have is that compiler support for them is so unfriendly - all those 20-line error messages, blech.
Without drifting too far OT... the new graphics engine referred to was just a case of extremely poor ( == lazy/gullible ) journalism. The engine had some interesting aspects, but it was neither new nor impressive nor suitable for general-purpose 3D rendering. I'd also be very interested in what John has to say about next-gen rendering technologies, particularly since he's active in pushing the OpenGL standard, but couching the question in these terms is inviting a sarcastic reply at best.