Slashdot Mirror

Torulf would like to start an ongoing discussion on books that anyone in the IT field would benefit in having in their library: "Here's a topic that might generate some interesting discussions. I'm a student trying to get general knowledge of the IT business. The question here is about what is regarded 'basic knowledge' and where to find it. As we all know (I hope), a lot of knowledge can really only be learned through experience. In many cases, however, a read through the theory will save you a lot of time. As books are also easier to look up than experience, below is a suggestion of a reading list that might give a decent general knowledge in the field. Please fill out the gaps with what you think is required knowledge for anyone working in the industry. Mostly this is about a general overview of the different areas of the IT industry, but if you have suggestions of good material for becoming an expert in some particular field, by all means, share your knowledge." Torulf has compiled a fairly long list of books, below, however your own suggestions are always welcome.

"To start off the discussion, here are a few suggestions as to likely candidates. The books are linked to Amazon since they can provide a fairly quick and complete description of the books online.

Programming:
Learning a few languages certainly won't hurt. Here are some suggestions:

• The C programming language
• The C++ programming language
• Programming Perl
• Programming Python
• A Book about Java
• A Book on SQL
• A Book about Functional languages (LISP, ML, etc.)

Design:
For any non-trivial task, it is suggested that you design before you code.

• Design Patterns
• UML Distilled

User Interfaces:
A lot of programmers are more than clueless in this area. These at least won't hurt:

• Designing Visual Interfaces
• Usability Engineering
• POET

Graphics:
Some general knowledge about graphics.

• Real-Time Rendering
• Computer Graphics

Business/Management:
Here's something about management and financing. I don't really know about a good reference for marketing applied to the IT industry. This is the area where the average geek is even more ignorant than concerning UI.

• High Tech Start Up
• The Mythical Man Month
• Code Complete

Security:
Alright, this list should be a lot longer.

• Security Engineering

Misc.
And last some stuff that didn't fit in any of the categories above.

• Modern Operating Systems
• Computer Networks
• A few operating systems
• A book about markup languages, ie HTML, XML, DHTML, etc
• A book about Algorithms and Data Structures in general
• At least some basic knowledge about Hardware
• Wireless systems seem to be growing. It might pay off to learn something about Symbian, J2ME etc."

Now that's a start to a comprehensive IT Library if I've ever seen one. How do you all feel about this list (if not the specific selections, then at least the material being covered)? If you were to make changes or additions, what would they be?

Torulf would like to start an ongoing discussion on books that anyone in the IT field would benefit in having in their library: "Here's a topic that might generate some interesting discussions. I'm a student trying to get general knowledge of the IT business. The question here is about what is regarded 'basic knowledge' and where to find it. As we all know (I hope), a lot of knowledge can really only be learned through experience. In many cases, however, a read through the theory will save you a lot of time. As books are also easier to look up than experience, below is a suggestion of a reading list that might give a decent general knowledge in the field. Please fill out the gaps with what you think is required knowledge for anyone working in the industry. Mostly this is about a general overview of the different areas of the IT industry, but if you have suggestions of good material for becoming an expert in some particular field, by all means, share your knowledge." Torulf has compiled a fairly long list of books, below, however your own suggestions are always welcome.

"To start off the discussion, here are a few suggestions as to likely candidates. The books are linked to Amazon since they can provide a fairly quick and complete description of the books online.

Programming:
Learning a few languages certainly won't hurt. Here are some suggestions:

• The C programming language
• The C++ programming language
• Programming Perl
• Programming Python
• A Book about Java
• A Book on SQL
• A Book about Functional languages (LISP, ML, etc.)

Design:
For any non-trivial task, it is suggested that you design before you code.

• Design Patterns
• UML Distilled

User Interfaces:
A lot of programmers are more than clueless in this area. These at least won't hurt:

• Designing Visual Interfaces
• Usability Engineering
• POET

Graphics:
Some general knowledge about graphics.

• Real-Time Rendering
• Computer Graphics

Business/Management:
Here's something about management and financing. I don't really know about a good reference for marketing applied to the IT industry. This is the area where the average geek is even more ignorant than concerning UI.

• High Tech Start Up
• The Mythical Man Month
• Code Complete

Security:
Alright, this list should be a lot longer.

• Security Engineering

Misc.
And last some stuff that didn't fit in any of the categories above.

• Modern Operating Systems
• Computer Networks
• A few operating systems
• A book about markup languages, ie HTML, XML, DHTML, etc
• A book about Algorithms and Data Structures in general
• At least some basic knowledge about Hardware
• Wireless systems seem to be growing. It might pay off to learn something about Symbian, J2ME etc."

Now that's a start to a comprehensive IT Library if I've ever seen one. How do you all feel about this list (if not the specific selections, then at least the material being covered)? If you were to make changes or additions, what would they be?

Torulf would like to start an ongoing discussion on books that anyone in the IT field would benefit in having in their library: "Here's a topic that might generate some interesting discussions. I'm a student trying to get general knowledge of the IT business. The question here is about what is regarded 'basic knowledge' and where to find it. As we all know (I hope), a lot of knowledge can really only be learned through experience. In many cases, however, a read through the theory will save you a lot of time. As books are also easier to look up than experience, below is a suggestion of a reading list that might give a decent general knowledge in the field. Please fill out the gaps with what you think is required knowledge for anyone working in the industry. Mostly this is about a general overview of the different areas of the IT industry, but if you have suggestions of good material for becoming an expert in some particular field, by all means, share your knowledge." Torulf has compiled a fairly long list of books, below, however your own suggestions are always welcome.

"To start off the discussion, here are a few suggestions as to likely candidates. The books are linked to Amazon since they can provide a fairly quick and complete description of the books online.

Programming:
Learning a few languages certainly won't hurt. Here are some suggestions:

• The C programming language
• The C++ programming language
• Programming Perl
• Programming Python
• A Book about Java
• A Book on SQL
• A Book about Functional languages (LISP, ML, etc.)

Design:
For any non-trivial task, it is suggested that you design before you code.

• Design Patterns
• UML Distilled

User Interfaces:
A lot of programmers are more than clueless in this area. These at least won't hurt:

• Designing Visual Interfaces
• Usability Engineering
• POET

Graphics:
Some general knowledge about graphics.

• Real-Time Rendering
• Computer Graphics

Business/Management:
Here's something about management and financing. I don't really know about a good reference for marketing applied to the IT industry. This is the area where the average geek is even more ignorant than concerning UI.

• High Tech Start Up
• The Mythical Man Month
• Code Complete

Security:
Alright, this list should be a lot longer.

• Security Engineering

Misc.
And last some stuff that didn't fit in any of the categories above.

• Modern Operating Systems
• Computer Networks
• A few operating systems
• A book about markup languages, ie HTML, XML, DHTML, etc
• A book about Algorithms and Data Structures in general
• At least some basic knowledge about Hardware
• Wireless systems seem to be growing. It might pay off to learn something about Symbian, J2ME etc."

Now that's a start to a comprehensive IT Library if I've ever seen one. How do you all feel about this list (if not the specific selections, then at least the material being covered)? If you were to make changes or additions, what would they be?

Torulf would like to start an ongoing discussion on books that anyone in the IT field would benefit in having in their library: "Here's a topic that might generate some interesting discussions. I'm a student trying to get general knowledge of the IT business. The question here is about what is regarded 'basic knowledge' and where to find it. As we all know (I hope), a lot of knowledge can really only be learned through experience. In many cases, however, a read through the theory will save you a lot of time. As books are also easier to look up than experience, below is a suggestion of a reading list that might give a decent general knowledge in the field. Please fill out the gaps with what you think is required knowledge for anyone working in the industry. Mostly this is about a general overview of the different areas of the IT industry, but if you have suggestions of good material for becoming an expert in some particular field, by all means, share your knowledge." Torulf has compiled a fairly long list of books, below, however your own suggestions are always welcome.

"To start off the discussion, here are a few suggestions as to likely candidates. The books are linked to Amazon since they can provide a fairly quick and complete description of the books online.

Programming:
Learning a few languages certainly won't hurt. Here are some suggestions:

• The C programming language
• The C++ programming language
• Programming Perl
• Programming Python
• A Book about Java
• A Book on SQL
• A Book about Functional languages (LISP, ML, etc.)

Design:
For any non-trivial task, it is suggested that you design before you code.

• Design Patterns
• UML Distilled

User Interfaces:
A lot of programmers are more than clueless in this area. These at least won't hurt:

• Designing Visual Interfaces
• Usability Engineering
• POET

Graphics:
Some general knowledge about graphics.

• Real-Time Rendering
• Computer Graphics

Business/Management:
Here's something about management and financing. I don't really know about a good reference for marketing applied to the IT industry. This is the area where the average geek is even more ignorant than concerning UI.

• High Tech Start Up
• The Mythical Man Month
• Code Complete

Security:
Alright, this list should be a lot longer.

• Security Engineering

Misc.
And last some stuff that didn't fit in any of the categories above.

• Modern Operating Systems
• Computer Networks
• A few operating systems
• A book about markup languages, ie HTML, XML, DHTML, etc
• A book about Algorithms and Data Structures in general
• At least some basic knowledge about Hardware
• Wireless systems seem to be growing. It might pay off to learn something about Symbian, J2ME etc."

Now that's a start to a comprehensive IT Library if I've ever seen one. How do you all feel about this list (if not the specific selections, then at least the material being covered)? If you were to make changes or additions, what would they be?

Torulf would like to start an ongoing discussion on books that anyone in the IT field would benefit in having in their library: "Here's a topic that might generate some interesting discussions. I'm a student trying to get general knowledge of the IT business. The question here is about what is regarded 'basic knowledge' and where to find it. As we all know (I hope), a lot of knowledge can really only be learned through experience. In many cases, however, a read through the theory will save you a lot of time. As books are also easier to look up than experience, below is a suggestion of a reading list that might give a decent general knowledge in the field. Please fill out the gaps with what you think is required knowledge for anyone working in the industry. Mostly this is about a general overview of the different areas of the IT industry, but if you have suggestions of good material for becoming an expert in some particular field, by all means, share your knowledge." Torulf has compiled a fairly long list of books, below, however your own suggestions are always welcome.

"To start off the discussion, here are a few suggestions as to likely candidates. The books are linked to Amazon since they can provide a fairly quick and complete description of the books online.

Programming:
Learning a few languages certainly won't hurt. Here are some suggestions:

• The C programming language
• The C++ programming language
• Programming Perl
• Programming Python
• A Book about Java
• A Book on SQL
• A Book about Functional languages (LISP, ML, etc.)

Design:
For any non-trivial task, it is suggested that you design before you code.

• Design Patterns
• UML Distilled

User Interfaces:
A lot of programmers are more than clueless in this area. These at least won't hurt:

• Designing Visual Interfaces
• Usability Engineering
• POET

Graphics:
Some general knowledge about graphics.

• Real-Time Rendering
• Computer Graphics

Business/Management:
Here's something about management and financing. I don't really know about a good reference for marketing applied to the IT industry. This is the area where the average geek is even more ignorant than concerning UI.

• High Tech Start Up
• The Mythical Man Month
• Code Complete

Security:
Alright, this list should be a lot longer.

• Security Engineering

Misc.
And last some stuff that didn't fit in any of the categories above.

• Modern Operating Systems
• Computer Networks
• A few operating systems
• A book about markup languages, ie HTML, XML, DHTML, etc
• A book about Algorithms and Data Structures in general
• At least some basic knowledge about Hardware
• Wireless systems seem to be growing. It might pay off to learn something about Symbian, J2ME etc."

Now that's a start to a comprehensive IT Library if I've ever seen one. How do you all feel about this list (if not the specific selections, then at least the material being covered)? If you were to make changes or additions, what would they be?

Torulf would like to start an ongoing discussion on books that anyone in the IT field would benefit in having in their library: "Here's a topic that might generate some interesting discussions. I'm a student trying to get general knowledge of the IT business. The question here is about what is regarded 'basic knowledge' and where to find it. As we all know (I hope), a lot of knowledge can really only be learned through experience. In many cases, however, a read through the theory will save you a lot of time. As books are also easier to look up than experience, below is a suggestion of a reading list that might give a decent general knowledge in the field. Please fill out the gaps with what you think is required knowledge for anyone working in the industry. Mostly this is about a general overview of the different areas of the IT industry, but if you have suggestions of good material for becoming an expert in some particular field, by all means, share your knowledge." Torulf has compiled a fairly long list of books, below, however your own suggestions are always welcome.

"To start off the discussion, here are a few suggestions as to likely candidates. The books are linked to Amazon since they can provide a fairly quick and complete description of the books online.

Programming:
Learning a few languages certainly won't hurt. Here are some suggestions:

• The C programming language
• The C++ programming language
• Programming Perl
• Programming Python
• A Book about Java
• A Book on SQL
• A Book about Functional languages (LISP, ML, etc.)

Design:
For any non-trivial task, it is suggested that you design before you code.

• Design Patterns
• UML Distilled

User Interfaces:
A lot of programmers are more than clueless in this area. These at least won't hurt:

• Designing Visual Interfaces
• Usability Engineering
• POET

Graphics:
Some general knowledge about graphics.

• Real-Time Rendering
• Computer Graphics

Business/Management:
Here's something about management and financing. I don't really know about a good reference for marketing applied to the IT industry. This is the area where the average geek is even more ignorant than concerning UI.

• High Tech Start Up
• The Mythical Man Month
• Code Complete

Security:
Alright, this list should be a lot longer.

• Security Engineering

Misc.
And last some stuff that didn't fit in any of the categories above.

• Modern Operating Systems
• Computer Networks
• A few operating systems
• A book about markup languages, ie HTML, XML, DHTML, etc
• A book about Algorithms and Data Structures in general
• At least some basic knowledge about Hardware
• Wireless systems seem to be growing. It might pay off to learn something about Symbian, J2ME etc."

Now that's a start to a comprehensive IT Library if I've ever seen one. How do you all feel about this list (if not the specific selections, then at least the material being covered)? If you were to make changes or additions, what would they be?

Torulf would like to start an ongoing discussion on books that anyone in the IT field would benefit in having in their library: "Here's a topic that might generate some interesting discussions. I'm a student trying to get general knowledge of the IT business. The question here is about what is regarded 'basic knowledge' and where to find it. As we all know (I hope), a lot of knowledge can really only be learned through experience. In many cases, however, a read through the theory will save you a lot of time. As books are also easier to look up than experience, below is a suggestion of a reading list that might give a decent general knowledge in the field. Please fill out the gaps with what you think is required knowledge for anyone working in the industry. Mostly this is about a general overview of the different areas of the IT industry, but if you have suggestions of good material for becoming an expert in some particular field, by all means, share your knowledge." Torulf has compiled a fairly long list of books, below, however your own suggestions are always welcome.

"To start off the discussion, here are a few suggestions as to likely candidates. The books are linked to Amazon since they can provide a fairly quick and complete description of the books online.

Programming:
Learning a few languages certainly won't hurt. Here are some suggestions:

• The C programming language
• The C++ programming language
• Programming Perl
• Programming Python
• A Book about Java
• A Book on SQL
• A Book about Functional languages (LISP, ML, etc.)

Design:
For any non-trivial task, it is suggested that you design before you code.

• Design Patterns
• UML Distilled

User Interfaces:
A lot of programmers are more than clueless in this area. These at least won't hurt:

• Designing Visual Interfaces
• Usability Engineering
• POET

Graphics:
Some general knowledge about graphics.

• Real-Time Rendering
• Computer Graphics

Business/Management:
Here's something about management and financing. I don't really know about a good reference for marketing applied to the IT industry. This is the area where the average geek is even more ignorant than concerning UI.

• High Tech Start Up
• The Mythical Man Month
• Code Complete

Security:
Alright, this list should be a lot longer.

• Security Engineering

Misc.
And last some stuff that didn't fit in any of the categories above.

• Modern Operating Systems
• Computer Networks
• A few operating systems
• A book about markup languages, ie HTML, XML, DHTML, etc
• A book about Algorithms and Data Structures in general
• At least some basic knowledge about Hardware
• Wireless systems seem to be growing. It might pay off to learn something about Symbian, J2ME etc."

Now that's a start to a comprehensive IT Library if I've ever seen one. How do you all feel about this list (if not the specific selections, then at least the material being covered)? If you were to make changes or additions, what would they be?

Torulf would like to start an ongoing discussion on books that anyone in the IT field would benefit in having in their library: "Here's a topic that might generate some interesting discussions. I'm a student trying to get general knowledge of the IT business. The question here is about what is regarded 'basic knowledge' and where to find it. As we all know (I hope), a lot of knowledge can really only be learned through experience. In many cases, however, a read through the theory will save you a lot of time. As books are also easier to look up than experience, below is a suggestion of a reading list that might give a decent general knowledge in the field. Please fill out the gaps with what you think is required knowledge for anyone working in the industry. Mostly this is about a general overview of the different areas of the IT industry, but if you have suggestions of good material for becoming an expert in some particular field, by all means, share your knowledge." Torulf has compiled a fairly long list of books, below, however your own suggestions are always welcome.

"To start off the discussion, here are a few suggestions as to likely candidates. The books are linked to Amazon since they can provide a fairly quick and complete description of the books online.

Programming:
Learning a few languages certainly won't hurt. Here are some suggestions:

• The C programming language
• The C++ programming language
• Programming Perl
• Programming Python
• A Book about Java
• A Book on SQL
• A Book about Functional languages (LISP, ML, etc.)

Design:
For any non-trivial task, it is suggested that you design before you code.

• Design Patterns
• UML Distilled

User Interfaces:
A lot of programmers are more than clueless in this area. These at least won't hurt:

• Designing Visual Interfaces
• Usability Engineering
• POET

Graphics:
Some general knowledge about graphics.

• Real-Time Rendering
• Computer Graphics

Business/Management:
Here's something about management and financing. I don't really know about a good reference for marketing applied to the IT industry. This is the area where the average geek is even more ignorant than concerning UI.

• High Tech Start Up
• The Mythical Man Month
• Code Complete

Security:
Alright, this list should be a lot longer.

• Security Engineering

Misc.
And last some stuff that didn't fit in any of the categories above.

• Modern Operating Systems
• Computer Networks
• A few operating systems
• A book about markup languages, ie HTML, XML, DHTML, etc
• A book about Algorithms and Data Structures in general
• At least some basic knowledge about Hardware
• Wireless systems seem to be growing. It might pay off to learn something about Symbian, J2ME etc."

Now that's a start to a comprehensive IT Library if I've ever seen one. How do you all feel about this list (if not the specific selections, then at least the material being covered)? If you were to make changes or additions, what would they be?

scubacuda writes "Here is an interesting tale about a Boy Scout who went a little too far in trying to achieve a merit badge in Atomic Energy. From smoke alarms, lantern components, the paint from radio clocks, and a little help from the Nuclear Regulator Commission, David Hahn attempted to build a nuclear reactor in his mother's shed. Regarding his excessive radioactive exposure, Hahn says, "I don't believe I took more than five years off my life."" While this is an oldish story (1998) it is not the pathetic self congratulatory lame princeton story.

Peter Wayner writes: "In a world where Ali had to meet Frazier and Luke had to meet his father, it was only a matter of time before buzzwords like Java and eXtreme Programming found themselves together on the same marquee. A pair of new books examines some open source Java development tools and outlines how they can be put to use by those trying to master their workload by adopting the techniques of eXtreme programming." Read on for his latest review, which is really two reviews in one. (see each) author (see each) pages (see each) publisher (see each) rating (see each) reviewer Peter Wayner ISBN (see each) summary Two books which explore the use of Ant in Java software development

The two books are excellent examples of how the book industry organizes and disciplines the often crazy explosion of new tools, approaches, structures and metaphors developed by the software industry. Ant: The Definitive Guide by Jesse Tilly and Eric Burke comes from O'Reilly, the masters of producing missing manuals for open source projects. The other, Java Tools for eXtreme Programming: Mastering Open Source Tools including Ant, JUnit, and Cactus by Richard Hightower and Nicholas Lesiecki was published by John Wiley and Sons. Both provide a clear, example-driven exploration of the tools at hand.

The books are probably driven by the success of Kent Beck's Extreme Programming Explained: Embrace Change , a manifesto that outlined Beck's belief that the best way to develop code was with small teams of programmers and users who constantly reworked the software. His most controversial and attention grabbing notion demanded that the programmers work in pairs sharing one computer, one mouse and one keyboard. The constant interaction forced everyone to actually communicate with each other without sending emails and that, more than anything else, may be responsible for the success of his vision. His book spawned a few others on how programmers can plan to apply his vision.

Meanwhile, on the other side of the buzzword galaxy, the Apache group was quietly creating some of the coolest Java development and deployment tools around. Ant was and still is one of the most revolutionary, even though it was just a simple reworking of the classic UNIX make command. Its creator, James Davidson, grew so frustrated with the shell interface of the make command that he wrote a Java-centric version that moved all of the compilation, compression, and distribution inside one Java process. Now, no one has to wait for another Java Virtual Machine to start up to compile each class file independently.

While Davidson's Ant isn't much different than make at first glance, it's hard to overestimate the power of giving programmers a clever tool with plenty of hooks into the development process. Anyone can write new tasks for Ant, and some clever folks have built great new widgets that do things like enforce style guidelines or grab new code from a CVS tree. The structure of Ant lets the programmer dig deeply into the build process. The organic growth and dynamic flexibility shows how close Java can be to Lisp.

Tilly and Burke do a good job capturing the spirit of the tool. Their book follows O'Reilly's time-tested and market-proven simple-examples technique to illustrate how to use Ant for your projects. The chapters in the first half of the book outline how to use and extend Ant for your project. The strength of the book may be the way the authors casually include practical advice about the bugs and idiosyncracies of the tool. While Ant is quite capable, there are a number of little limitations to the XML parser that can drive new users a bit nuts. The second half of the book is a detailed description of the API, the data types and the other practical documentation.

In one sense, it's not really fair to lump this book in with all of this gloss about Extreme Programming. because it's just another methodical O'Reilly book with Dover artwork on the cover. It's important to realize that these tools aren't directly tied to the extreme programming movement. Ant was just created by a Java programmer who hated to wait. Everything else came afterwards when he opened the API.

Ant: The Definitive Guide author Jesse Tilly & Eric M. Burke pages 260 publisher O'Reilly rating 7 ISBN 0-597-00184-3 summary A methodical, in-depth look at the Java tool.

The other book, however, explicitly illustrates how some popular open source tools can help the process of extreme programming. Hightower and Lesiecki's book is much broader than Tilly and Burke's because they want to tackle so much more. They don't want to just provide a missing manual for the tool-- they want to give the world a road map on how they use Ant and its cousins JUnit, HTTPUnit, and Cactus to build better applications. It should be noted that Hightower and Lesiecki work for a consulting group called eBlox and a number of other eBlox programmers are listed as contributors to the book. I think it's fair to say that anyone who hires eBlox will get eXtreme Programming results built with this methodology.

The best part about this book is the wide scope. Ant remains the central taskmaster responsible for building the software, but the book explains how to incorporate other tools for testing the software. The authors embrace one of the extreme programming central beliefs that programmers should define how to test their code before it is actually written. The book explains how to use JUnit, Cactus, and HTTPUnit to set up rules to test every class file. After ANT fires up the compiler, it turns around and runs the tests on the code.

Java Tools for eXtreme Programming author Richard Hightower and Nicholas Lesiecki pages 513 publisher John Wiley and Sons rating 7 ISBN 0-471-20708-X summary How to use some Java tools to transform extreme programming theory into reality.

I don't think that eXtreme Programming or any of these tools is the last word on the subject. The biggest problem is that testing a piece of code is guaranteed to be fairly rudimentary. No programmer can come up with test cases to push all of buttons in all possible combinations. The structure and discipline provided by this approach can help, but the book makes it clear that no amount of pairs programming or extremism will remove the need for the guidance of good programmers.

If anything these tools and the books about them should serve as inspiration for the next round of tools even more focused on extreme programming. The tools are impressive, but there is plenty of room for more innovation. None of them is aimed at explicitly coordinating the work of multiple developers and none of them is designed to provide much structure to the refactoring process. These areas are still very much arts, but there's no reason why tool suites like Ant can't evolve some rational approach to solving them. Perhaps the Slashdot audience can provide some informative postings with pointers to the next generation of cool tools.

Hightower and Lesiecki's book feels a bit more rudimentary and basic than Tilly and Burke's, in part because they cover so much more ground. Although their book is broader, it doesn't go into as much depth about Ant as Tilly and Burke's. The examples are simpler, too, and Hightower and Liesiecki seem mainly interested in getting you excited about building and testing software with the tools. There just isn't as much room for details. If you're interested in learning as much as you can about Ant, choose the book devoted to it. If you want to learn how to use a diverse set of tools to build and test your program in an extreme way, go for that book.

Peter Wayner blends the buzzwords of security, privacy, and data warehousing together in his latest book, Translucent Databases. It shows how to ensure that only the right people see the right information and the wrong people get nothing. His other new book, Disappearing Cryptography, mixes the buzzwords of being, nothingness, steganography, and cryptography. You can purchase both Ant: The Definitive Guide and Java Tools for eXtreme Programming from bn.com. Slashdot welcomes readers' book reviews -- to submit yours, read the book review guidelines, then hit the submission page.

Peter Wayner writes: "In a world where Ali had to meet Frazier and Luke had to meet his father, it was only a matter of time before buzzwords like Java and eXtreme Programming found themselves together on the same marquee. A pair of new books examines some open source Java development tools and outlines how they can be put to use by those trying to master their workload by adopting the techniques of eXtreme programming." Read on for his latest review, which is really two reviews in one. (see each) author (see each) pages (see each) publisher (see each) rating (see each) reviewer Peter Wayner ISBN (see each) summary Two books which explore the use of Ant in Java software development

The two books are excellent examples of how the book industry organizes and disciplines the often crazy explosion of new tools, approaches, structures and metaphors developed by the software industry. Ant: The Definitive Guide by Jesse Tilly and Eric Burke comes from O'Reilly, the masters of producing missing manuals for open source projects. The other, Java Tools for eXtreme Programming: Mastering Open Source Tools including Ant, JUnit, and Cactus by Richard Hightower and Nicholas Lesiecki was published by John Wiley and Sons. Both provide a clear, example-driven exploration of the tools at hand.

The books are probably driven by the success of Kent Beck's Extreme Programming Explained: Embrace Change , a manifesto that outlined Beck's belief that the best way to develop code was with small teams of programmers and users who constantly reworked the software. His most controversial and attention grabbing notion demanded that the programmers work in pairs sharing one computer, one mouse and one keyboard. The constant interaction forced everyone to actually communicate with each other without sending emails and that, more than anything else, may be responsible for the success of his vision. His book spawned a few others on how programmers can plan to apply his vision.

Meanwhile, on the other side of the buzzword galaxy, the Apache group was quietly creating some of the coolest Java development and deployment tools around. Ant was and still is one of the most revolutionary, even though it was just a simple reworking of the classic UNIX make command. Its creator, James Davidson, grew so frustrated with the shell interface of the make command that he wrote a Java-centric version that moved all of the compilation, compression, and distribution inside one Java process. Now, no one has to wait for another Java Virtual Machine to start up to compile each class file independently.

While Davidson's Ant isn't much different than make at first glance, it's hard to overestimate the power of giving programmers a clever tool with plenty of hooks into the development process. Anyone can write new tasks for Ant, and some clever folks have built great new widgets that do things like enforce style guidelines or grab new code from a CVS tree. The structure of Ant lets the programmer dig deeply into the build process. The organic growth and dynamic flexibility shows how close Java can be to Lisp.

Tilly and Burke do a good job capturing the spirit of the tool. Their book follows O'Reilly's time-tested and market-proven simple-examples technique to illustrate how to use Ant for your projects. The chapters in the first half of the book outline how to use and extend Ant for your project. The strength of the book may be the way the authors casually include practical advice about the bugs and idiosyncracies of the tool. While Ant is quite capable, there are a number of little limitations to the XML parser that can drive new users a bit nuts. The second half of the book is a detailed description of the API, the data types and the other practical documentation.

In one sense, it's not really fair to lump this book in with all of this gloss about Extreme Programming. because it's just another methodical O'Reilly book with Dover artwork on the cover. It's important to realize that these tools aren't directly tied to the extreme programming movement. Ant was just created by a Java programmer who hated to wait. Everything else came afterwards when he opened the API.

Ant: The Definitive Guide author Jesse Tilly & Eric M. Burke pages 260 publisher O'Reilly rating 7 ISBN 0-597-00184-3 summary A methodical, in-depth look at the Java tool.

The other book, however, explicitly illustrates how some popular open source tools can help the process of extreme programming. Hightower and Lesiecki's book is much broader than Tilly and Burke's because they want to tackle so much more. They don't want to just provide a missing manual for the tool-- they want to give the world a road map on how they use Ant and its cousins JUnit, HTTPUnit, and Cactus to build better applications. It should be noted that Hightower and Lesiecki work for a consulting group called eBlox and a number of other eBlox programmers are listed as contributors to the book. I think it's fair to say that anyone who hires eBlox will get eXtreme Programming results built with this methodology.

The best part about this book is the wide scope. Ant remains the central taskmaster responsible for building the software, but the book explains how to incorporate other tools for testing the software. The authors embrace one of the extreme programming central beliefs that programmers should define how to test their code before it is actually written. The book explains how to use JUnit, Cactus, and HTTPUnit to set up rules to test every class file. After ANT fires up the compiler, it turns around and runs the tests on the code.

Java Tools for eXtreme Programming author Richard Hightower and Nicholas Lesiecki pages 513 publisher John Wiley and Sons rating 7 ISBN 0-471-20708-X summary How to use some Java tools to transform extreme programming theory into reality.

I don't think that eXtreme Programming or any of these tools is the last word on the subject. The biggest problem is that testing a piece of code is guaranteed to be fairly rudimentary. No programmer can come up with test cases to push all of buttons in all possible combinations. The structure and discipline provided by this approach can help, but the book makes it clear that no amount of pairs programming or extremism will remove the need for the guidance of good programmers.

If anything these tools and the books about them should serve as inspiration for the next round of tools even more focused on extreme programming. The tools are impressive, but there is plenty of room for more innovation. None of them is aimed at explicitly coordinating the work of multiple developers and none of them is designed to provide much structure to the refactoring process. These areas are still very much arts, but there's no reason why tool suites like Ant can't evolve some rational approach to solving them. Perhaps the Slashdot audience can provide some informative postings with pointers to the next generation of cool tools.

Hightower and Lesiecki's book feels a bit more rudimentary and basic than Tilly and Burke's, in part because they cover so much more ground. Although their book is broader, it doesn't go into as much depth about Ant as Tilly and Burke's. The examples are simpler, too, and Hightower and Liesiecki seem mainly interested in getting you excited about building and testing software with the tools. There just isn't as much room for details. If you're interested in learning as much as you can about Ant, choose the book devoted to it. If you want to learn how to use a diverse set of tools to build and test your program in an extreme way, go for that book.

Peter Wayner blends the buzzwords of security, privacy, and data warehousing together in his latest book, Translucent Databases. It shows how to ensure that only the right people see the right information and the wrong people get nothing. His other new book, Disappearing Cryptography, mixes the buzzwords of being, nothingness, steganography, and cryptography. You can purchase both Ant: The Definitive Guide and Java Tools for eXtreme Programming from bn.com. Slashdot welcomes readers' book reviews -- to submit yours, read the book review guidelines, then hit the submission page.

Peter Wayner writes: "In a world where Ali had to meet Frazier and Luke had to meet his father, it was only a matter of time before buzzwords like Java and eXtreme Programming found themselves together on the same marquee. A pair of new books examines some open source Java development tools and outlines how they can be put to use by those trying to master their workload by adopting the techniques of eXtreme programming." Read on for his latest review, which is really two reviews in one. (see each) author (see each) pages (see each) publisher (see each) rating (see each) reviewer Peter Wayner ISBN (see each) summary Two books which explore the use of Ant in Java software development

The two books are excellent examples of how the book industry organizes and disciplines the often crazy explosion of new tools, approaches, structures and metaphors developed by the software industry. Ant: The Definitive Guide by Jesse Tilly and Eric Burke comes from O'Reilly, the masters of producing missing manuals for open source projects. The other, Java Tools for eXtreme Programming: Mastering Open Source Tools including Ant, JUnit, and Cactus by Richard Hightower and Nicholas Lesiecki was published by John Wiley and Sons. Both provide a clear, example-driven exploration of the tools at hand.

The books are probably driven by the success of Kent Beck's Extreme Programming Explained: Embrace Change , a manifesto that outlined Beck's belief that the best way to develop code was with small teams of programmers and users who constantly reworked the software. His most controversial and attention grabbing notion demanded that the programmers work in pairs sharing one computer, one mouse and one keyboard. The constant interaction forced everyone to actually communicate with each other without sending emails and that, more than anything else, may be responsible for the success of his vision. His book spawned a few others on how programmers can plan to apply his vision.

Meanwhile, on the other side of the buzzword galaxy, the Apache group was quietly creating some of the coolest Java development and deployment tools around. Ant was and still is one of the most revolutionary, even though it was just a simple reworking of the classic UNIX make command. Its creator, James Davidson, grew so frustrated with the shell interface of the make command that he wrote a Java-centric version that moved all of the compilation, compression, and distribution inside one Java process. Now, no one has to wait for another Java Virtual Machine to start up to compile each class file independently.

While Davidson's Ant isn't much different than make at first glance, it's hard to overestimate the power of giving programmers a clever tool with plenty of hooks into the development process. Anyone can write new tasks for Ant, and some clever folks have built great new widgets that do things like enforce style guidelines or grab new code from a CVS tree. The structure of Ant lets the programmer dig deeply into the build process. The organic growth and dynamic flexibility shows how close Java can be to Lisp.

Tilly and Burke do a good job capturing the spirit of the tool. Their book follows O'Reilly's time-tested and market-proven simple-examples technique to illustrate how to use Ant for your projects. The chapters in the first half of the book outline how to use and extend Ant for your project. The strength of the book may be the way the authors casually include practical advice about the bugs and idiosyncracies of the tool. While Ant is quite capable, there are a number of little limitations to the XML parser that can drive new users a bit nuts. The second half of the book is a detailed description of the API, the data types and the other practical documentation.

In one sense, it's not really fair to lump this book in with all of this gloss about Extreme Programming. because it's just another methodical O'Reilly book with Dover artwork on the cover. It's important to realize that these tools aren't directly tied to the extreme programming movement. Ant was just created by a Java programmer who hated to wait. Everything else came afterwards when he opened the API.

Ant: The Definitive Guide author Jesse Tilly & Eric M. Burke pages 260 publisher O'Reilly rating 7 ISBN 0-597-00184-3 summary A methodical, in-depth look at the Java tool.

The other book, however, explicitly illustrates how some popular open source tools can help the process of extreme programming. Hightower and Lesiecki's book is much broader than Tilly and Burke's because they want to tackle so much more. They don't want to just provide a missing manual for the tool-- they want to give the world a road map on how they use Ant and its cousins JUnit, HTTPUnit, and Cactus to build better applications. It should be noted that Hightower and Lesiecki work for a consulting group called eBlox and a number of other eBlox programmers are listed as contributors to the book. I think it's fair to say that anyone who hires eBlox will get eXtreme Programming results built with this methodology.

The best part about this book is the wide scope. Ant remains the central taskmaster responsible for building the software, but the book explains how to incorporate other tools for testing the software. The authors embrace one of the extreme programming central beliefs that programmers should define how to test their code before it is actually written. The book explains how to use JUnit, Cactus, and HTTPUnit to set up rules to test every class file. After ANT fires up the compiler, it turns around and runs the tests on the code.

Java Tools for eXtreme Programming author Richard Hightower and Nicholas Lesiecki pages 513 publisher John Wiley and Sons rating 7 ISBN 0-471-20708-X summary How to use some Java tools to transform extreme programming theory into reality.

I don't think that eXtreme Programming or any of these tools is the last word on the subject. The biggest problem is that testing a piece of code is guaranteed to be fairly rudimentary. No programmer can come up with test cases to push all of buttons in all possible combinations. The structure and discipline provided by this approach can help, but the book makes it clear that no amount of pairs programming or extremism will remove the need for the guidance of good programmers.

If anything these tools and the books about them should serve as inspiration for the next round of tools even more focused on extreme programming. The tools are impressive, but there is plenty of room for more innovation. None of them is aimed at explicitly coordinating the work of multiple developers and none of them is designed to provide much structure to the refactoring process. These areas are still very much arts, but there's no reason why tool suites like Ant can't evolve some rational approach to solving them. Perhaps the Slashdot audience can provide some informative postings with pointers to the next generation of cool tools.

Hightower and Lesiecki's book feels a bit more rudimentary and basic than Tilly and Burke's, in part because they cover so much more ground. Although their book is broader, it doesn't go into as much depth about Ant as Tilly and Burke's. The examples are simpler, too, and Hightower and Liesiecki seem mainly interested in getting you excited about building and testing software with the tools. There just isn't as much room for details. If you're interested in learning as much as you can about Ant, choose the book devoted to it. If you want to learn how to use a diverse set of tools to build and test your program in an extreme way, go for that book.

Peter Wayner blends the buzzwords of security, privacy, and data warehousing together in his latest book, Translucent Databases. It shows how to ensure that only the right people see the right information and the wrong people get nothing. His other new book, Disappearing Cryptography, mixes the buzzwords of being, nothingness, steganography, and cryptography. You can purchase both Ant: The Definitive Guide and Java Tools for eXtreme Programming from bn.com. Slashdot welcomes readers' book reviews -- to submit yours, read the book review guidelines, then hit the submission page.

Moshe Bar is (pick one) 1. A Linux kernel developer; 2. A motorcycle enthusiast; 3. The primary openMosix maintainer; 4. A respected Linux device driver writer; 5. Author of several books and many articles about Linux; 6. Newly married. 7. A Talmudic scholar; 8. All of the above. The correct answer is 8, and since in addition to (or perhaps because of) all this Moshe is a popular guy, this interview is here by reader request. (Yes, we take interview requests; send them to robin@roblimo.com.) Ask Moshe whatever you wish, one question per post. We'll send him 10 of the highest moderated questions and post his answers as soon as he gets them back to us.

serendigital writes "Stephen Wolfram, founder of Wolfram Research and creator of Mathematica has, after 10 years+ finished his book, "A New Kind of Science." In a "Wired" article entitled: The Man Who Cracked The Code to Everything ...," Steven Levy talks about how and why the book was written and more importantly, what it is about. The best part of the article is in this exchange: 'I've got to ask you,' I say. 'How long do you envision this rule of the universe to be?' ... 'I don't know. In Mathematica, for example, perhaps three, four lines of code.'" This book seems a little... nutty. But it's been submitted a bunch of times. If anyone wants to review it, go right ahead.

Peter Wayner writes: "There are 1693 books for sale at Amazon.com with the word "java" in the title and almost all of them are earnest, chipper books that promise real programmers, dummies , and nuts that learning Java is easy. Bruce Tate's, Bitter Java , is not one these books." Read on to see if you'd like to experience Bruce Tate's bitterness first hand. Bitter Java: The lessons taught by server-side Java Antipatterns author Bruce A. Tate (with help from Braden R. Flowers) pages publisher Manning rating 8 reviewer Peter Wayner ISBN 1-930110-43-X summary A collection of bad habits to avoid for server developers using Java.

Writing and reading technical books is both a pleasure and a chore. Programming computers can be great fun, but doing the job well requires almost impossible amounts of discipline, attention to detail, and pure drive. The machines churn through billions of operations per second and a mistake in just one can send everything tumbling out of control. Most authors tend to gloss over the difficulty by tossing in a spoonful of Mary Poppins because it does little good to grouse. It's just so simple and straight-forward to toss in optimistic words like "simple" and "straight-forward."

Tate's approach is looks a bit different. He wants to follow in the tradition of Frederick Brook's Mythical Man Month and talk about software development with an honest voice. Microsoft executives, Objective C devotees, and assembler lovers will be disappointed because the title is a bit misleading. He's not really bitter about Java in the way that Princess Diana was bitter about the British Royalty, he's just had a few bad experiences and he wants to help us learn from them.

In fact, he's not even writing about Java in the general sense. The book concentrates on the problems that often arise with most popular and complicated applications for the technology like servlets and enterprise Java beans. If you're building a web site based on Java, then you might want to read through this book.

The structure itself is devoted to uncovering antipatterns , a term Tate uses because it plays off the way that Sun offered Java patterns to help programmers use the new tools efficiently. Most of the chapters show the wrong way to build something and then show how to correct it.

Chapter 8, for instance, demonstrates a bulletin board that seems to be well-designed on the surface. The parts of the data structure are broken up into suitable objects and every object comes with a collection of methods that act as gatekeepers for the data inside the object. It all looks elegant, but it performs badly especially on large installations when the objects live on different servers. Suddenly, all of the extra well-meaning object-oriented engineering starts jamming the flow. Wrapping every object with so much glue code is like hiring more workers to speed up a bureaucracy. Tate shows how to aggregate the calls and speed things up dramatically by cutting through the misapplied object-oriented concepts.

If you step back a bit and think about the book from a distance, the right title starts to look like "Bitter Object-Oriented Programming". Most of the problems in the book emerge when seemingly good uses of OOP turn out to be terribly slow when implemented. While all of the problems are practical hurdles awaiting Java programmers, they must have cousins in the world of C++ and the other OOP languages. Splitting things up into many objects is plenty of fun at the beginning, but when the messages start flowing, the code becomes a swamp.

After a few chapters it becomes clear that object-oriented programming is starting to reach practical limits. The theory may be elegant, but programmers can only make it work if they use guidebooks like Tate's. The object-oriented toolkits are too easy to use dangerously. So what is the solution?

This kind of guidebook filled with antipatterns may be the best we can do for now. Tate himself says that the book is filled with "merc talk", the kind of chatter about hair raising experiences he says that mercenaries trade when they're sitting around the fire. This is an apt description. If you're a hired codeslinger creating J2EE applications or servlets, then this is a good book for your shelf.

Peter Wayner's latest two books are Translucent Databases , an exploration of how to create ultra-secure databases, and Disappearing Cryptography: Information Hiding, Steganography and Watermarking , a book about mathematical parlour tricks, sleights-of-hand, and subversive things you can do with bits. You can purchase Bitter Java at bn.com, and you can join Peter in reviewing books by submitting reviews after reading the book review guidelines.

Peter Wayner writes: "There are 1693 books for sale at Amazon.com with the word "java" in the title and almost all of them are earnest, chipper books that promise real programmers, dummies , and nuts that learning Java is easy. Bruce Tate's, Bitter Java , is not one these books." Read on to see if you'd like to experience Bruce Tate's bitterness first hand. Bitter Java: The lessons taught by server-side Java Antipatterns author Bruce A. Tate (with help from Braden R. Flowers) pages publisher Manning rating 8 reviewer Peter Wayner ISBN 1-930110-43-X summary A collection of bad habits to avoid for server developers using Java.

Writing and reading technical books is both a pleasure and a chore. Programming computers can be great fun, but doing the job well requires almost impossible amounts of discipline, attention to detail, and pure drive. The machines churn through billions of operations per second and a mistake in just one can send everything tumbling out of control. Most authors tend to gloss over the difficulty by tossing in a spoonful of Mary Poppins because it does little good to grouse. It's just so simple and straight-forward to toss in optimistic words like "simple" and "straight-forward."

Tate's approach is looks a bit different. He wants to follow in the tradition of Frederick Brook's Mythical Man Month and talk about software development with an honest voice. Microsoft executives, Objective C devotees, and assembler lovers will be disappointed because the title is a bit misleading. He's not really bitter about Java in the way that Princess Diana was bitter about the British Royalty, he's just had a few bad experiences and he wants to help us learn from them.

In fact, he's not even writing about Java in the general sense. The book concentrates on the problems that often arise with most popular and complicated applications for the technology like servlets and enterprise Java beans. If you're building a web site based on Java, then you might want to read through this book.

The structure itself is devoted to uncovering antipatterns , a term Tate uses because it plays off the way that Sun offered Java patterns to help programmers use the new tools efficiently. Most of the chapters show the wrong way to build something and then show how to correct it.

Chapter 8, for instance, demonstrates a bulletin board that seems to be well-designed on the surface. The parts of the data structure are broken up into suitable objects and every object comes with a collection of methods that act as gatekeepers for the data inside the object. It all looks elegant, but it performs badly especially on large installations when the objects live on different servers. Suddenly, all of the extra well-meaning object-oriented engineering starts jamming the flow. Wrapping every object with so much glue code is like hiring more workers to speed up a bureaucracy. Tate shows how to aggregate the calls and speed things up dramatically by cutting through the misapplied object-oriented concepts.

If you step back a bit and think about the book from a distance, the right title starts to look like "Bitter Object-Oriented Programming". Most of the problems in the book emerge when seemingly good uses of OOP turn out to be terribly slow when implemented. While all of the problems are practical hurdles awaiting Java programmers, they must have cousins in the world of C++ and the other OOP languages. Splitting things up into many objects is plenty of fun at the beginning, but when the messages start flowing, the code becomes a swamp.

After a few chapters it becomes clear that object-oriented programming is starting to reach practical limits. The theory may be elegant, but programmers can only make it work if they use guidebooks like Tate's. The object-oriented toolkits are too easy to use dangerously. So what is the solution?

This kind of guidebook filled with antipatterns may be the best we can do for now. Tate himself says that the book is filled with "merc talk", the kind of chatter about hair raising experiences he says that mercenaries trade when they're sitting around the fire. This is an apt description. If you're a hired codeslinger creating J2EE applications or servlets, then this is a good book for your shelf.

Peter Wayner's latest two books are Translucent Databases , an exploration of how to create ultra-secure databases, and Disappearing Cryptography: Information Hiding, Steganography and Watermarking , a book about mathematical parlour tricks, sleights-of-hand, and subversive things you can do with bits. You can purchase Bitter Java at bn.com, and you can join Peter in reviewing books by submitting reviews after reading the book review guidelines.

Peter Wayner writes: "There are 1693 books for sale at Amazon.com with the word "java" in the title and almost all of them are earnest, chipper books that promise real programmers, dummies , and nuts that learning Java is easy. Bruce Tate's, Bitter Java , is not one these books." Read on to see if you'd like to experience Bruce Tate's bitterness first hand. Bitter Java: The lessons taught by server-side Java Antipatterns author Bruce A. Tate (with help from Braden R. Flowers) pages publisher Manning rating 8 reviewer Peter Wayner ISBN 1-930110-43-X summary A collection of bad habits to avoid for server developers using Java.

Writing and reading technical books is both a pleasure and a chore. Programming computers can be great fun, but doing the job well requires almost impossible amounts of discipline, attention to detail, and pure drive. The machines churn through billions of operations per second and a mistake in just one can send everything tumbling out of control. Most authors tend to gloss over the difficulty by tossing in a spoonful of Mary Poppins because it does little good to grouse. It's just so simple and straight-forward to toss in optimistic words like "simple" and "straight-forward."

Tate's approach is looks a bit different. He wants to follow in the tradition of Frederick Brook's Mythical Man Month and talk about software development with an honest voice. Microsoft executives, Objective C devotees, and assembler lovers will be disappointed because the title is a bit misleading. He's not really bitter about Java in the way that Princess Diana was bitter about the British Royalty, he's just had a few bad experiences and he wants to help us learn from them.

In fact, he's not even writing about Java in the general sense. The book concentrates on the problems that often arise with most popular and complicated applications for the technology like servlets and enterprise Java beans. If you're building a web site based on Java, then you might want to read through this book.

The structure itself is devoted to uncovering antipatterns , a term Tate uses because it plays off the way that Sun offered Java patterns to help programmers use the new tools efficiently. Most of the chapters show the wrong way to build something and then show how to correct it.

Chapter 8, for instance, demonstrates a bulletin board that seems to be well-designed on the surface. The parts of the data structure are broken up into suitable objects and every object comes with a collection of methods that act as gatekeepers for the data inside the object. It all looks elegant, but it performs badly especially on large installations when the objects live on different servers. Suddenly, all of the extra well-meaning object-oriented engineering starts jamming the flow. Wrapping every object with so much glue code is like hiring more workers to speed up a bureaucracy. Tate shows how to aggregate the calls and speed things up dramatically by cutting through the misapplied object-oriented concepts.

If you step back a bit and think about the book from a distance, the right title starts to look like "Bitter Object-Oriented Programming". Most of the problems in the book emerge when seemingly good uses of OOP turn out to be terribly slow when implemented. While all of the problems are practical hurdles awaiting Java programmers, they must have cousins in the world of C++ and the other OOP languages. Splitting things up into many objects is plenty of fun at the beginning, but when the messages start flowing, the code becomes a swamp.

After a few chapters it becomes clear that object-oriented programming is starting to reach practical limits. The theory may be elegant, but programmers can only make it work if they use guidebooks like Tate's. The object-oriented toolkits are too easy to use dangerously. So what is the solution?

This kind of guidebook filled with antipatterns may be the best we can do for now. Tate himself says that the book is filled with "merc talk", the kind of chatter about hair raising experiences he says that mercenaries trade when they're sitting around the fire. This is an apt description. If you're a hired codeslinger creating J2EE applications or servlets, then this is a good book for your shelf.

Peter Wayner's latest two books are Translucent Databases , an exploration of how to create ultra-secure databases, and Disappearing Cryptography: Information Hiding, Steganography and Watermarking , a book about mathematical parlour tricks, sleights-of-hand, and subversive things you can do with bits. You can purchase Bitter Java at bn.com, and you can join Peter in reviewing books by submitting reviews after reading the book review guidelines.

Peter Wayner writes: "There are 1693 books for sale at Amazon.com with the word "java" in the title and almost all of them are earnest, chipper books that promise real programmers, dummies , and nuts that learning Java is easy. Bruce Tate's, Bitter Java , is not one these books." Read on to see if you'd like to experience Bruce Tate's bitterness first hand. Bitter Java: The lessons taught by server-side Java Antipatterns author Bruce A. Tate (with help from Braden R. Flowers) pages publisher Manning rating 8 reviewer Peter Wayner ISBN 1-930110-43-X summary A collection of bad habits to avoid for server developers using Java.

Writing and reading technical books is both a pleasure and a chore. Programming computers can be great fun, but doing the job well requires almost impossible amounts of discipline, attention to detail, and pure drive. The machines churn through billions of operations per second and a mistake in just one can send everything tumbling out of control. Most authors tend to gloss over the difficulty by tossing in a spoonful of Mary Poppins because it does little good to grouse. It's just so simple and straight-forward to toss in optimistic words like "simple" and "straight-forward."

Tate's approach is looks a bit different. He wants to follow in the tradition of Frederick Brook's Mythical Man Month and talk about software development with an honest voice. Microsoft executives, Objective C devotees, and assembler lovers will be disappointed because the title is a bit misleading. He's not really bitter about Java in the way that Princess Diana was bitter about the British Royalty, he's just had a few bad experiences and he wants to help us learn from them.

In fact, he's not even writing about Java in the general sense. The book concentrates on the problems that often arise with most popular and complicated applications for the technology like servlets and enterprise Java beans. If you're building a web site based on Java, then you might want to read through this book.

The structure itself is devoted to uncovering antipatterns , a term Tate uses because it plays off the way that Sun offered Java patterns to help programmers use the new tools efficiently. Most of the chapters show the wrong way to build something and then show how to correct it.

Chapter 8, for instance, demonstrates a bulletin board that seems to be well-designed on the surface. The parts of the data structure are broken up into suitable objects and every object comes with a collection of methods that act as gatekeepers for the data inside the object. It all looks elegant, but it performs badly especially on large installations when the objects live on different servers. Suddenly, all of the extra well-meaning object-oriented engineering starts jamming the flow. Wrapping every object with so much glue code is like hiring more workers to speed up a bureaucracy. Tate shows how to aggregate the calls and speed things up dramatically by cutting through the misapplied object-oriented concepts.

If you step back a bit and think about the book from a distance, the right title starts to look like "Bitter Object-Oriented Programming". Most of the problems in the book emerge when seemingly good uses of OOP turn out to be terribly slow when implemented. While all of the problems are practical hurdles awaiting Java programmers, they must have cousins in the world of C++ and the other OOP languages. Splitting things up into many objects is plenty of fun at the beginning, but when the messages start flowing, the code becomes a swamp.

After a few chapters it becomes clear that object-oriented programming is starting to reach practical limits. The theory may be elegant, but programmers can only make it work if they use guidebooks like Tate's. The object-oriented toolkits are too easy to use dangerously. So what is the solution?

This kind of guidebook filled with antipatterns may be the best we can do for now. Tate himself says that the book is filled with "merc talk", the kind of chatter about hair raising experiences he says that mercenaries trade when they're sitting around the fire. This is an apt description. If you're a hired codeslinger creating J2EE applications or servlets, then this is a good book for your shelf.

Peter Wayner's latest two books are Translucent Databases , an exploration of how to create ultra-secure databases, and Disappearing Cryptography: Information Hiding, Steganography and Watermarking , a book about mathematical parlour tricks, sleights-of-hand, and subversive things you can do with bits. You can purchase Bitter Java at bn.com, and you can join Peter in reviewing books by submitting reviews after reading the book review guidelines.

Peter Wayner writes: "There are 1693 books for sale at Amazon.com with the word "java" in the title and almost all of them are earnest, chipper books that promise real programmers, dummies , and nuts that learning Java is easy. Bruce Tate's, Bitter Java , is not one these books." Read on to see if you'd like to experience Bruce Tate's bitterness first hand. Bitter Java: The lessons taught by server-side Java Antipatterns author Bruce A. Tate (with help from Braden R. Flowers) pages publisher Manning rating 8 reviewer Peter Wayner ISBN 1-930110-43-X summary A collection of bad habits to avoid for server developers using Java.

Writing and reading technical books is both a pleasure and a chore. Programming computers can be great fun, but doing the job well requires almost impossible amounts of discipline, attention to detail, and pure drive. The machines churn through billions of operations per second and a mistake in just one can send everything tumbling out of control. Most authors tend to gloss over the difficulty by tossing in a spoonful of Mary Poppins because it does little good to grouse. It's just so simple and straight-forward to toss in optimistic words like "simple" and "straight-forward."

Tate's approach is looks a bit different. He wants to follow in the tradition of Frederick Brook's Mythical Man Month and talk about software development with an honest voice. Microsoft executives, Objective C devotees, and assembler lovers will be disappointed because the title is a bit misleading. He's not really bitter about Java in the way that Princess Diana was bitter about the British Royalty, he's just had a few bad experiences and he wants to help us learn from them.

In fact, he's not even writing about Java in the general sense. The book concentrates on the problems that often arise with most popular and complicated applications for the technology like servlets and enterprise Java beans. If you're building a web site based on Java, then you might want to read through this book.

The structure itself is devoted to uncovering antipatterns , a term Tate uses because it plays off the way that Sun offered Java patterns to help programmers use the new tools efficiently. Most of the chapters show the wrong way to build something and then show how to correct it.

Chapter 8, for instance, demonstrates a bulletin board that seems to be well-designed on the surface. The parts of the data structure are broken up into suitable objects and every object comes with a collection of methods that act as gatekeepers for the data inside the object. It all looks elegant, but it performs badly especially on large installations when the objects live on different servers. Suddenly, all of the extra well-meaning object-oriented engineering starts jamming the flow. Wrapping every object with so much glue code is like hiring more workers to speed up a bureaucracy. Tate shows how to aggregate the calls and speed things up dramatically by cutting through the misapplied object-oriented concepts.

If you step back a bit and think about the book from a distance, the right title starts to look like "Bitter Object-Oriented Programming". Most of the problems in the book emerge when seemingly good uses of OOP turn out to be terribly slow when implemented. While all of the problems are practical hurdles awaiting Java programmers, they must have cousins in the world of C++ and the other OOP languages. Splitting things up into many objects is plenty of fun at the beginning, but when the messages start flowing, the code becomes a swamp.

After a few chapters it becomes clear that object-oriented programming is starting to reach practical limits. The theory may be elegant, but programmers can only make it work if they use guidebooks like Tate's. The object-oriented toolkits are too easy to use dangerously. So what is the solution?

This kind of guidebook filled with antipatterns may be the best we can do for now. Tate himself says that the book is filled with "merc talk", the kind of chatter about hair raising experiences he says that mercenaries trade when they're sitting around the fire. This is an apt description. If you're a hired codeslinger creating J2EE applications or servlets, then this is a good book for your shelf.

Peter Wayner's latest two books are Translucent Databases , an exploration of how to create ultra-secure databases, and Disappearing Cryptography: Information Hiding, Steganography and Watermarking , a book about mathematical parlour tricks, sleights-of-hand, and subversive things you can do with bits. You can purchase Bitter Java at bn.com, and you can join Peter in reviewing books by submitting reviews after reading the book review guidelines.

Peter Wayner writes: "There are 1693 books for sale at Amazon.com with the word "java" in the title and almost all of them are earnest, chipper books that promise real programmers, dummies , and nuts that learning Java is easy. Bruce Tate's, Bitter Java , is not one these books." Read on to see if you'd like to experience Bruce Tate's bitterness first hand. Bitter Java: The lessons taught by server-side Java Antipatterns author Bruce A. Tate (with help from Braden R. Flowers) pages publisher Manning rating 8 reviewer Peter Wayner ISBN 1-930110-43-X summary A collection of bad habits to avoid for server developers using Java.

Writing and reading technical books is both a pleasure and a chore. Programming computers can be great fun, but doing the job well requires almost impossible amounts of discipline, attention to detail, and pure drive. The machines churn through billions of operations per second and a mistake in just one can send everything tumbling out of control. Most authors tend to gloss over the difficulty by tossing in a spoonful of Mary Poppins because it does little good to grouse. It's just so simple and straight-forward to toss in optimistic words like "simple" and "straight-forward."

Tate's approach is looks a bit different. He wants to follow in the tradition of Frederick Brook's Mythical Man Month and talk about software development with an honest voice. Microsoft executives, Objective C devotees, and assembler lovers will be disappointed because the title is a bit misleading. He's not really bitter about Java in the way that Princess Diana was bitter about the British Royalty, he's just had a few bad experiences and he wants to help us learn from them.

In fact, he's not even writing about Java in the general sense. The book concentrates on the problems that often arise with most popular and complicated applications for the technology like servlets and enterprise Java beans. If you're building a web site based on Java, then you might want to read through this book.

The structure itself is devoted to uncovering antipatterns , a term Tate uses because it plays off the way that Sun offered Java patterns to help programmers use the new tools efficiently. Most of the chapters show the wrong way to build something and then show how to correct it.

Chapter 8, for instance, demonstrates a bulletin board that seems to be well-designed on the surface. The parts of the data structure are broken up into suitable objects and every object comes with a collection of methods that act as gatekeepers for the data inside the object. It all looks elegant, but it performs badly especially on large installations when the objects live on different servers. Suddenly, all of the extra well-meaning object-oriented engineering starts jamming the flow. Wrapping every object with so much glue code is like hiring more workers to speed up a bureaucracy. Tate shows how to aggregate the calls and speed things up dramatically by cutting through the misapplied object-oriented concepts.

If you step back a bit and think about the book from a distance, the right title starts to look like "Bitter Object-Oriented Programming". Most of the problems in the book emerge when seemingly good uses of OOP turn out to be terribly slow when implemented. While all of the problems are practical hurdles awaiting Java programmers, they must have cousins in the world of C++ and the other OOP languages. Splitting things up into many objects is plenty of fun at the beginning, but when the messages start flowing, the code becomes a swamp.

After a few chapters it becomes clear that object-oriented programming is starting to reach practical limits. The theory may be elegant, but programmers can only make it work if they use guidebooks like Tate's. The object-oriented toolkits are too easy to use dangerously. So what is the solution?

This kind of guidebook filled with antipatterns may be the best we can do for now. Tate himself says that the book is filled with "merc talk", the kind of chatter about hair raising experiences he says that mercenaries trade when they're sitting around the fire. This is an apt description. If you're a hired codeslinger creating J2EE applications or servlets, then this is a good book for your shelf.

Peter Wayner's latest two books are Translucent Databases , an exploration of how to create ultra-secure databases, and Disappearing Cryptography: Information Hiding, Steganography and Watermarking , a book about mathematical parlour tricks, sleights-of-hand, and subversive things you can do with bits. You can purchase Bitter Java at bn.com, and you can join Peter in reviewing books by submitting reviews after reading the book review guidelines.

ReadParse writes "There was a previous story about "The Hitchhiker's Guide to the Galaxy" being released on DVD in January. This turned out to be a Region 2 DVD, but the Region 1 DVD was released on or about April 30th. There are two discs, the first of which is the BBC Miniseries, which was adapted from the BBC radio play. It suddenly occurs to me to submit this story, because mine was just delivered within the past hour. Right now it's the 12th most popular DVD on Amazon." Several people also noted that Adams' final (I guess) book, The Salmon of Doubt, is now hitting the shelves.

Fubar writes "Longtime TidBITS publisher Adam C. Engst recently wrote a book about Apple's iPhoto software. Faced with the standard publishing-to-market delays that would only leave a month or so before the next version of iPhoto is released, Engst worked out a deal with Amazon that folks can download the book for $13 now, and receive a free dead-tree version once the book is updated to reflect the changes in the new version of iPhoto. This is the first 'book upgrade' I've ever heard of."

I'm not much of a salesman, in comfort or skill, but I'm willing to hype my books, especially given the realities of 21st Century publishing, when you do it yourself or nobody does it. Some people think if you get a book published, you're a big deal and a rich one. If you're Grisham or King, that's true. The reality: Few books sell well, and even fewer (mine, for example) make money. Can content like books be successfully "open-marketed" on the Net? I say yes.

In early March my eleventh book A Dog Year; Twelve Months, Four Dogs and Me was published by Random House/Villard. For several months I've been working on a bottom-up, Net-based marketing program that permits me to push my own book in my own way, rather than rely on big publishing or big media. That led me to the banner ad on this site a lot of you have seen and e-mailed me about. So why am I buying a banner ad, on Slashdot of all places, to tout my new book about a year with four dogs? It's a chance for me to tick off the yowling hordes, which is always fun. Some will shriek that a dog saga has little to do with open source, technology or selling things on the Net. But it does, and I'm happy -- eager, even -- to explain why.

I do most of my hyping for A Dog Year in the expected places -- in media interviews and on various dog-related sites, mailing lists and forums.

My reason for advertising here, too, is that I believe the Net offers the best place for individual entrepreneurs of all kinds -- writers, game creators, artists, musicians, software designers -- to skirt conventional costs, limitations and marketing practices and find their own audiences. To me, that's a big part of the "open" in open source. Younger people raised on the Net don't pay nearly as much attention to mainstream media as their elders, so we have to reach them where they are. The good news is that we can.

In fact, Net communications themselves have become increasingly segmented and targeted. Much has become subterranean, centered on mailing lists, IM and other limited-entry venues. In the weeks before my book's publication, I concentrated on these grass-roots venues, contacting websites, subscribing to mailing lists, e-mailing excerpts of my book to people who were interested. People on special interests lists and chat rooms don't mind being pitched on subjects they're interested in. They don't consider it spam. What they hate is being bombarded with messages for things they don't care about, which is what traditional media does. Besides which, I can't afford to take an ad out in Time magazine or on the ABC Evening News.

Elsewhere, individual entrepreneurs and creators find it more and more difficult to survive. The megacorporations who've taken over much of culture and media are primarily interested in best-selling mega-products -- Britney Spears, John Grisham -- not idiosyncratic ones like mine. They have a point, too. My last book found its own audience, or rather its audience found it. It did all right, but didn't sell much beyond it's core audience. To successfully market a book like Running To The Mountain or A Dog Year (at least in the conventional way) could cost more money than my publisher expects to earn. And interesting, I believe the Running To The Mountain excerpt that ran on Slashdot sold more books than a subsequent appearance on the Oprah Winfrey show.

The Net, at least in theory, can bypass that stalemate and create radical new opportunities for artists of all kinds. So I don't mind paying for my own ad. I think it has worked.

Individuals are under attack all across our culture, from the likes of Microsoft and Wal-Mart and Sony to publishing conglomerates. The Net can be a way out for people like me (us), whether we're telling the story of our dogs or coming up with new software. What's why I bought a banner on Slashdot. If it works, it could sell some books, sure. I have no apologies to make for that. But it could also help demonstrate to writers and other people struggling to survive in a mass-market world that the Open Source idea is only fractionally about software. It's about individualism, free expression, and a culture open to us all.

Anonymous Coward writes "Just about everyone has used either the CDDB or freedb CD databases. And many people are also familiar with DVD Profiler, a well developed database for DVD fans. Each of these public databases have a number of wonderful strengths, and a few weaknesses, but they are well thought out and well developed. After searching Google, sourceforge and every other search engine I could think of, I have come to the conclusion that there is not a well developed internet book database. While many people would be quick to point out the various commercial websites (Amazon, Barnes and Noble, etc), and the various library databases (Library of Congress, Boston Public Library, and other online catalogs), none of these online databases offer the same ease of use of DVD Profiler, or the open structure of the online CD databases. The closest program I could find was the shareware program Readerware. This program will search several web sites and download the pertinent information, but it is extremely inefficient, as it does not then store the data in a central database to make it easier for the other users, and in my opinion, the UI is terrible. What programs, if any, do those of you reading /. use to keep track of your books? If you were to start an open source internet book database project, what features would you include in it?" Books in Print is the definitive book database; apparently it costs about $30,000/year to license it.

Tal Cohen writes: "It is said that one of the most important skills a physicist needs is the ability to quickly make "back-of-the-envelope" calculations. For example, Jan Wolitzky (in Jon Bently's "Programming Pearls") tells about Enrico Fermi, Robert Oppenheimer, and the other Manhattan Project brass who were behind a low blast wall awaiting the detonation of the first nuclear device from a few thousand yards away. Fermi was tearing up sheets of paper into little pieces, which he tossed into the air when he saw the flash. After the shock wave passed, he paced off the distance traveled by the paper shreds, performed a quick "back-of-the-envelope" calculation, and arrived at a figure for the explosive yield of the bomb, which was confirmed much later by expensive monitoring equipment." Read on to find out what this has to do with the unusual characteristics of Earth, and how they could influence our search for life elsewhere in the universe. Rare Earth: Why Complex Life is Uncommon in the Universe author Peter D. Ward, Donald Brownlee pages 368 publisher Copernicus rating 7 reviewer Tal Cohen ISBN 0387987010 summary Maybe we are alone, after all.

But expensive monitoring equipment which can confirm the calculation does not always exist, and hence in some fields, our entire knowledge is based on back-of-the-envelope calculations and rough estimates.

Take, for example, the following question: "How many intelligent civilizations, capable of radio communications, currently exist in the Milky Way galaxy?". The worthwhileness of search projects (such as SETI) is closely related to the answer to this question. The number of positively known civilizations is exactly one: the human civilization. And yet, many scientists believe, or at least believed until recently, that the actual number is far, far higher.

This belief was based on various estimates, such as the calculation proposed by Frank Drake, now known as "The Drake Equation." This equation was popularized in Carl Sagan's remarkable TV series, "Cosmos". Sagan himself believed the calculation's result, and was one of the founders of SETI.

Drake's equation is easy to understand. Take the number of stars in the galaxy (about 200 to 300 billion, based on generally accepted estimates), and multiply it by: the percentage of stars that are similar to our Sun in the energy output and stability; the percentage of stars that have planets (since not every star has any); the percentage of planets orbiting their star in a proper distance (so they could hold liquid water, a necessity for maintaining life); the percentage of planets with liquid water on which life actually evolved; and finally, the percentage of life-bearing planets in which intelligent civilizations (i.e., those that can communicate by radio) eventually came to be. All in all, there are five or six factors in this product.

(Note: In my own copy of the book (2nd impression), page 267 states that "a good estimate for the number of stars in our galaxy [is] between 200 and 300 million" - one letter misspelled, and wrong by three orders of magnitude. I do hope the authors' actual calculations were based on the correct value.)

But what values should be used for the various percentages? Drake (and Sagan) chose what they considered to be a conservative approach, and estimated that only about 1 in 10 stars has any planets; only 1 in 10 planets is in the proper orbit, and so forth. Despite the conservative approach, the results were encouraging, indicating that there are thousands of intelligent civilizations in the Milky Way, and probably millions of them in the whole universe. Thus they concluded that there is intelligent life out there, in all likelihood; now we only have to look for it.

In their book Rare Earth, published by Copernicus Press in 2000, Peter Ward and Donald Brownlee point at Drake's (and other physicists') mistakes in a long and depressing discussion, a discussion that took the wind out of more than one SF author's sail.

The book presents what the authors call "the rare Earth hypothesis": simple (bacterial) life is very common in the universe; complex life (multi-cellular life forms, or animals -- let alone intelligent life) is very rare. The first part of the hypothesis is easy to understand, and few scientists will argue with it: indications of simple life were already discovered on rocks originating on Mars, and even here on Earth in conditions that were, until recently, considered completely hostile to life (such as temperatures higher than 100 degrees Celsius, in which 'extremophile' bacteria were found to exist). The second part is the interesting one, and it suggests that the existence of simple life does not necessarily lead to the evolutionary development of complex life, for any number of reasons.

Drake's mistake was basically in the assumption that all it takes for a planet to develop life is being in the proper distance from a proper star. The truth, Ward and Brownlee suggest, is that we have to look at each and every attribute of Earth, and re-estimate its importance for supporting life. Drake's equation is a statistical calculation, but with no other example for life, we're doing statistics with N=1.

Well then, what are the special attributes of Earth that we have to take into account when attempting to run this calculation?

• Proper distance from the star. If a planet orbits its sun too closely or too far away, liquid water would not exist. There isn't much margin for error here: a change of 5 to 15 percent in Earth's distance from the Sun would lead to the freezing, or boiling, of all water on Earth.
• Proper distance from the center of the galaxy. The density of stars near the center of the galaxy is so high, that the amount of cosmic radiation in that area would prevent the development of life.
• A star of a proper mass. A too-massive star would emit too much ultra-violet energy, preventing the development of life. A star that is too small would require the planet to be closer to it (in order to maintain liquid water). But such a close distance would result in tidal locking (where one face of the planet constantly faces the star, and the other always remains dark -- as with the moon in its orbit around Earth). In this case one side becomes too hot, the other too cold, and the planet's atmosphere escapes.
• A proper mass. A planet that is too small will not be able to maintain any atmosphere. A planet that is too massive would attract a larger number of asteroids, increasing the chances of life-destroying cataclysms.
• Oceans. The ability to maintain liquid water does not automatically imply that there will be any on the planet's surface. It looks like Earth acquired its own water from asteroids made of ice that crashed here billions of years ago. On the other hand, too much water (i.e., a planet with little or no land) will lead to an unstable atmosphere, unfit for maintaining life.
• A constant energy output from the star. If the star's energy output suddenly decreases, even for a relatively short while, all the water on the planet would freeze. This situation is irreversible, since when the star resumes its normal energy output, the planet's now-white surface will reflect most of this energy, and the ice will never melt. Conversely, if the stars energy output increases for a short while, all the oceans will evaporate and the result would be an irreversible greenhouse-effect, preventing the oceans from reforming.
• Successful evolution. Even if all of these conditions hold, and simple life evolves (which probably happens even if some of these conditions aren't met), this still does not imply that the result is animal (multi-cellular) life. The evolution of life on Earth included some surprising leaps; two worth mentioning are the move from simple, single-cellular life to cells which contain internal organs, and the appearance of calcium-based skeletons. It appears like the first of these leaps took more time than the evolution from complex single-celled life to full-blown humans.
• Avoiding disasters. Any number of disasters can lead to the complete extinction of all life on a planet. This include the supernova of a nearby star; a massive asteroid impact (like the one that probably caused the extinction of dinosaurs, and 70% of all other life-forms at the time); drastic changes of climate; and so on.

There are also a few attributes that seem, at first, to be completely unrelated to life and not required for its development. Ward and Brownlee argue strongly for the importance of the following attributes:

• The existence of a Jupiter-like planet in the system. Apparently, Jupiter's large mass attracted many of the asteroids that would have otherwise hit Earth. Could life evolve in a system with no Jovian planet? On the other hand, too many Jovian planets, or one that is too large, could lead to a non-stable solar system, sending the smaller planets into the central sun or ejecting them into the cold of space.
• The existence of a large, nearby moon. Luna, Earth's moon, is atypically large and close. Both of Mars's moons, for example, are minor rocks by comparison. What does this have to do with life? Well, it turns out that Luna kept (and still keeps) Earth's tilt stable. Without Luna, the tilt would have changed drastically over time, and no stable climate could exist. If the tilt would have stabilized on a too-large or too-small value, the results could also be disastrous; Earth's tilt is "just right."
• Plate tectonics. Surprisingly enough, it seems like plate tectonics are required for maintaining a stable atmosphere. Plate tectonics play an important role in a complex feedback system (explained in detail in the book) that prevents too many greenhouse gases from existing in the atmosphere. No other planet (except maybe for Jupiter's moon Europa) is known to have plate tectonics. Is this a rare phenomenon, but required for life?

The bottom line is that many additional factors must be added to Drake's equation. One must keep in mind that as any term in such an equation approaches zero, so too does the final product. For most terms, we have no way of reliably estimating their true value, but it seems like at least some of these values are extremely low.

Two important things should be noted about this book. First, about what it does not contain: although I am sure many people will see the Rare Earth Hypothesis as another proof for the existence of a god, this notion of a proof is completely unrelated to the authors' ideas. The hypothesis claims that the conditions for creating complex life are rare; but we know for a fact that at least in one case, all the required conditions were met. Additionally, anyone who insists on taking the ideas of this book as a proof for god's existence will also have to accept the authors' prepositions about the age of the universe, the age of planet Earth, and more importantly, the theory of evolution.

Second, about what the book does contain: the book discusses at length all the issues I've listed above, and more. The problem is that sometimes one gets the feeling that these issues are discussed in too much detail, and the authors tend to repeat themselves, or to delve too deep into some of the less-important aspects of their theory. This is certainly not your common popular-science book; it relies on very up-to-date research results (including some results that were not even published when the book went to press). The writing gets technical on many points in astrophysics, biology, chemistry, and geology (as well as the new field of astrobiology, of course). Over 25 pages of bibliography and references are included.

The theory's weakest point, however, is obvious. The authors admit (after 281 pages of discussion) that their base assumption was that every complex life-form would be similar in many ways to life on Earth: "We assume in this book that animal life will be somehow Earth-like. We take the perhaps jingoistic stance that Earth-life is every-life, that lessons from Earth are not only guides but also rules. We assume that DNA is the only way, rather than only one way" (p. 282).

For me, reading this book was a fascinating and awe-inspiring experience. The most important conclusion (apart from SETI being a huge waste of resources) is an unavoidable cliché, which the authors avoided presenting directly, even though it stares into the reader's face from every page and each paragraph: What we have here is rare, maybe even unique. We should try a little harder to make sure it survives.

Post Scriptum: A news item in the November/December 2001 issue of the Skeptical Inquirer (Vol. 25, No. 6) states that "David Darling, an astronomer who is a critic of the Rare Earth hypothesis, has revealed that one of the strongest influences on the authors, a young [...] astronomer who they acknowledge in their preface 'changed many of our views about planets and habitable zones', has a hidden, Earth-is-unique agenda motivated by strong 'intelligent design' religious views." That astronomer, Guillermo Gonzalez, published several articles in Connections, a quarterly newsletter published by Reasons to Believe, Inc. In one of these articles, co-authored with the creationist scientist Hugh Ross, Gonzalez writes: "The fact that the Sun's location is fine-tuned to permit the possibility of life [...] powerfully suggests divine design."

Darling published these findings, along with a detailed point-by-point scientific critique of the Rare Earth hypothesis, in his book Life Everywhere: The Maverick Science of Astrobiology . Skeptical Inquirer quotes Darling as saying, "What matters is not whether there's anything unusual about the Earth; there's going to be something idiosyncratic about every planet in space. What matters is whether any of Earth's circumstances are not only unusual but also essential for complex life. So far we've seen nothing to suggest there is."

For more about this book, please see this page. For additional book reviews, please visit Tal's bookshelf. You can purchase Rare Earth from bn.com. Want to see your own review here? Just read the book review guidelines, then use Slashdot's handy submission form.

bughunter writes "Accomplished astrophysicist and SF author Gregory Benford shares a personal account of his recent conversation with Stephen Hawking at Reason Online. As usual, Benford's style is engaging and informal, and this doesn't read like a typical interview. Although the article is short on jargon, Benford and Hawking share insights on the meaning of life, the universe, and everything, as such minds are want to do. We even get a glimpse of Cambridge tunnel hacking. Of course, there's also a plug for Hawking's new book, The Universe in a Nutshell."

McSpew writes "Hackers author Steven Levy so far is the only person in the mainstream press to pick up on the the travesty of the SSSCA hearings. He points out that only the media giants could be so stupid as to think treating their customers like criminals will increase sales." Steven's a very smart guy - and very well said on this issue.

SilverStr writes: "With all the recent discussion on organizations rethinking their security strategies, I thought I would do a review on one of my favorite books. I have stayed pretty quiet on /. over the years, but security is something I don't think developers anywhere should be taking lightly. Hopefully some of them will get something out of my review and pick this book up." Read on for the rest of his review of Ross Anderson's Security Engineering. Security Engineering: A Guide to Building Dependable Distributed Systems author Ross Anderson pages 612 publisher Wiley Computer Publishing rating 9.5 reviewer SilverStr ISBN 0-471-38922-6 summary An exceptional book on the dynamics of security engineering. A must have on all developers shelves who care about digital security and its impact on system design.

Introduction

The complexities of security engineering go beyond the ideals of understanding buffer overflows and considering that patching your systems is not an option. Many a Slashdot article (particularly the latest one on Louis Bertrand's OpenBSD presentation) has comments on the failings of code design. In Ross Anderson's book Security Engineering: A Guide to Building Dependable Distributed Systems, Ross goes into impeccable detail into the aspects of building systems resilient to malicious attack, abuse and programming error.

The book is well laid out, and in my opinion Ross properly segmented the topics in a way that makes the sections easy to read. The first section is focused on the many concepts of digital security such as protocols, access control and cryptography, and is written in a way so that you do not require a technical background to understand. It was refreshing to read how Ross explains cryptography in such a non-threatening manner that you can understand it without having to refer to Applied Cryptography from Bruce Schneier. Many authors have tried this in the past, and failed.

The second part of the book goes into considerable detail about practical and important applications such as banking and network attacks and defense. I have to be honest with you, I don't read a lot of books on software engineering that go into Radar Jamming and Nuclear Command and Control systems, and I found that sort of discussion exciting. (Although I have no interest in writing security code for the next cruise missile that will move the world to a level of DefCon quicker than that in movies like War Games, I still was quite interested in the approach.) Many of the examples and case studies that Ross explains bring the whole topic together to help strengthen the point about security engineering and its application to each system. Further to this, Ross' writing made me shutter to think about just how popular applications like bankcard systems have been written to be so weak and vulnerable. Before the book's main content, Ross includes an explanation the legalities of publishing some of this information. It wasn't until I started reflecting on some of the case studies that I realized how potent and valuable some of this information is, especially when I thought of potential risks that should have been mitigated and were not. Ross' examples should be considered textbook cases, though, and not information that can be drastically abused.

The third part looks into the organizational and policy issues faced with security engineering. From office politics to security and the law, this section goes into depth about managing security engineering and its affects on business and people. Compared to the rest of this book I found some of the topics in this section too short on detail, feeling like just a glancing blow, but still giving the reader enough information to seek more in depth content if they so choose. (Check out the bibliography for such information.) Discussing issues such as Carnivore, digital copyright, and system evaluation and assurance, this section rounds out the book quite well.

Why to Consider this Book

If you are a developer considering security (which should be all developers, anyways) this book provides a good balance on security engineering, and serves as an excellent reference work. It can work well as a textbook introducing developers to security engineering, and can be used as a good introduction to many dynamics of digital security. (Hint to COMP professors outside of Cambridge: get your students to read this book -- after you do of course).

Although you might not be able to use the section on radar jamming and its countermeasures directly, you may still be able to use principles in writing protected electronic systems while working on that new wireless system for Ma Bell. And finally, you should use this book as a brick in the foundation of learning on the concepts of writing secure code.

Something else you should consider in this book is the extensive bibliography in the back. If you want to follow up with more detailed information in any one section, Ross did an tremendous job in providing pointers to research papers and work done by others to read and research on. This in itself made the book well worth the money, as for me I have already read up and used some of the works I didn't have indexed to me before.

Wrap Up

If you are going to read this book and look for samples to write secure code, you are going to pick up the wrong book. This book is a cornerstone in building a strong foundation and understanding of security engineering. This book is goes beyond understanding the practical components of buffer overflows, stack smashing and code audits for review, and takes the reader into a new plain of understanding when it comes to security engineering. It is not a cookbook for lazy script kiddies to learn how to attack weak systems, but can be used to allow you to learn from others mistakes. You don't have to be a developer working on security systems to gain some knowledge from this text. Areas in the book such as that on E-Commerce can very much help bridge the chasm of bad web application design and can help you refrain from getting in the trap of fast application development full of vulnerabilities and exposing users to unnecessary online risk.

It is the responsibility of all developers to understand the risks they expose their software and their clients to. I am sure some developers will have some excuse where their web forms and applications do not require them to learn such silly things. That's fine. Hopefully I wouldn't need to use your systems. For the rest of us though, this is a must read.

Table of Contents

Part One

1. What Is Security Engineering
2. Protocols
3. Passwords
4. Access Control
5. Cryptography
6. Distributed Systems

Part Two

1. Multilevel Security
2. Multilateral Security
3. Banking and Bookkeeping
4. Monitoring Systems
5. Nuclear Command and Control
6. Security Printing and Seals
7. Biometrics
8. Physical Tamper Resistance
9. Emission Security
10. Electronic and Information Warfare
11. Telecom System Security
12. Network Attack and Defense
13. Protecting E-Commerce Systems
14. Copyright and Privacy Protection

Part Three

1. E-Policy
2. Management Issues
3. System Evaluation and Assurance
4. Conclusions

Bibliography

You can purchase Security Engineering from Fatbrain. Want to see your own review here? Just read the book review guidelines, then use Slashdot's handy submission form.

MacSlash writes "There's an interview over at MacSlash with David Pogue, the New York Times Tech columnist and author of lots of stuff, including the best-selling Mac OS X: The Missing Manual and his brand new Piloting Palm, The Inside Story of Palm, Handspring and the Birth of the Billion Dollar Handheld Industry. The interview deals with subjects like the future of Mac OS X, how Unix programmers are providing some of the best new stuff, and even why Pogue uses Windows to write his books."

MacSlash writes "There's an interview over at MacSlash with David Pogue, the New York Times Tech columnist and author of lots of stuff, including the best-selling Mac OS X: The Missing Manual and his brand new Piloting Palm, The Inside Story of Palm, Handspring and the Birth of the Billion Dollar Handheld Industry. The interview deals with subjects like the future of Mac OS X, how Unix programmers are providing some of the best new stuff, and even why Pogue uses Windows to write his books."

fmita writes: "Amazon.com is auctioning off 3 Segways to the public. The proceeds are to go to a foundation started by the inventor. These are the first Segways to go to the public. Since there are only three, they sure aren't cheap." Women drool over a man on a Segway.

fmita writes: "Amazon.com is auctioning off 3 Segways to the public. The proceeds are to go to a foundation started by the inventor. These are the first Segways to go to the public. Since there are only three, they sure aren't cheap." Women drool over a man on a Segway.

way0utwest asks: "I was searching on Amazon today for Lawrence Lessig's 'The Future of Ideas'. While browsing, I noticed that there was also an e-book version of the same title. What was amazing was that the hardcover copy of the book is $21 and the e-book, which is downloaded, is $24! Now I may be just a simple computer programmer, but it seems to me that there is less overall 'cost' involved with the e-book and it should be cheaper. There's very little 'inventory' to store (how much disk space and electricity cost can there be?). There's no risk of having to 'return' the book to the publisher. There's no labor needed to 'ship' me the book. How can it cost more? Is Adobe charging that much for the licensing of the e-book? Now I'm not sold on the idea of e-books, or electronic books in general (though I am looking forward to electronic paper), however it seems that either the industry is not interested in pushing e-books, or Amazon is not really paying attention (though the list price of the hardcover is $30) OR the publishers are trying to overcharge for the e-book to make up for potential piracy. Am I way off base? Is there anther explanation? Anyone?" It's frustrating to find digital media that is priced higher than the corresponding title in dead-tree form. way0utwest makes a good point in that one reason for the increased pricing is due to piracy, but one has to wonder how often e-Books get pirated? Are such prices justified or are eBooks doomed to failure because they have effectively priced themselves out of the market?

way0utwest asks: "I was searching on Amazon today for Lawrence Lessig's 'The Future of Ideas'. While browsing, I noticed that there was also an e-book version of the same title. What was amazing was that the hardcover copy of the book is $21 and the e-book, which is downloaded, is $24! Now I may be just a simple computer programmer, but it seems to me that there is less overall 'cost' involved with the e-book and it should be cheaper. There's very little 'inventory' to store (how much disk space and electricity cost can there be?). There's no risk of having to 'return' the book to the publisher. There's no labor needed to 'ship' me the book. How can it cost more? Is Adobe charging that much for the licensing of the e-book? Now I'm not sold on the idea of e-books, or electronic books in general (though I am looking forward to electronic paper), however it seems that either the industry is not interested in pushing e-books, or Amazon is not really paying attention (though the list price of the hardcover is $30) OR the publishers are trying to overcharge for the e-book to make up for potential piracy. Am I way off base? Is there anther explanation? Anyone?" It's frustrating to find digital media that is priced higher than the corresponding title in dead-tree form. way0utwest makes a good point in that one reason for the increased pricing is due to piracy, but one has to wonder how often e-Books get pirated? Are such prices justified or are eBooks doomed to failure because they have effectively priced themselves out of the market?

entrox writes: "Paul Graham made his infamous book On Lisp available as PostScript on the web. The book is out of print and the queues for used copies on Amazon are pretty big, so this comes as a godsent for every Lisp programmer and people who would like to take a look at some neat features of Lisp. What sets this book apart is that it doesn't focus on things you could do in other languages, but rather on more extravagant techniques like making the language suit your application and not the other way around."

sofar writes: "Amazon finally makes a profit. Well, only $ 5mln, but maybe you can actually earn something on your stock now. At 1c a share it's no pension fund in Florida yet." I wonder how much of that profit represents 1-click licensing fees.

Music listener and Slashdot author chrisd has prepared a review of the new Nex II CF based mp3 player from Hong Kong based Frontier Labs. He declares it the best MP3 player he's owned, so read the whole review if you'd like to learn more. I have always preferred the Compact Flash memory format. I'm not alone, either. It's always baffled me that the MP3 player market has been dominated by SmartMedia-based players. It's clearly a throwback to the first Rio that Diamond released a few years back (which I still have in a box somewhere in the basement); It's always been a big problem in my mind. I find the SmartMedia format to be too small in capacity and flimsy in packaging to be appropriate for serious music listening or digital photography.

In digital photography, I've pretty much stuck with the CF-based Nikon Coolpix series of digital cameras, so I had scads of CF memory cards lying about. I also have an IBM Microdrive which I use when taking TIFFs using the Nikon. So I wanted an MP3 player able to handle not just Compact Flash, but also the Microdrive. The Microdrive is tricky because it both consumes much more power than solid-state CF cards, but also is slower to respond and larger, demanding the taller CF-II slot.

Until the i2go ego, there wasn't a mp3 player that could handle the Microdrive. I had owned and immediately given away the original, incredibly flawed, RCA Lyra because it simply stank so much I couldn't stand to own the thing. If RCA wants to send one of the new ones, I'd be pleased to check it out, but the shoddy original made me vow never to give RCA more MP3 player money.

The i2go ego (still sold some places, although I think the company that made it is defunct, look look here to see one) wasn't all bad. It played, and it acted as a pretty basic voice recorder, and it allowed for two CF cards to be inserted, at least if you bought a funny daughter board. But its build quality was such that it would spontaneously lose power if jostled. Also, it had the most annoying bug ever: the player would remember the card's contents from before, even if you changed said card's contents. It would try to play them too. It also -- at random --wouldn't notice songs that were on the card. It was very annoying, besides which it was enormous for an MP3 player.

I had been checking out the Nex II for a few months and with a long trip coming up, I decided I needed a MP3 player for the trip. I wanted to have a player that was smartly designed and able to run the microdrive. The Nex II seemed to fit the bill, so I ordered one (with a 256mb card included) for $239 (plus $15 shipping).

It arrived promptly 3 days after order from Frontier Labs' shop in Hong Kong; I've been using it for about a week now, and I have to say it's the best player I've ever owned. The display, an LCD (the letters are not blurry on the actual display) with a blue electro-luminescent backlight, is very readable, and the interface is super easy to use, with a rocker button on the right for track control above the volume buttons and the stop and the "fn" button on the left, under the headphone jack.

Conveniently, the Nex II also acts as a plain vanilla USB drive, so I can upload and download songs (or other files) under Linux with no problem. You can chose from two types of display while the song is playing (status or spectrographic display), which is fun. I stick with the status screen, which shows all pertinent information, including track length, quality in kbps, song title and time elapsed. The player has been able to handle any data rate I've thrown at it, and the specs says it can play WMA files, but I can't verify that. Also, I was able to pass the card to the camera and back with no problem, as neither the nikon nor the player are too controlling of the disk format.

Physically about the size of thick deck of playing cards, the Nex II allows you to change the color of the area around the LCD by sliding in thin colored pieces of glossy paper. You can buy more of these skins for $10, including the unfortunately named "mutant sperm" skin. It also comes with a snappy little neoprene case which has transparent portions covering the LCD and buttons so you can see what's up.

Despite all its good points, the Nex isn't perfect, it lacks some basic features, namely any sort of external power connector. You must always run it with 2 AA batteries. Mind you, it lasts 12 hours when using solid state CF and 5 when using a microdrive, so this is less inconvenient than it sounds. Also, the included headphones are not to my taste at all. The battery cover should be redesigned completely so the latches aren't as flimsy -- every time I change the batteries, I picture scotch tape in my future. Many would probably also like to see it be able to play Ogg Vorbis files, but that wasn't a deal breaker for me.

Another quirk of the Nex II is that to play Microdrives well, you need to load the 1.4(m) firmware available from the FrontierLabs website. It's odd that they didn't make this the default firmware, as the 1.4m firmware seems to work equally well with solid state cards and microdrives, while the firmware it ships with works poorly with microdrives.

So if you're looking for a decent mp3 player, you should check it out. The Nex II is an excellent value, and it sounds terrific.

Muddie writes: "OnVideo.org reminded me that on January 15 , Disney is releasing the "Tron 20th Anniversary Collector's Edition" (1982) on DVD and VHS. Directed by Steven Lisberger, the film stars Jeff Bridges, Bruce Boxleitner and Barnard Hughes. The 2 disc DVD set contains the remastered film with commentary by Lisberger, producer Donald Kushner and visual effects supervisors Harrison Ellenshaw and Richard Taylor, a new 75-minute "making-of" documentary "The Making of Tron", deleted scenes, original soundtrack music deleted from the film and more all for $29.99. Check out all the happy details at Amazon's link"

WalterGR asks: "There are plenty of resources available for writing operating systems, e.g. Tanenbaum's Modern Operating Systems, the Dinosaur Book, and countless web sites. For those of us who aren't interested in low-level issues, and prefer focusing on human-computer interaction, what resources are available for designing windowing systems (a la X Window)? Issues like the object hierarchy, event management, modularity, redefining behavior at runtime (e.g. for skins) etc. Any suggestions?"

alen asks: "I'm in the market for an MP3 player. I've been looking at various models and they all seem to be SDMI ready or compliant. Looking at customer reviews on Amazon confirms this as you'll find at least one person saying you can't transfer the music from the MP3 player to your PC. At least on the newer players you do." I've been resisting the urge to get an MP3 player for precisely this reason, opting to use my laptop and a cassette adaptor for those long driving trips, but this is hardly affordable or efficient. Handhelds might work, but memory is a problem here. Are there any players out there that haven't forgotten the "fair" part in "fair-use"?

"So far I have narrowed my search to 3 choices. I want it to sound very good and be able to play music encoded at 128kb or higher.

The Rio Volt 250 is a CD based player so the SDMI thing doesn't really apply. The Creative Labs Nomad II" proudly displays this as a feature. The Samsung Yepp doesn't use SDMI, but something called SecuMax as stated in the Nomad II technical specs on Amazon. And this little tid bit on the Samsung Yepp homepage confirms that SecuMax is just like SDMI.

Now I'm not looking to download any illegal music from the Internet. I simply want to listen to my CD collection on the train to work or while working out. And there is freely downloadable music out there. If I were to download a song at work or a friend's house, put it in my MP3 player I then wouldn't be able to transfer it back to my PC at home to add to my collection. Where is 'fair use' when the artist is giving away their music for free? And I don't have the link, but what of the recent surges in so called 'secure' CD's that one can't rip into MP3's? Where is the 'fair use' there? Or are we supposed to purchase multiple copies of the same music in different formats?"

alen asks: "I'm in the market for an MP3 player. I've been looking at various models and they all seem to be SDMI ready or compliant. Looking at customer reviews on Amazon confirms this as you'll find at least one person saying you can't transfer the music from the MP3 player to your PC. At least on the newer players you do." I've been resisting the urge to get an MP3 player for precisely this reason, opting to use my laptop and a cassette adaptor for those long driving trips, but this is hardly affordable or efficient. Handhelds might work, but memory is a problem here. Are there any players out there that haven't forgotten the "fair" part in "fair-use"?

"So far I have narrowed my search to 3 choices. I want it to sound very good and be able to play music encoded at 128kb or higher.

The Rio Volt 250 is a CD based player so the SDMI thing doesn't really apply. The Creative Labs Nomad II" proudly displays this as a feature. The Samsung Yepp doesn't use SDMI, but something called SecuMax as stated in the Nomad II technical specs on Amazon. And this little tid bit on the Samsung Yepp homepage confirms that SecuMax is just like SDMI.

Now I'm not looking to download any illegal music from the Internet. I simply want to listen to my CD collection on the train to work or while working out. And there is freely downloadable music out there. If I were to download a song at work or a friend's house, put it in my MP3 player I then wouldn't be able to transfer it back to my PC at home to add to my collection. Where is 'fair use' when the artist is giving away their music for free? And I don't have the link, but what of the recent surges in so called 'secure' CD's that one can't rip into MP3's? Where is the 'fair use' there? Or are we supposed to purchase multiple copies of the same music in different formats?"

Kent M. Pitman has already given you his first 11 answers to the questions you asked him about Lisp, Scheme, the creation of programming standards, and much more -- below are his answers to another eight (starting with answer #12). Thanks again, Kent.

12) Good texts for learning Scheme?
by drenehtsral

I have recently been working on learning Scheme in my spare time, with the eventual goal of writing a scheme based scripting system to run the guts of a massive adventure game/graphical mud sort of system, everything from environment simulation (predator/prey cycles, etc...) to 3d models (i.e. models will be geometry glued together by scripts so you could have trees that by a random seed and a growth level variable have grown over time and are unique to provide interresting landscape features). Scheme is appealing because it's simple, powerful, and adapts well to the idea of a threaded interpreter.

To further my goal of learning Scheme inside and out, I've been reading "The Little Schemer," as well as "Structure and Interpretation of Computer Programs." Do you have any other recommendations for good Scheme programming texts?

Kent M. Pitman: You can get a list of textbooks from Schemers website. If you can articulate a particular need or preference that you think should help narrow down the many available choices, I'd suggest posting a more specific inquiry to the comp.lang.scheme newsgroup.

13) Overlooked practical aspects of Lisp
by hding

Why do you think that people so often overlook many of the wonderful things in Common Lisp such as unwind-protect, the whole condition system (which you are of course closely associated with), and so on - things that make it very useful for day-to-day programming, and are there any such things that you'd particularly highlight, or conversely that you wish had become part of the standard but did not.

Incidentally, thank you for all of the insight so generously and regularly poured forth in comp.lang.lisp.

KMP: Well, people program with tools that are familiar to them. Unless Common Lisp is someone's first language, it'd be easy for them to overlook the things it contains that are not like the things they're familiar with. There's a certain irony here because often the reason people will leave a language for another language is that they've reached the limits of what they can do with the first language and they need more power. So you'd expect that they'd aggressively look for features of the new language that were different than the things they've used before. And probably some do. But you're right that others cling to the safety and familiarity of the operators they could just as well have found in the old language they left behind, and so in the process they miss out on what the language can offer them.

Fortunately, unwind-protect is finally (pardon the pun) present in Java. And some hints of the Common Lisp condition system made it into Java as well. So probably people who come to Common Lisp from Java will be inclined to seek out those capabilities. But there's a lot of other stuff there and I hope new users will indulge their curiosity and take the time to explore.

As to what we should have in the language, the main omission of note is some sort of system definition tool (the in-Lisp analog of make). It was a shame that we did a feature-freeze on ANSI Common Lisp in 1988 but didn't get the standard out until 1994, and the suggestion of including such a tool didn't come until the after-freeze period. All vendors offer such a facility, but programs would be more portable if there were a uniform solution.

There are also quite a number of things about Common Lisp that are available in the same or similar forms in nearly all implementations. Multi-tasking, sockets, database access, external function call, windowing, and so on. It wouldn't be bad to have included any of these, but the fact is that they weren't ready for standarization in 1988. At this point, though, I think other mechanisms than standards are the right way to proceed.

The Lisp community used to expect the delivery mechanism for new functionality to be a new language spec. But that requires working through consensus standards bodies. The problem is that, by their nature, standards bodies are synchronization mechanisms. The problem with synchronization mechanisms in a massively parallel world is that they slow things down. The world is not going to wait for us to slow down, so I think we need to evolve mechanisms that will keep up better with a degree of pace that is externally dictated.

I think this is an area where Lisp as a community has been slow to respond. There need to be community mechanisms for sharing the many great commercial and private packages people have been creating in Lisp, so that we can properly reap the cross-product benefits of our community's productivity. I see evidence that this is changing. The Common Lisp Open Code Collection (CLOCC) is one such mechanism that addresses open source code. I'd like to see similar mechanisms arise for the exchange of proprietary products as well.

As to my posts on the comp.lang.lisp newsgroup, thank you. I'm glad you enjoy them. Frankly, I always consider it a victory to hear I haven't bored everyone to death. In background I've been working on putting together several books on Lisp, but one never quite knows if one will finish such things. I regard comp.lang.lisp as a kind of insurance policy, assuring that at least some piece of what I have seen and done in my career gets transferred from individual memory to global group memory.

I think preserving individual experiences for history is quite important. In the future, this will happen naturally due to logs kept by online collaboration tools. But I'm especially worried about the records of what happened between about 1960 (the birth of programming languages) and 1994 (the birth of the web). Most of everything in that time range is recorded on paper and will eventually be lost. Looking back from the future, I expect it to be as confusing to figure out how the information society was born as it is to look back in a telescope to see the birth of the Universe. You'll get very close, but then you'll get to a point where you can see nothing. The informational big bang. I've been working on webbing all of my old hardcopy papers, and I hope others of that era will commit to doing the same.

14) Lisp - Scheme - ML
by Tom7

I know a lot of big academic (erstwhile) lisp shops, such as CMU, have transitioned away from lisp to ML [standardml.org] and relatives [inria.fr]. Some of the reasons we might give are:

• Sophisticated type systems, catching most bugs before your program is run, ensuring safety, etc.
• Much more efficient (http://www.bagley.org/~doug/shootout/craps.shtml), partly due to compilation strategies using types
• Increased modularity and abstraction
• Pattern matching, (subjectively) more natural syntax

In fact, I'm one of those people. I've been scoffed at by lisp fans, but most had never used ML. But I have an open mind, so, in the face of more "modern" languages, what advantages do lisp and scheme offer? Do you think that these advantages are fundamentally impossible to achieve in a typed setting?

KMP: First, I assume by "typed" you mean "statically typed." I think of Lisp as "dynamically typed." I think of most machine languages as "untyped." I've heard statically typed languages sometimes called strongly typed, and I sometimes use this terminology myself out of habit, but I've grown to dislike it because it seems to me that the issue of strength ought to refer to whether you check types, not when you do. The terms "static" and "dynamic" seem to me to better get to the heart of the matter.

To quote Abraham Lincoln, admittedly somewhat out of context, "People who like this sort of thing will find this the sort of thing they like." So to somewhat flippantly re-interpret Lincoln's remarks in a modern context, applying perhaps just a bit of obligatory political spin to the result: The fact that functional languages appeal to people who like functional languages is not a proof that functional languages are of general purpose appeal.

I think the real reason that CMU (or any university with a grant-based funding model) changed its direction is good sources of funding in research depend on saying you're doing something "new and different." Such a shift doesn't imply that the thing left behind wasn't "tried and true," but only that "tried and true" is not what gets research dollars. Research must constantly stir the mix, but that doesn't imply obsolescence to what came before. So don't read too much into that.

Answering each of your points in detail might require a whole article, but I'll touch on each in brief:

• Sophisticated type systems, catching most bugs before your program is run, ensuring safety, etc. Much more efficient partly due to compilation strategies using types.

  Actually, it's funny that you both mention the CMU project and then make this comment. Before moving away from Common Lisp, the CMU crowd was successful in demonstrating to the Lisp community's satisfaction that there were enormous opportunities offered by the Common Lisp language design in terms of type inferencing that still today go untapped by implementations. This is really a market issue, not a language design issue. The fact is that although other languages do a lot more type inferencing, vendors are not getting huge numbers of bug reports saying that better type inferencing is what stands between programmers and the commercial success of their product. Over time, I think you'll see more and more interesting type analysis done, but such work is always balanced against other needs of users, such as CORBA, COM, RMI, and web interfaces, for example, such as UI toolkits and debugging options. When I observe, as I often do, that languages are political parties, this is what I mean. They are each responsive not to the needs of the world, but to the needs of their constituencies. And the Lisp constituency, while it is not oblivious to the value of type inferencing, does not see that issue as its number one priority.

• Increased modularity and abstraction.

  This is quite a multidimensional space. I think Lisp provides great opportunities for modularity and abstraction that other languages do not. And yet, there are sometimes things I can't abstract as well as I wish. An example of a minor omission: Common Lisp's CLOS doesn't do protocol abstraction as well as Zetalisp's New Flavors; among other things, one can't declare that certain unimplemented methods are required. But with the use of the macro system and the Meta-Object Protocol (MOP), one can add this kind of thing. Further, the package system is missing certain kinds of inheritance capabilities I've often wished for, but I recently sat down and did the work of writing my own versions of defpackage for my own use, adding the capabilities I wanted in a way that my own tools can use, and I had no difficulty. For the most part, I've found the limitations of Common Lisp's abstraction capabilites to be incidental, and not deep, and I've found its syntactic reorganization capabilities more than capable of making up for it.

• Pattern matching.

  I think you're right that Lisp doesn't do pattern matching. Whether or not that's a good or bad thing is subjective. I think there are people who like pattern matching and people who don't. In fairness to Lisp, though, on the few occasions in my career where I've felt a strong need for pattern matching, I've been able to implement it easily. And, importantly, Lisp's syntactic adaptability has allowed me to make my personal implementation look as natural in the programs I write as if it were natively provided by the language; most other languages don't give me the syntactic control to be able to add new functionality in a way that feels appropriate to the language. So personally, I don't find this a strong negative; rather, I see it as an opportunity for you to create a layered library that supports the needs of yourself and others like you.

• (Subjectively) more natural syntax.

  I don't think you can make the case that much of any language has "natural" syntax. COBOL and HyperTalk gave this the fairest shot and there's a big difference even between them and any natural language. I personally find Lisp syntax remarkably natural in that it focuses on symbols that you could say out loud, marking them minimally to indicate grouping. Other languages contain lots of special-purpose markers like commas, semicolons, asterisks, and braces/brackets/parens that are used in quite nitpicky ways. All this to say that you're right on this one: it's subjective. And as such, I hope I can fairly dismiss this as an even draw.

15) Lisp in Mathematics Programming
by An Anonymous Coward

Gregory Chaitin has a book called "The Limits of Mathematics." In it he claims that mathematicians should love Lisp because Lisp is basically set theory, and all mathematicians love set theory. I wholeheartedly agree with this, one only needs to look at Chaitin's Lisp programs to realize how quickly and succinctly one can arrive at astonishing incompleteness results in mathematics. So we know Lisp is great for stuff like this, really researching a mathematical subject. Do you see Lisp continuing in this direction, showing and discovering theorems, or will it move into industry? Or has it moved into industry, and we just don't know it? Do the likes of NASA and JPL use Lisp and Scheme religiously? I would bet so.

KMP: Lisp may have started out as a way of addressing abstract topics like math (logic, calculus, prime numbers, etc.) and artificial intelligence, but it long ago made the transition to commercial applications. Both Scheme and Common Lisp have been and continue to be used in real-world applications that might surprise you. These include (but are certainly not limited to) applications in airline scheduling, commercial database manipulation, computer operating systems, bioengineering, web services, document format translation, and, yes, even space exploration. Franz, Inc. has created quite a nice page of Lisp success stories that I think expand on this much better than I could in the space I've allowed myself to answer this question. And speaking of NASA/JPL, they did a comparative study of Lisp vs Java and C++ that some might find interesting.

16) Scheme in CS
by An Anonymous Coward

It seems many of the more popular CS programs in the world use Scheme as a teaching language. A lot of times, students complain about this, saying they'd prefer to learn about C or another language that is considered "apt for industry." I used to be like this too, but have now discovered the error of my thinking. How have you convinced others that while the latest programs might not be written in Scheme, that it is worth a student's time to learn Scheme. Many seem stuck to the point that if they won't use it outside of school, they shouldn't learn it. How can we convince them otherwise, to become scholarly citizens instead of drones?

KMP: I think the thing to explain to a student is that the world is ever changing and that one cannot put ones eggs all in one basket. Furthermore, modern environments are often quite heterogeneous, with different languages and systems being used together cooperatively. Especially for a CS student, who often has the luxury of time that a person in the job world does not, I think it's worth taking time to learn as many different languages as possible. This not only exposes the students to alternate ways of thinking, but it also prepares the student to quickly change modes of thought or languages of expression later. Once on the job, one often can't afford the ramp-up time to learn a new language at the point it becomes necessary to use. Better to already know it and just have to "brush up".

One is much more likely to consider alternative approaches if one has a sense of what is involved in them; it's very easy to fear the unknown, even when the unknown might be of great help. So get to know as many things as you can while you can. Common Lisp and Scheme, which I regard as two very different languages, by the way, should definitely be among the things every student studies. But they should not be the only things the person studies. Like it or not, there is a lot the professional programmer needs to know to be really successful not just tomorrow, but for a lifetime.

As Oliver Wendell Holmes is often quoted as saying, "A mind stretched to a new idea never returns to its original dimensions." In order to stretch a student's mind, I recommend they make a list of "kinds of languages" and then learn as many different kinds as they can. Here are some that come to mind, though I'm sure others with different experience than me might reasonably contribute still others.

• A block-structured language, such as Algol or Pascal or Scheme.
• A line-oriented language, such as Fortran or BASIC.
• A rule-based logic language, such as Prolog or EMYCIN.
• An Englishy language such as HyperTalk or Cobol.
• A "stack" language such as PostScript.
• A "line noise" language (heavy emphasis on one-letter operators) like APL or Teco.
• A dynamic object-oriented language, such as Common Lisp or Smalltalk .
• A strongly-typed, statically analyzed language such as ML or Haskell.
• A dynamically-typed functional programming language, such as Scheme.
• A string or macro processing language, such as Perl or m4 or TeX or Teco.
• A database access language, such as SQL.
• An abstract high-level, assembly language, such as Java.
• A concrete high-level, assembly language, such as C.
• A low-level, traditional assembly language.
• A scripting language, such as Javascript.
• An interface-definition language such as Visual Basic, HyperTalk, or Javascript.
• A document-structuring language such as XSL or TeX.
• A language with a modern error system, such as Common Lisp or Dylan.
• A reflective/introspective language such as Common Lisp or Java.
• A symbolic programming language, such as Common Lisp or Scheme.
• A security-oriented language, such as Java or MOO.
• A language where both programs and data are fully persistent, such as MOO or HyperTalk.

I'm confident that if people make a sincere effort to learn each of these kinds of languages on their own terms, the Lisp community will get its share of converts. But further, I would hope that the people who come to the Lisp community bring with them the ideas of other communities so that we can incorporate, rather than hide from, the good ideas that we need in order to continually be moving forward.

17) A question for Kent
by MarkusQ

Do you have a maclisp manual I could borrow?

KMP:For those not familiar with Maclisp, it's a defunct dialect of Lisp that predated and strongly influenced the design of Common Lisp.

I've been working on webbing The Revised Maclisp Manual, which I had published on paper back in the early 1980's. It's not quite ready to go out yet, but should finally be ready sometime in the not terribly distant future. Probably a month or two. Watch the site maclisp.info for more information.

18) Open Implementations
by Martin Pomije

What is your opinion of the idea of Open Implementations from Gregor Kiczales? Do you think that his idea could help Lisp be more widely used?

You can see him giving a lecture about this idea here. [microsoft.com] The video is only available in Windows Media format on this site.

KMP: I hadn't seen Gregor Kiczales's talk on Open Implementations, so I enjoyed watching it. Thanks for the pointer!

The talk made me think back to various related ideas I've seen batted around for a long time, the earliest of which that I can recall is a short paper on something called "Capsules" (an object system where classes were allowed to have multiple implementations) by Richard Zippel back in the late 1970s or early 1980s at MIT. Often, especially in a university environment, people will make up such a concept, bat it around for a bit, and then go on to something else. There are some very interesting ideas there and I'm glad to see that they're being pursued seriously, especially by someone as thoughtful and talented as I know Gregor to be.

As a formalized area of study, this topic of "aspect-oriented programming" is new to me. It reuses some old ideas in new ways, and introduces some new ones along with it. I'm only just barely becoming conversant in the terminology, so I can't really speak to it from a theoretical point of view. But it looks promising. And from a practical point of view, I can note that I'm getting daily on-the-job training in it through my consulting relationship with The Software Smith. They're using Lisp as a vehicle to apply the principles of aspect-oriented programming, and the results they get are quite spectacular.

19) What was up with CLisp's "loop" form?
by Jayson

Did you can have anything to do or know who had anything to do with the "loop" form in Common Lisp? Why does it look and feel just like a FOR loop on C (from the Graham book):

(loop for x = 8 then (/x 2)
until (< x 1)
do (princ x))

This is one of by biggest minor nags about CLisp and I am very curious what was going through the committee's collective head. Didn't anybody balk at this enough to at least get the syntax cleaned up?

KMP: The example you cite is quite simplistic and if this were the only reason for using LOOP, we wouldn't have it. Lisp has a number of other iteration operators for doing simple loops like this. However, the reason for using LOOP is that it can represent much more complicated arrangements of iteration paths and collection techniques. I used to grumble a lot myself about how "un-Lispy" LOOP seemed, but over time I come to the belief that the benefits outweigh the costs. A loop like this:

(loop for x from 0
for y in some-list
when (good-result? y)
collect (list x y))

is easy to write and maintain, and much easier to explain than the equivalent, but more Lispy:

(do ((x 0 (+ x 1))
(y-list some-list (cdr y-list))
(result '()))
((null y)
(nreverse result))
(let ((y (first y-list)))
(when (good-result? y)
(push (list x y) result))))

The Common Lisp community likes to offer the traditional Lispy notations for places where they enhance readability, but we also offer alternative notations for situations where we've learned there's a call for it. We leave the choice of which style to use up to the individual taste of the programmer. Common Lisp is not a minimalist language offering only one way to do things or rigidly attempting to force people into a single programming paradigm.

By the way, this is a fundamental difference between the ANSI Common Lisp design philosophy and the Scheme design philosophy. The introduction to the Scheme specification states:

Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary. Scheme demonstrates that a very small number of rules for forming expressions, with no restrictions on how they are composed, suffice to form a practical and efficient programming language that is flexible enough to support most of the major programming paradigms in use today.

By contrast, the charter for X3J13, the group that designed ANSI Common Lisp, stated the following in the X3J13 charter:

It will codify existing practice, provide additional features to facilitate portability of code among diverse implementations, and establish normative Common Lisp programming practice. The committee will begin with the language described in Common Lisp: The Language by Guy L. Steele Jr. (Digital Press, 1984), which is the current de facto standard for Common Lisp. Whenever there is a proposal for the standard to differ from Common Lisp: The Language, the committee shall weigh both future costs of adopting (or not adopting) a change and costs of conversion of existing code. Aesthetic criteria shall be a subordinate consideration.

In other words, the Scheme community is a very conservative community that is highly focused on keeping its language specification as highly aesthetic and minimal in size as possible. By contrast, the Common Lisp community is an industrial standard that is concerned with messier issues of compatibility, portability, and commercial need; while the Common Lisp community cares about aesthetics, it does not allow aesthetics to dominate practicality as a design criterion.

The relevance of this here is that the Lisp family of languages is made up of a number of smaller communities who share a few core ideas, but really have some very divergent points of view. Each is worthy of study in its own right. One should not, having looked at Scheme, assume they have good intuitions about Common Lisp, nor vice versa.

Steve MacLaughlin wrote this review of Web ReDesign: Workflow that Works , a book which transcends its title to address much more than workflow, and more generally than just on the Web. Steve promises that your copy will soon be tattered and marked -- and that's a good thing. Web ReDesign: Workflow that Works author Kelly Goto & Emily Cotler pages 253 publisher New Riders Publishing rating 9 reviewer Steve MacLaughlin ISBN 0735710627 summary Practical wisdom for Web creators on consulting, design, development and more rolled into a single readable volume.

There are books that attempt to impart the divine wisdom of consulting. There are books that detail best practices in graphic and usability design. There are books that detail the intricacies of software development. There are books that detail project management and surviving the technology lifecycle. But there are very few books that explain how all of these pieces work together successfully. Kelly Goto and Emily Cotler have pulled it off with masterful perfection in their new book Web ReDesign: Workflow that Works.

People, projects, technology, and clients do not work in a vacuum from one another. Process is the magnet that holds them all together. Goto and Cotler offer professionals a comprehensive "Core Process" to guide them through their Web projects. While other books may explain some of the tricks of the trade no book has really placed all of these best practices under the umbrella of a process or methodology. Perhaps that's because a lot of these processes have been closely guarded secrets in the highly competitive interactive services industry. It's almost as if Goto and Cotler are on a humanitarian mission to save clients and projects from future punishment under the hands of companies using poor or in some cases no processes at all.

Web ReDesign's Core Process is a five-step approach to producing successful Web projects. The five steps are Defining the Project, Developing Site Structure, Visual Design & Testing, Production & QA, and Launch & Beyond. And each phase is broken down further into steps and checkpoints in splendid detail. As someone who started out doing this kind of work I found myself making mental checkmarks throughout the book. "Did that. Did something like that. Man, it took me years to learn that I should do that. Where was this book six years ago when I needed it?"

Perhaps a book like this wasn't really possible until now. The profession had to go through its ugly duckling stages where individuals and companies tried to figure out what worked and what didn't. Grafting parts from consulting, marketing, project management, and software development into some freakish process monster that often resulted in turning clients into an angry torch-carrying mob. Thankfully Web ReDesign has finally arrived and it is certainly no Bride of Frankenstein. The processes are spelled out in clear language and the authors repeat certain key points in case you missed something along the way.

It's easy to get sidetracked reading Web ReDesign with all the sidebars, charts, sample forms, and interviews. But this is a good thing! The tips and sidebars along the way spell out in greater detail how to put the process into action, and what to do when trouble arises. The forms and charts are some of the most thorough ever published, and thankfully you can download most of them on the companion website located at www.web-redesign.com. Throughout the book Goto and Cotler call on experts like Lynda Weinman, David Siegel, Jeffrey Zeldman, and Jakob Nielsen to offer their perspective on a given topic. The overall design and layout work done by the folks at New Riders is phenomenal and the visual presentation of the book is really first rate.

The one big question I have about the books is its title: Web ReDesign. That's because this is a book that can be used for first time Internet initiatives just as well as for redesign projects. Perhaps the authors had some dual purpose in mind for the title: If you're doing this for the first time, you need to rethink the conventional wisdom that Web projects are a black art with no best practices. Or if you didn't use a process the first time, then you've probably learned how valuable it is to have a proven methodology to avoid repeating mistakes.

Goto and Cotler have produced a book that no Web professional, whether they're a consultant, project manager, designer, programmer, or specialist, should be without. Web ReDesign is one of those books that should be kept close at hand during projects of all shapes and sizes. It won't take long before your copy is either severely dog-eared or has post-it flags sticking up throughout it. Get your hands on a copy before the competition does.

You can purchase this book at Fatbrain. Have your own book review to contribute? Check out the book review guidelines, then write away!

Steve MacLaughlin wrote this review of Web ReDesign: Workflow that Works , a book which transcends its title to address much more than workflow, and more generally than just on the Web. Steve promises that your copy will soon be tattered and marked -- and that's a good thing. Web ReDesign: Workflow that Works author Kelly Goto & Emily Cotler pages 253 publisher New Riders Publishing rating 9 reviewer Steve MacLaughlin ISBN 0735710627 summary Practical wisdom for Web creators on consulting, design, development and more rolled into a single readable volume.

There are books that attempt to impart the divine wisdom of consulting. There are books that detail best practices in graphic and usability design. There are books that detail the intricacies of software development. There are books that detail project management and surviving the technology lifecycle. But there are very few books that explain how all of these pieces work together successfully. Kelly Goto and Emily Cotler have pulled it off with masterful perfection in their new book Web ReDesign: Workflow that Works.

People, projects, technology, and clients do not work in a vacuum from one another. Process is the magnet that holds them all together. Goto and Cotler offer professionals a comprehensive "Core Process" to guide them through their Web projects. While other books may explain some of the tricks of the trade no book has really placed all of these best practices under the umbrella of a process or methodology. Perhaps that's because a lot of these processes have been closely guarded secrets in the highly competitive interactive services industry. It's almost as if Goto and Cotler are on a humanitarian mission to save clients and projects from future punishment under the hands of companies using poor or in some cases no processes at all.

Web ReDesign's Core Process is a five-step approach to producing successful Web projects. The five steps are Defining the Project, Developing Site Structure, Visual Design & Testing, Production & QA, and Launch & Beyond. And each phase is broken down further into steps and checkpoints in splendid detail. As someone who started out doing this kind of work I found myself making mental checkmarks throughout the book. "Did that. Did something like that. Man, it took me years to learn that I should do that. Where was this book six years ago when I needed it?"

Perhaps a book like this wasn't really possible until now. The profession had to go through its ugly duckling stages where individuals and companies tried to figure out what worked and what didn't. Grafting parts from consulting, marketing, project management, and software development into some freakish process monster that often resulted in turning clients into an angry torch-carrying mob. Thankfully Web ReDesign has finally arrived and it is certainly no Bride of Frankenstein. The processes are spelled out in clear language and the authors repeat certain key points in case you missed something along the way.

It's easy to get sidetracked reading Web ReDesign with all the sidebars, charts, sample forms, and interviews. But this is a good thing! The tips and sidebars along the way spell out in greater detail how to put the process into action, and what to do when trouble arises. The forms and charts are some of the most thorough ever published, and thankfully you can download most of them on the companion website located at www.web-redesign.com. Throughout the book Goto and Cotler call on experts like Lynda Weinman, David Siegel, Jeffrey Zeldman, and Jakob Nielsen to offer their perspective on a given topic. The overall design and layout work done by the folks at New Riders is phenomenal and the visual presentation of the book is really first rate.

The one big question I have about the books is its title: Web ReDesign. That's because this is a book that can be used for first time Internet initiatives just as well as for redesign projects. Perhaps the authors had some dual purpose in mind for the title: If you're doing this for the first time, you need to rethink the conventional wisdom that Web projects are a black art with no best practices. Or if you didn't use a process the first time, then you've probably learned how valuable it is to have a proven methodology to avoid repeating mistakes.

Goto and Cotler have produced a book that no Web professional, whether they're a consultant, project manager, designer, programmer, or specialist, should be without. Web ReDesign is one of those books that should be kept close at hand during projects of all shapes and sizes. It won't take long before your copy is either severely dog-eared or has post-it flags sticking up throughout it. Get your hands on a copy before the competition does.

You can purchase this book at Fatbrain. Have your own book review to contribute? Check out the book review guidelines, then write away!

Captain_Frisk asks: "My buddy and I have recently received approval to teach a programming course at our Alma Mater. We have pretty much free reign over what we teach, so we've elected to teach 'An Introduction to Object Oriented Programming,' to fill a void at a school where the only programming languages taught are C and Matlab. Can anyone out there recommend some good books for the course, not just for the students, but for us to read as preparation material? We've never taught a class before, and as graduates of this school, we've never had any formal training in OOP. I read a few books at work a few years back, but I don't remember their names, nor did they strike me as particularly memorable. So far I've looked at An Introduction to Object-Oriented Programming and Object-Oriented Software Construction, 2nd Edition (a book reviewed at Slashdot 3 years ago), but have not invested in either."

Captain_Frisk asks: "My buddy and I have recently received approval to teach a programming course at our Alma Mater. We have pretty much free reign over what we teach, so we've elected to teach 'An Introduction to Object Oriented Programming,' to fill a void at a school where the only programming languages taught are C and Matlab. Can anyone out there recommend some good books for the course, not just for the students, but for us to read as preparation material? We've never taught a class before, and as graduates of this school, we've never had any formal training in OOP. I read a few books at work a few years back, but I don't remember their names, nor did they strike me as particularly memorable. So far I've looked at An Introduction to Object-Oriented Programming and Object-Oriented Software Construction, 2nd Edition (a book reviewed at Slashdot 3 years ago), but have not invested in either."

There's been lots more happening today - arrests and suspect taken from the Westin Hotel in Boston, as well as the Park Hotel in Newton, MA, which is right down the road for me. There's been some thoughtful submissons about people saving the feeds on their [PVR]s, so that the moment isn't lost in time. NATO has invoked Article 5, meaning that for first in history, I believe, the mutual defense clause has been activated. More news included below. Scott Laird writes "We've received notice that our network facilities in NYC are going to run out of Diesel in ~2 hours, and there's no way to get more diesel to them until lower manhattan is opened up. Since we're located in the same facilties as most of the other major network providers in Manhattan, odds are there are going to be a lot of things dropping off the air this afternoon."

ELBnet writes It would be a godsend if the various survivor registries would pool their data, or if someone sets up a google-like search engine to reach all of them at once - and that is a great idea. I set up the search engine at WWW.ELBnet.com/wtc but need URLs to populate it. Please e-mail me any suggested URLS and I'll add them.

Also please don't /. the site... let the people who need it get to it. Spread the word."

Radio Free Wazee writes "Radio Free Wazee has suspended its normal programming in order to provide a relay for National Public Radio. Most of the sites are slammed -- we've got room for about 320 listeners. You'll need an MP3 player (WinAMP, etc.) -- the stream is at http://live.str3am.com:2310/listen.pls Our web site is http://www.ideashot.com/wazee.org Howard @ radio free waee"

GatorMan writes "The Red Cross and Amazon.com have setup a donations page for disaster relief to aide in the recovery of our people. I've seen it jump $100,000 in an hour (thanks to my $10 I'm sure) with over 25,000 donations so far, very promising. No where else on Earth could you find support like this."

winksmith writes "as many of us look on the recent crashes in horror, we will also be pushed towards more tech solutions to some of the scenarios witnessed. i believe experts agree that the buildings may have stood up to forces of the crash had it not been for the very hot fuel burning w/i the building. the building themselves were designed to take aircraft impacts (albeit circa 1960 aircraft). this disaster may spark re-interest in fuel additives for jet fuel that would immediately put out fires upon impact.

the faa and nasa ran some very extensive tests including the purposeful crashing of a large boeing jet (B720) in december of 1984. the tests were not encouraging. details are available. figure 1-1 shows the jet crashing.

no one can second guess what would have happened, but perhaps continued research into this area might have played a role in saving a few more lives. and still may in the future."

Wiggins writes ""The Internet Fraud Complaint Center recently received several complaints that someone is using the letters, "FBI" or "fbi.gov" in an e-mail address in order to make it seem that the message is coming from an FBI employee. In several cases, the message said, "Your application is approved. Please fill out this form to confirm your identity" and solicited the person's name, address, credit card number and expiration date." More on the http://www.ifccfbi.gov/. I am sure /. users know better, but the general populace doesn't (always)."

Further news of the events going on around the world following the attacks earlier today on New York and Washington. To follow things even more closely, you are encouraged to join realtime CNN coverage in channel #cnn_newsfeed on irc.idlenet.org. (Doubtless there are other similar IRC and IM feeds going on -- please post them in comments.) In addition to the news below, note that CNN has reported that multiple suspects were arrested with a van loaded with explosives in the vicinity of New York's George Washington Bridge. Update: 09/12 04:29 AM GMT by T : Many readers have reported that the van in question was found not to contain explosives, though its occupants were held for questioning. And Giacomo DiGrigoli, international product manager at PayPal.com, wrote with word of a donation fund on the PayPal website where folks can make donations to the American Red Cross.

Contradicting earlier reports, reader Adam Brookman writes: "I can guarantee that no car bomb went off in front of the State Dept. in DC. My father is part of the critical personel at State dept. When I read that I called him. He said he heard the same thing and he also heard that the building was hit by a plane, but neither were true."

Worth reading is this analysis of the motives and some possible suspects in today's violence, at Jane's International Security News. They've picked three plausible attackers. Motive aside, Jack Bryar has a convincing take on who is really most hurt by the attacks today.

babyruth writes: "amazon.com has a Red Cross Relief fund set up on their homepage, where you can contribute online. Only several hundred have contributed so far, let the power of /. help!" Iridium provides a link straight to the donations page, noting that "All standard fees are waived -- all proceeds go directly to the Red Cross." Of course, the Red Cross is -still- in desperate need of blood. If you can donate, please call 1-800-HELP-NOW to find the donation center nearest to you.

iggyflashbulb writes: "CNN reports some oddball group not associated with bin Laden is attacking Kabul at night. Are they taking advantage of the NY situation or did they create it?"

An anonymous reader writes: "Following the sad (and outrageous) mess of these terrorist attacks, results are already starting to impact the country. When a RSM failed on one of our 5500 Ciscos, we recieved the following notice

'Due to a national emergency completion of your case, delivery of your parts or engineer will be delayed until further notice. Several areas of the country have restricted transportation and currently no air traffic is available. Cisco will notify you as soon a we are able to dispatch your order.'

There doesn't seem to any information on Cisco's site."

CERT is in action as well: SilentTone writes: "Ween Hall at Carnegie-Mellon University was evacuated today so the the Computer Emergency Response Team could go into action."

Many readers have been assembling mirrors for the overloaded news sites of the world. Jon Anhold writes: "I've compiled more photos and what not, mirrored many of the sites around to help the load. They're available here: http://ziggy.dreamland.net/wtc/"

Owen Bossola writes: "This is a simple webpage I put up with shots I took all day of the World Trade Center. I go to school across the river at Stevens Institute of Technology and I watched the whole thing from campus. It is absolutely nuts, I'm looking out my window and for the first time, downtown NYC is dark, and there aren't two large buildings gleaming back at me."

rhyder writes: "I was last in the World Trade Center and the attached World Financial Center on Saturday evening. Many people I know work in those buildings, even more live and work in the shadow of those 2 towers.

From the Port Authority of NY and NJ:

1. The Port Authority
   
2. Trade Center Concourse Level Map
   
3. Trade Center Plaza Level Map
   
4. Trade Center Complex Overview
   
5. Area Map showing southern tip of Manhattan and the Trade Center location."

An Anonymous Coward seeks more information about an interview that Washington area readers may be able to provide: He writes: "Fox News channel 5 (local around 6:30ish E.S.T) this evening had an interview with a witness about what he saw at the Pentagon the moment of impact. His interview was the basic 'I was in my car looked to my side..blah blah' but then he said something totally unexpected. He observed a second airplane immediately swing behind the first in a follow like manner and swoop down on the Pentagon only to pull up at the last second, out of the smoke cloud, and fly away. His description of the plane was pretty detailed, saying it was propeller-driven ... He stated everyone around him who were also outside their cars saw the SECOND Airplane following the first and it was also going in."

Anyone else able to confirm this rumor?

Jon Bishop asks: "Why Today? Why did this attack happen on September 11, 2001. Here is a guess. I played with the date commonly used for programming. YYYYMMDD returns 20010911. 911...in 2001. Is this play on numbers intentional or coincidence?" It may be significant that the anniversary of a Congressional resolution "favoring a Jewish homeland in Palestine" falls on this date. Then again, if you go back a century or two, you may find a lot of anniversaries that seem just as significant.

Carl Merritt writes: "Since many sites seem to be creaking under the load today I've dumped every relevant picture and video I can find onto my server, please feel free to suck up some of my unused bandwidth with downloads or links: http://www.binaryvista.com/WTC/ I'll probably leave it up for a couple weeks, or until CNN asks me to remove their pictures ;-)."

An Anonymous Coward writes "I just want to remind everyone that there is still active air cover over at least Chicago. A tanker is orbiting O'Hare and at least what appear to be two F-15s are making the rounds. If you would like more information including frequencies I suggest subscribing to the CARMA mailing list at QTH.net for up to date monitoring information."

Disheartening news from Egypt: soulflakes points to this story of some Egyptians celebrating the attacks today. Here's a BBC piece which indicates the feeling is shared in some other African countries. This doesn't mean that all or most people in any country feel the same way.

yoda389 writes: "I'm getting reports from friends that gas prices are jumping to as much as $5.00 a gallon. There are huge lines at all gas stations here in my hometown someplace in Wisconsin." And ikohl1 writes: "A friend just informed me of how gas prices were raised to $3.50 in a town near where i live. I didn't believe him at first but I found this article on Yahoo."

Gas prices may fluctuate in the short term, but in the long haul, effects on exports of goods physical and abstract may be affected just as drastically: elliotj writes: "MSNBC has a Steven Levy opinion piece on the possible implications of today's attack on America and governmental policy on encryption export restrictions. Personally, I think we need to determine exactly what happened before blaming physical or electronic security measures for a role in the tragedy. I heard the planes were hi-jacked with knives ... that doesn't sound very high-tech or a sign of significant security failings to me. It is the act itself that is so shocking and sickening."

Further news of the events going on around the world following the attacks earlier today on New York and Washington. To follow things even more closely, you are encouraged to join realtime CNN coverage in channel #cnn_newsfeed on irc.idlenet.org. (Doubtless there are other similar IRC and IM feeds going on -- please post them in comments.) In addition to the news below, note that CNN has reported that multiple suspects were arrested with a van loaded with explosives in the vicinity of New York's George Washington Bridge. Update: 09/12 04:29 AM GMT by T : Many readers have reported that the van in question was found not to contain explosives, though its occupants were held for questioning. And Giacomo DiGrigoli, international product manager at PayPal.com, wrote with word of a donation fund on the PayPal website where folks can make donations to the American Red Cross.

Contradicting earlier reports, reader Adam Brookman writes: "I can guarantee that no car bomb went off in front of the State Dept. in DC. My father is part of the critical personel at State dept. When I read that I called him. He said he heard the same thing and he also heard that the building was hit by a plane, but neither were true."

Worth reading is this analysis of the motives and some possible suspects in today's violence, at Jane's International Security News. They've picked three plausible attackers. Motive aside, Jack Bryar has a convincing take on who is really most hurt by the attacks today.

babyruth writes: "amazon.com has a Red Cross Relief fund set up on their homepage, where you can contribute online. Only several hundred have contributed so far, let the power of /. help!" Iridium provides a link straight to the donations page, noting that "All standard fees are waived -- all proceeds go directly to the Red Cross." Of course, the Red Cross is -still- in desperate need of blood. If you can donate, please call 1-800-HELP-NOW to find the donation center nearest to you.

iggyflashbulb writes: "CNN reports some oddball group not associated with bin Laden is attacking Kabul at night. Are they taking advantage of the NY situation or did they create it?"

An anonymous reader writes: "Following the sad (and outrageous) mess of these terrorist attacks, results are already starting to impact the country. When a RSM failed on one of our 5500 Ciscos, we recieved the following notice

'Due to a national emergency completion of your case, delivery of your parts or engineer will be delayed until further notice. Several areas of the country have restricted transportation and currently no air traffic is available. Cisco will notify you as soon a we are able to dispatch your order.'

There doesn't seem to any information on Cisco's site."

CERT is in action as well: SilentTone writes: "Ween Hall at Carnegie-Mellon University was evacuated today so the the Computer Emergency Response Team could go into action."

Many readers have been assembling mirrors for the overloaded news sites of the world. Jon Anhold writes: "I've compiled more photos and what not, mirrored many of the sites around to help the load. They're available here: http://ziggy.dreamland.net/wtc/"

Owen Bossola writes: "This is a simple webpage I put up with shots I took all day of the World Trade Center. I go to school across the river at Stevens Institute of Technology and I watched the whole thing from campus. It is absolutely nuts, I'm looking out my window and for the first time, downtown NYC is dark, and there aren't two large buildings gleaming back at me."

rhyder writes: "I was last in the World Trade Center and the attached World Financial Center on Saturday evening. Many people I know work in those buildings, even more live and work in the shadow of those 2 towers.

From the Port Authority of NY and NJ:

1. The Port Authority
   
2. Trade Center Concourse Level Map
   
3. Trade Center Plaza Level Map
   
4. Trade Center Complex Overview
   
5. Area Map showing southern tip of Manhattan and the Trade Center location."

An Anonymous Coward seeks more information about an interview that Washington area readers may be able to provide: He writes: "Fox News channel 5 (local around 6:30ish E.S.T) this evening had an interview with a witness about what he saw at the Pentagon the moment of impact. His interview was the basic 'I was in my car looked to my side..blah blah' but then he said something totally unexpected. He observed a second airplane immediately swing behind the first in a follow like manner and swoop down on the Pentagon only to pull up at the last second, out of the smoke cloud, and fly away. His description of the plane was pretty detailed, saying it was propeller-driven ... He stated everyone around him who were also outside their cars saw the SECOND Airplane following the first and it was also going in."

Anyone else able to confirm this rumor?

Jon Bishop asks: "Why Today? Why did this attack happen on September 11, 2001. Here is a guess. I played with the date commonly used for programming. YYYYMMDD returns 20010911. 911...in 2001. Is this play on numbers intentional or coincidence?" It may be significant that the anniversary of a Congressional resolution "favoring a Jewish homeland in Palestine" falls on this date. Then again, if you go back a century or two, you may find a lot of anniversaries that seem just as significant.

Carl Merritt writes: "Since many sites seem to be creaking under the load today I've dumped every relevant picture and video I can find onto my server, please feel free to suck up some of my unused bandwidth with downloads or links: http://www.binaryvista.com/WTC/ I'll probably leave it up for a couple weeks, or until CNN asks me to remove their pictures ;-)."

An Anonymous Coward writes "I just want to remind everyone that there is still active air cover over at least Chicago. A tanker is orbiting O'Hare and at least what appear to be two F-15s are making the rounds. If you would like more information including frequencies I suggest subscribing to the CARMA mailing list at QTH.net for up to date monitoring information."

Disheartening news from Egypt: soulflakes points to this story of some Egyptians celebrating the attacks today. Here's a BBC piece which indicates the feeling is shared in some other African countries. This doesn't mean that all or most people in any country feel the same way.

yoda389 writes: "I'm getting reports from friends that gas prices are jumping to as much as $5.00 a gallon. There are huge lines at all gas stations here in my hometown someplace in Wisconsin." And ikohl1 writes: "A friend just informed me of how gas prices were raised to $3.50 in a town near where i live. I didn't believe him at first but I found this article on Yahoo."

Gas prices may fluctuate in the short term, but in the long haul, effects on exports of goods physical and abstract may be affected just as drastically: elliotj writes: "MSNBC has a Steven Levy opinion piece on the possible implications of today's attack on America and governmental policy on encryption export restrictions. Personally, I think we need to determine exactly what happened before blaming physical or electronic security measures for a role in the tragedy. I heard the planes were hi-jacked with knives ... that doesn't sound very high-tech or a sign of significant security failings to me. It is the act itself that is so shocking and sickening."

sarchasm writes: "Apparently George Lucas is suing medical intsrument company Minrad for calling some of its new laser-based surgical devices Light Sabers. According to the suit: "Any deficiencies or faults in the quality of the defendant's goods are likely to reflect negatively upon, tarnish and seriously injure the reputation which Lucasfilm has established for goods and services marketed under its Light Saber mark. This confusion is likely to result in loss of revenues to Lucasfilm and damage to its reputation."" I know that I myself have on occasion confused surgical cutting implements and little-plastic-flashlights-with-plastic-cones. If you go into surgery, and the surgeon has one of these, he's made the same mistake, and you'd better let him know!