It's very simple. These reviews are done on a volunteer basis. Therefore, the only books reviewed are the ones the reviewer has taken the time and effort to read, and then the time and effort to review.
That tends to be books that are, in my case, excellent. I don't have time to read poor, marginal, or even "okay" books, because I have several (allegedly) excellent books on my shelf waiting to be read.
That said, sometimes I hit a dud. Then I review it as such. I reviewed a game programming book on Slashdot at 5/10 because it was mostly crap.
Hi Bruce. I really enjoyed your novel The Difference Engine. I hadn't realized that the history of computing (notwithstanding math) reached back so far.
Apparently, the Science Museum in London completed a replica of Babbage's Difference Engine on his 200th birthday (URL below). How do you feel about that? Have you seen it? Neat, eh?
I've used Miranda and NIAL (Nested Interactive Array Language). Both are lazy evaluating, functional languages.
I have a background in computer science, and have studied dynamic programming, functional programming, etc.
You should check out C++'s standard valarray templated class. It is designed for optimum performance. Implementations typically use proxy objects for intermediate access and operations. This, in effect, means lazy evaluation. However, it's partly done at compile time, which effectively means performance.
I've seen companies shut down new development for a quarter, while they refactor and rearchitect their code base. Not due to foresight, though, but rather because functionality could no longer be safely added, and sales people could no longer sell the outdated product. When *managers* finally realize refactoring is necessary, the *technical* people really know it is too late.
I am the reviewer. I have trashed books in the past, when deserved. I gave a game programming book 5/10. This book is 9/10, deservedly so. Please don't question my reviewing integrity.
Chapter 13, "Refactoring, Reuse, and Reality", by William Opdyke, covers this.
It's a hard topic, especially since many of the best technical people are not the best politicians. How do we cope?
At one point, Fowler addresses the question of "What if your manager won't let you refactor?" His controversial advice is "Don't tell the manager you're refactoring." His justification is, you are a professional, you know what it takes to do your job, and if refactoring here and there is the right thing to do, just do it. When your development improves because the code improves, your manager won't complain.
It strikes me that your argument is somewhat circular.
Those who really, really want "a better language" are going to stick with something like Haskell, or Eiffel, etc. But the majority of people are going to accept C++'s warts (yes it has a few, I believe all languages do) because of its other advantages.
So, more people use C++. Granted? Not everyone is a good programmer. Probably there are worse programmers using C++ (sheer numbers argument here) than Haskell.
It's not surprising you see bad C++ code. Again, sheer number of users.
You haven't seen my C++ code. Do I sound like the kind of person who would tolerate inelegance? I've used quite a few languages (although admittedly not Haskell, I'll take your word that it's nice). I understand C++ seems inelegant in places, but I believe that's more of a surface impression.
C++ is currently the best, prevalent, language we have for software architecture. Java lacks language features (particularly const, and stack-allocation for user-defined types) and performance. C lacks higher-order features (such as classes). Smalltalk/Lisp/etc. lack performance and static type checking. Eiffel/Haskell/etc. lack prevalence.
As long as C coders use C++, we will be stuck with programmers who don't understand the difference between initialization and assignment. The language can't help that.
I'd really recommend reading Stroustrup's "The Design and Evolution of C++" to understand *why* C++ is the way it is. It is *not* entirely about C... it is about other issues, such as performance, static type checking, etc.
Then Stroustrup's "The C++ Programming Language (Third Edition" to understand the language as it now is. If you can see past the support for casting and operator overloading, you will discover that Stroustrup has as much to say on large scale software design as Booch or Lakos.
There are whole chapters on expressing architecture in C++. Of course, you have to understand the syntax and semantics of the language to achieve that goal. But C++ is about more than obfuscation and C compatibility. Lurking in there is a language that combines the best of Simula, C, and other languages, into a successful language that supports large scale programming.
Don't forget: Stroustrup's background is heading a research centre for large scale programming at ATT. He doesn't just work with toy problems.
The ideas of both patterns and refactoring are acknowledged to be old. The design patterns book specifically states that each pattern had to be used in at least two successful, major projects to be included in the catalogue. Similarly, the refactorings in this book have been tested and tried. The best programmers have been working this way for ages.
What is new, is the codification of these ideas into a more textbook form. This is a step along the way from art to science. You can open a textbook now, and discover the steps of a proven method to get from software point A to B, when to do so, and when not to.
This makes it more akin to engineering. These are proven recipes for engineering software, and now they are codified in books.
Havoc, how did you find the process of writing a book? Can you tell us more about the process? How long did it take? How did you find the time? What were some of the hurdles you had to overcome? Are you as pleased with the final product as you imagined when you began? Would you do it again?
There isn't enough info to go on. What is the game structured like? Libraries? DLLs? What are the major subsystems? What technologies are used? XML? Object I/O? CORBA? Threading? Assembly? What aspects of C++ are used? Templates? RTTI? Operator overloading? Design patterns? Polymorphism? Generic programming? STL? Do they make heavy use of the preprocessor? Is the source commented? What kind of documentation will be presented? Are there UML diagrams for everything? These are all things that a developer ("hacker") needs to know before touching the code. In 48hrs, you can't just be dropped into uncommented, non-standard, C-ish C++ code without UML diagrams and documentation, and be expected to revamp the AI engine. You could be a good C++ programmer and a decent Linux hacker, but still not be able to do anything in the code. Someone else might have mediocre skills but just happen to know Linux threading inside out, and fix threading issues. Luck of the draw? Many, like myself, are already employed and under NDA and employment agreements. I'd have to check, but I'm not sure I can even do work for another computer company, unless I can positively be sure that it is non-competitive. That's hard, because I do data mining and AI, and damn near *anything* is AI. Is game AI non-competitive enough? So if they don't get professional developers, they are left with Linux hackers. They may be great hackers, but can they handle code of commercial size and quality? Remember, Linux is C land. Simple. Established. Old. If this game is modern, advanced C++, that may be beyond the skills of otherwise great Linux hackers. If I have to pay travel, and work for 2 days straight, while they get my services for free, I'm not sure a computer covers that. Still, I wish them the best.
So are Boo Radley and Rashomon
on
Ender's Shadow
·
· Score: 1
You might also want to read The Sound and the Fury by William Faulkner and watch Rashomon by Akira Kurosawa: each tells the same story four times from a different character's point of view. Classics in postmodern writing/film-making.
For C/C++ books, I'm afraid Addison-Wesley kicks O'Reilley's ass every time. That's okay, though... O'Reilley has great books in their catalog, and I'm happy to purchase from either.
So for C/C++, be sure to get "The C Programming Language (Second edition)" and "The C++ Programming Language (Third edition)."
For algorithms, I'd recommend Cormen et al "Introduction to Algorithms". It's *not* an intro, it's a 1000+ page behemoth textbook, very thorough. We used it in university, covering half the material. We also had more specialised texts on numerical methods, etc. Most of these books are available on Dr. Dobb's CDROMs, check their web site.
Also, I have the Knuths and have read some of them. While that's clearly beyond the average programmer, I have to say I find his wit, style, and attention to detail inspiring.
Of course, if you just want to *use* algorithms, you use the C++ standard template library, or whatever. I've heard numerical recipes has some problems and bugs.
A GA is a weak search method, meaning it doesn't use domain knowledge in its search. Constrast this with a strong search method, which uses domain knowledge. This is both an advantage and a disadvantage. The former, because it makes the algorithm reusable. The latter, because it doesn't take specific advantage of what you might know about the problem.
The GA is essentially a randomized beam search. It has a random component, but of course this can be characterized statistically. Beam search means it retains a number of search endpoints and explores them in parallel. That makes it quite parallelizable. Contrast with breadth-first or depth-first search.
The basic steps are simple. Produce a random population of chromosomes (i.e. bit strings). Evaluate their fitness (this part is problem specific). That's generation 0. Select the most fit (using biased roulette wheel selection) to reproduce, which means copying them into the next generation's population.
With some high probability, cross 2 parents at some random point. This is crossover. Also, with some low probability, each bit copied might be copied imperfectly. This is mutation.
Fitness-proportionate selection focusses the search on more promising avenues. Crossover builds new promising avenues by combining building blocks. And mutation retains diversity in the gene pool to prevent premature convergence and to help escape local maxima.
Keep doing this until the population converges on the most fit chromosomes. This step, the termination criterion, also can be customized for each problem. The best-of-run chromosome encodes the solution.
The complicated part is the encoding of the problem in the chromosomes (genotype), its decoding (expression into phenotype), and evaluation of fitness. This is problem specific. The key is that although we have a procedure for fitness evaluation, we *cannot* guess in advance what a particular chromosome's fitness is: we *must* evaluate it.
An example is a human: the only effective way to see how well they will do in life, is to run their life and watch them; you cannot predict. If you could predict, the GA would not be appropriate.
A simple example, discussed in the book, is using a GA to search the space of neural network architectures to solve a problem. Each chromosome encodes a grammar for generating a neural network. For fitness evaluation, the grammar is decoded, a neural network is produced, trained, validated, and its performance on the problem is its fitness.
This is a good example, because it is generally very difficult to predict in advance which architectures (e.g., how many hidden nodes) will be best in a neural network, for a particular problem. It usually requires a lot of domain knowledge, and therefore is hard to do on a larger scale, or in a production setting. The GA takes care of that by effectively searching the space of possible neural network architectures.
You can find lots more info in the book, or on the many GA sites on the web.
A GA is basically a randomized beam search. It retains the N best individuals. It allocates more search power to more promising areas, in a roughly exponential fashion. This allows it to zone in on potential solutions. Yet the randomness keeps it from getting locked in, like a depth first search.
Also, it is optimized for "online" performance, where the cost of the search is considered along with the cost of the resulting solution. (In "offline" performance, you don't care about the cost of the search, only of the solution.)
As jhobson pointed out, Mitchell does cover this in a section or two.
She also briefly discusses Goldberg's work with hybrid GAs, which I recently read in more detail in Golberg's book.
Basically, this is where a GA searches the global space quickly, then another domain-specific routine kicks in to quickly finish searching the local space.
Holland's "From Chaos to Order" is actually "Emergence: From Chaos to Order". I haven't read any of Holland's books yet (though I have all of them I think) but reviews suggest "Hidden Order" is better.
Slashdot Mirror
[DISCLAIMER: I also write Slashdot reviews.]
It's very simple. These reviews are done on a volunteer basis. Therefore, the only books reviewed are the ones the reviewer has taken the time and effort to read, and then the time and effort to review.
That tends to be books that are, in my case, excellent. I don't have time to read poor, marginal, or even "okay" books, because I have several (allegedly) excellent books on my shelf waiting to be read.
That said, sometimes I hit a dud. Then I review it as such. I reviewed a game programming book on Slashdot at 5/10 because it was mostly crap.
--
I'm almost finished reading it as well, loved the reference.
The ESS can be applied beyond genes, though. Wasn't it an economist who introduced it? Doesn't it figure into game theory?
--
Please, include all books you'd recommend, even non-graphical. There's more to games programming (at least, beyond Quake) than graphics.
Programming Pearls? The Art of Computer Programming? The Mythical Man-Month?
What's the complete contents of your bookshelf!!??
Hi Bruce. I really enjoyed your novel The Difference Engine. I hadn't realized that the history of computing (notwithstanding math) reached back so far.
1 862-89.html
Apparently, the Science Museum in London completed a replica of Babbage's Difference Engine on his 200th birthday (URL below). How do you feel about that? Have you seen it? Neat, eh?
http://www.nmsi.ac.uk/on-line/treasure/objects/
They missed the obvious host puns.
Yes, my web page has a comprehensive catalogue of my software development library.
http://www.cgocable.net/~mlepage/library.html
Of course not all are "must haves" but I did buy them all.
Agreed. However, even writing has its books on "elements of style" and "how to write effectively" etc.
I've used Miranda and NIAL (Nested Interactive Array Language). Both are lazy evaluating, functional languages.
I have a background in computer science, and have studied dynamic programming, functional programming, etc.
You should check out C++'s standard valarray templated class. It is designed for optimum performance. Implementations typically use proxy objects for intermediate access and operations. This, in effect, means lazy evaluation. However, it's partly done at compile time, which effectively means performance.
I've seen companies shut down new development for a quarter, while they refactor and rearchitect their code base. Not due to foresight, though, but rather because functionality could no longer be safely added, and sales people could no longer sell the outdated product. When *managers* finally realize refactoring is necessary, the *technical* people really know it is too late.
I am the reviewer. I have trashed books in the past, when deserved. I gave a game programming book 5/10. This book is 9/10, deservedly so. Please don't question my reviewing integrity.
Chapter 13, "Refactoring, Reuse, and Reality", by William Opdyke, covers this.
It's a hard topic, especially since many of the best technical people are not the best politicians. How do we cope?
At one point, Fowler addresses the question of "What if your manager won't let you refactor?" His controversial advice is "Don't tell the manager you're refactoring." His justification is, you are a professional, you know what it takes to do your job, and if refactoring here and there is the right thing to do, just do it. When your development improves because the code improves, your manager won't complain.
It strikes me that your argument is somewhat circular.
Those who really, really want "a better language" are going to stick with something like Haskell, or Eiffel, etc. But the majority of people are going to accept C++'s warts (yes it has a few, I believe all languages do) because of its other advantages.
So, more people use C++. Granted? Not everyone is a good programmer. Probably there are worse programmers using C++ (sheer numbers argument here) than Haskell.
It's not surprising you see bad C++ code. Again, sheer number of users.
You haven't seen my C++ code. Do I sound like the kind of person who would tolerate inelegance? I've used quite a few languages (although admittedly not Haskell, I'll take your word that it's nice). I understand C++ seems inelegant in places, but I believe that's more of a surface impression.
C++ is currently the best, prevalent, language we have for software architecture. Java lacks language features (particularly const, and stack-allocation for user-defined types) and performance. C lacks higher-order features (such as classes). Smalltalk/Lisp/etc. lack performance and static type checking. Eiffel/Haskell/etc. lack prevalence.
As long as C coders use C++, we will be stuck with programmers who don't understand the difference between initialization and assignment. The language can't help that.
I'd really recommend reading Stroustrup's "The Design and Evolution of C++" to understand *why* C++ is the way it is. It is *not* entirely about C... it is about other issues, such as performance, static type checking, etc.
Then Stroustrup's "The C++ Programming Language (Third Edition" to understand the language as it now is. If you can see past the support for casting and operator overloading, you will discover that Stroustrup has as much to say on large scale software design as Booch or Lakos.
There are whole chapters on expressing architecture in C++. Of course, you have to understand the syntax and semantics of the language to achieve that goal. But C++ is about more than obfuscation and C compatibility. Lurking in there is a language that combines the best of Simula, C, and other languages, into a successful language that supports large scale programming.
Don't forget: Stroustrup's background is heading a research centre for large scale programming at ATT. He doesn't just work with toy problems.
The ideas of both patterns and refactoring are acknowledged to be old. The design patterns book specifically states that each pattern had to be used in at least two successful, major projects to be included in the catalogue. Similarly, the refactorings in this book have been tested and tried. The best programmers have been working this way for ages.
What is new, is the codification of these ideas into a more textbook form. This is a step along the way from art to science. You can open a textbook now, and discover the steps of a proven method to get from software point A to B, when to do so, and when not to.
This makes it more akin to engineering. These are proven recipes for engineering software, and now they are codified in books.
Havoc, how did you find the process of writing a book? Can you tell us more about the process? How long did it take? How did you find the time? What were some of the hurdles you had to overcome? Are you as pleased with the final product as you imagined when you began? Would you do it again?
There isn't enough info to go on. What is the game structured like? Libraries? DLLs? What are the major subsystems? What technologies are used? XML? Object I/O? CORBA? Threading? Assembly? What aspects of C++ are used? Templates? RTTI? Operator overloading? Design patterns? Polymorphism? Generic programming? STL? Do they make heavy use of the preprocessor? Is the source commented? What kind of documentation will be presented? Are there UML diagrams for everything? These are all things that a developer ("hacker") needs to know before touching the code. In 48hrs, you can't just be dropped into uncommented, non-standard, C-ish C++ code without UML diagrams and documentation, and be expected to revamp the AI engine. You could be a good C++ programmer and a decent Linux hacker, but still not be able to do anything in the code. Someone else might have mediocre skills but just happen to know Linux threading inside out, and fix threading issues. Luck of the draw? Many, like myself, are already employed and under NDA and employment agreements. I'd have to check, but I'm not sure I can even do work for another computer company, unless I can positively be sure that it is non-competitive. That's hard, because I do data mining and AI, and damn near *anything* is AI. Is game AI non-competitive enough? So if they don't get professional developers, they are left with Linux hackers. They may be great hackers, but can they handle code of commercial size and quality? Remember, Linux is C land. Simple. Established. Old. If this game is modern, advanced C++, that may be beyond the skills of otherwise great Linux hackers. If I have to pay travel, and work for 2 days straight, while they get my services for free, I'm not sure a computer covers that. Still, I wish them the best.
You might also want to read The Sound and the Fury by William Faulkner and watch Rashomon by Akira Kurosawa: each tells the same story four times from a different character's point of view. Classics in postmodern writing/film-making.
For C/C++ books, I'm afraid Addison-Wesley kicks O'Reilley's ass every time. That's okay, though... O'Reilley has great books in their catalog, and I'm happy to purchase from either.
So for C/C++, be sure to get "The C Programming Language (Second edition)" and "The C++ Programming Language (Third edition)."
For algorithms, I'd recommend Cormen et al "Introduction to Algorithms". It's *not* an intro, it's a 1000+ page behemoth textbook, very thorough. We used it in university, covering half the material. We also had more specialised texts on numerical methods, etc. Most of these books are available on Dr. Dobb's CDROMs, check their web site.
Also, I have the Knuths and have read some of them. While that's clearly beyond the average programmer, I have to say I find his wit, style, and attention to detail inspiring.
Of course, if you just want to *use* algorithms, you use the C++ standard template library, or whatever. I've heard numerical recipes has some problems and bugs.
A GA is a weak search method, meaning it doesn't use domain knowledge in its search. Constrast this with a strong search method, which uses domain knowledge. This is both an advantage and a disadvantage. The former, because it makes the algorithm reusable. The latter, because it doesn't take specific advantage of what you might know about the problem.
The GA is essentially a randomized beam search. It has a random component, but of course this can be characterized statistically. Beam search means it retains a number of search endpoints and explores them in parallel. That makes it quite parallelizable. Contrast with breadth-first or depth-first search.
The basic steps are simple. Produce a random population of chromosomes (i.e. bit strings). Evaluate their fitness (this part is problem specific). That's generation 0. Select the most fit (using biased roulette wheel selection) to reproduce, which means copying them into the next generation's population.
With some high probability, cross 2 parents at some random point. This is crossover. Also, with some low probability, each bit copied might be copied imperfectly. This is mutation.
Fitness-proportionate selection focusses the search on more promising avenues. Crossover builds new promising avenues by combining building blocks. And mutation retains diversity in the gene pool to prevent premature convergence and to help escape local maxima.
Keep doing this until the population converges on the most fit chromosomes. This step, the termination criterion, also can be customized for each problem. The best-of-run chromosome encodes the solution.
The complicated part is the encoding of the problem in the chromosomes (genotype), its decoding (expression into phenotype), and evaluation of fitness. This is problem specific. The key is that although we have a procedure for fitness evaluation, we *cannot* guess in advance what a particular chromosome's fitness is: we *must* evaluate it.
An example is a human: the only effective way to see how well they will do in life, is to run their life and watch them; you cannot predict. If you could predict, the GA would not be appropriate.
A simple example, discussed in the book, is using a GA to search the space of neural network architectures to solve a problem. Each chromosome encodes a grammar for generating a neural network. For fitness evaluation, the grammar is decoded, a neural network is produced, trained, validated, and its performance on the problem is its fitness.
This is a good example, because it is generally very difficult to predict in advance which architectures (e.g., how many hidden nodes) will be best in a neural network, for a particular problem. It usually requires a lot of domain knowledge, and therefore is hard to do on a larger scale, or in a production setting. The GA takes care of that by effectively searching the space of possible neural network architectures.
You can find lots more info in the book, or on the many GA sites on the web.
Yes I don't know why Hemos says "the latest book" (although I think it is).
I mention in the review the book dates from 1996.
Thanks.
[files into mental catalog]
You can model niching and speciation in several ways, by restricting mating by phenotypic or genotypic similarity, or by geography.
A GA is basically a randomized beam search. It retains the N best individuals. It allocates more search power to more promising areas, in a roughly exponential fashion. This allows it to zone in on potential solutions. Yet the randomness keeps it from getting locked in, like a depth first search.
Also, it is optimized for "online" performance, where the cost of the search is considered along with the cost of the resulting solution. (In "offline" performance, you don't care about the cost of the search, only of the solution.)
As jhobson pointed out, Mitchell does cover this in a section or two.
She also briefly discusses Goldberg's work with hybrid GAs, which I recently read in more detail in Golberg's book.
Basically, this is where a GA searches the global space quickly, then another domain-specific routine kicks in to quickly finish searching the local space.
Holland's "From Chaos to Order" is actually "Emergence: From Chaos to Order". I haven't read any of Holland's books yet (though I have all of them I think) but reviews suggest "Hidden Order" is better.