Slashdot Mirror

Rinzai writes to mention an article on Gamasutra, noting a statement by Ken Kutaragi where the CEO states that the PS3 is a computer, not a console. From the article: "He went on to outline a scenario where many parts of the PS3 were upgradeable, much more like a PC, noting: 'Since PS3 is a computer, there are no models but configurations', and continuing (though talking in the theoretical): 'I think it's okay to release a [extended PS3] configuration every year'. It's clear from the comments that Sony is indicating that it will be possible to upgrade hard drives and perhaps even other components easily."

PseudoSapien writes "A Dutch consumer media company is hoping it can tap the power of the VIC 20, the PET and the Commodore 64 to launch a new wave of products, including a home media center device and a portable GPS (Global Positioning System) unit and media player. They're talking about Resurrecting Commodore." From the article: "Commodore is far from the first company to try to revive a once-popular tech brand. The Amiga, Commodore's onetime PC brand, has had its own decades-long history as fans tried to preserve both the computer's operating system and brand despite the lack of strong corporate backing."

Reader Mountain Splash writes "The New York Times has a decent thought-inspiring article questioning what happens to our stored data and who owns the rights to it after we die. I have to admit that, while this dilemma had already crossed my mind many months ago, I've been rather slow to do something about handling it. While considering the same, though, what I did do was start a very detailed list of my many various emailboxes, IM monikers, cyber buddies, and yes, passwords (complete with encrypted hints to be stored separately). I have also already approached my roomie and my sister about following up with that list for me as a last wish if and when the inevitable should occur. Just wondering if everyone else has done the same or similar... Anyone gone so far as to have already filed their information along with their will with their family lawyer?"

hexidec writes "Haven't seen this here yet, though I may have missed it. Anyway... A group of Australian techies have put together an analysis matrix of the likelyhood of each SCO Unix claim being true, and what outcome would most likely result if so. Puts a lot of the various recent suppositions in one handy place."

metal_llama writes "There is a story in the Milwaukee Journal Sentinel about a man, Christopher Blummel, who "has a vision for a better world - one where every man would carry in his wallet a small cellophane packet containing a product that can come in handy in an emergency. Duct tape." This is exactly what I've always wanted: an ever-handy supply of duct tape."

FarceMajeur writes "Business 2.0 has a column on a recently prototyped "round engine," properly named a toroidal engine, by VGT Technologies, Inc. Nice Flash animations of the concept are here. I've always admired the Wankel engine, but it seemed more like a time bomb than a going concern. This engine is billed as the 'world's first practical Concentric Positive Displacement Engine,' meaning no eccentric rotation to generate vibration, meaning fewer catostophic failures, one would hope."

brnsurgon1 writes ""The aim of the project was to investigate mobile gaming over GSM- and Bluetooth- networks, by developing a concept prototype, connecting a Gameboy to a mobile phone over Bluetooth. The results show that it is possible to connect two Gameboy Color over a GSM network by connecting to the phone using the Bluetooth plugin we developed for the Gameboy."" A couple other have submitted this story - it looks interesting. But, heck, I'm still trying to finish Golden Sun on my GBA.

David Kennedy writes "This is a review of Tom DeMarco's recent Broadway title, Slack, sub-titled Getting past burnout, busywork, and the myth of total efficiency." Relax, and read on below to find out how good a case DeMarco makes for keeping slack. Slack: Getting past burnout, busywork and the myth of total efficiency. author Tom DeMarco pages 220 publisher Broadway rating A reviewer David Kennedy ISBN 076790768X summary A highly entertaining, and informative survey of the state of the high-tech and software industries today, which suggests that companies have been taking exactly the wrong actions under pressure and further decreasing their ability to handle rapid change.

Summary: A highly entertaining, and informative survey of the state of the high-tech and software industries today, which suggests that companies have been taking exactly the wrong actions under pressure and further decreasing their ability to handle rapid change. The book is peppered with interesting asides and examples, but is always informed by the central thesis that companies need more Slack built back into their structures.

Check your sources. Tom DeMarco is an established industry management guru who has the respect of many of the technical community. He's written several previous titles, including the notable Peopleware and the collection, Why does software cost so much?. I'm not normally keen on any books in this genre, but have always found DeMarco's writing very readable and though-provoking -- most importantly for me, he has a habit of trying to find NUMBERS to back up any claims.

What's this book about? This is a 2001 title, and I find it slightly shocking that, in a maturing industry, we still need a book on this topic (from the blurb):

"To most companies, efficiency means profits and growth. But what if your 'efficient' company - the one with the reduced headcount and the 'stretch' goals -- is actually slowing down and losing money? What if your employees are burning out doing the work of two or more people, leaving them no time for planning, prioritizing, or even lunch? What if your super-efficient company is suddenly falling behind?"

So far we're just talking about the state of the modern software industry right? What's he proposing we do about it?
"[...] what you need is not more efficiency, but more slack. What is 'slack'? Slack is the degree of freedom in a company that allows it to change."

It seems a very simple concept to me, but then I'm an engineer, his writing is persuasive, and I have the benefit of 20-20 hindsight when reading. How can he get a 220 page book out of such a simple concept? After all, all we programmers know that your general purpose solutions always sacrifice speed for flexibility right?

What he discusses is a business model where you keep people, say, 70% busy. This leaves time for unexpected business, for reflection on why X takes so long and how to fix it, for self-training, for discussion about how things are done. These are all good things -- but the winner is that when people are stressed by sudden change or a deluge of new work, they have some slack to take in. Things change, you suffer a reduction in productivity, but hey, you had some slack to take in so the week's work is still getting done, you've just dropped that Ruby book for a week or two. You're swamped by a rush on finishing Product X before a competitors Product hits the market first -- just drop that tinkering with a novel memory pooling thingy you were considering slotting in to replace the adequate-but-inelegant solution in your product. I'm simplifying and reducing his argument here, but that's the idea. The other corollary to the 70% busyness level is that the system is responsive -- some nodes are 100%, some are 20%, but overall things are flowing. A system where most nodes are at 100% means some nodes are hanging waiting for other nodes to catch up -- total throughput drops. This'll make more sense reading his version ('underworked but responsive secretary' vs '100% busy, cannot help until Friday secretary'), but it's a good central topic -- simple, but not trivial.

220 pages isn't much -- he states that the book should be comfortable reading for a business trip -- and the bulk of the space is taken up by rationale for his suggestion, and discussion of the consequences. What I found valuable about the book was the description and subsequent debunking of several management techniques -- for example, he has a severe go at management-by-objective. I recognise it. I suspect you too will recognise it, and several other common variations.

Let's have a quick skim of the contents -- this isn't a technical book, more one massive opinion column, so the section titles aren't that useful, but I feel like I'm cheating if I don't do this in a review ...

• Slack
  Madmen in the halls, busyness vs business, the myth of fungible resources. This section sets up the case by setting out the assumptions, and describing what actually happened to most businesses when put under pressure in the last 10 years. I loved the word "fungible" too -- describes a resource that can be freely interchanged -- like paperclips are and software designers aren't.
• Lost, but making good time
  The cost of pressure, aggressive schedules, overtime, culture of fear, quality, management by objective. This is a meaty section and basically describes how the heck things got to be this way, what practices were adopted, and how they made things worse...
• Change and growth
  Vision, leadership, fear and safety, trust, what middle management is there for, change management. This section talks about change, specially why a lot of the measures adopted to prepare for it help make things worse, and how we should instead consider other approaches.
• Risk and risk management
  Working at breakneck speed, learning to live with risk. This seems like a short section from the contents, but it's reasonably long. There's less to discuss here for what we have is a 2-by-4 to head of businesses who refuse to plan for failure. A discussion then follows of the classic problem -- scheduling -- and why you'll never do a decent job of that without risk management. This is the only section where the tone is hectoring rather than persuasive -- or else that was my own frustration at the experiences I've had coming into play!

Target audience It's aimed at a particular segment according to the cover: "A handbook for managers, entrepreneurs, and CEOs." Well, I'm none of those, but I enjoyed it and found it useful. I'd prefer that my bosses were reading this than most of the other pap from the same shelf, but let's face it, change comes from all levels in the organisation, and if you can't spot mistakes being made within your team then you can't plan for your own career either. Read this book, it'll come in useful either when your managers start going awry and making you suffer, or it'll come in useful when you float up the org chart and have to start dealing with a team of your own.

What's good? Most of it. This is a highly entertaining read, and does present some genuinely useful ideas. It's also great as a collection of management anti-patterns. I think any career programmer in a medium-sized or above business would find this book interesting. Actually, come to that, anyone who enjoys Dilbert will enjoy this book.

What's bad? Not much. There were a couple of areas where I would have liked more case studies or evidence. As I said above, the recourse to surveys for the truth is something of a trademark of DeMarco -- he certainly references quite a lot of material in this book, but doesn't produce any solid evidence to back his ideas. Granted, probably hard to experiment on this scale!

You can purchase Slack from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

David Kennedy writes with a review of Tom DeMarco's older Dorset House title, Why does software cost so much? (sub-title: And Other Puzzles of the Information Age.) Sounds like something to put in the same section of your library as Frederick Brooks Jr.'s The Mythical Man Month . Why Does Software Cost So Much? And other Puzzles of The Information Age author Tom DeMarco pages 230 publisher Dorset House rating 7 reviewer David Kennedy ISBN 093263334X summary An older collection of essays, some good, some bad, from one of the most respected names in the software management field.

Summary: An older collection of essays, some good, some bad, from one of the most respected names in the software management field. An interesting read, not least because of the amusement to be gained from how things have, and haven't, changed. Worth reading if you have the time, but not as essential as some of his other titles.

Check your sources. Tom DeMarco is an established industry figure who occupies that rarest of market niches - he's a management consultant/guru who has the respect of technical people. He's the co-author (with Tom Lister) of the classic "Peopleware" (which I suggest you rush out and read), and it's on the strength of that title that I read his work. I normally lack even the slightest interest in management titles, on the basis that Sturgeon's Law seems to be especially strict in that genre. For example, both my copies of "The 7 Habits of Highly Effective People" and "The Monk Who Sold His Ferrari" ended up in the bin. (If it helps, I have a library of about 5K books [mainly novels], and have only ever thrown out 4.)

What's this book about? This is a 1995 title, and as such is interesting for historical value. The blurb states:
"Drawing together several essays published previously, plus ten all-new papers never seen beyond his circle of colleagues, Tom DeMarco tackles a multitude of tough subjects and wrestles fresh insight out of them. Here's a compact, compelling edition of this acclaimed consultant's views of managing the software process."

What you get is 230 pages of essays or opinion pieces. There are 24 pieces, ranging from a couple of pages to a couple of dozen pages. A smattering of titles:

• Why does software cost so much?
• Management-aided software engineering
• Lean and mean
• If we did only one thing to improve...
• Software development: State of the art vs State of the practice
• Software productivity: The Covert Agenda

As the titles suggest, the focus is on software projects specifically, although much of the discussion re managing the effort could apply to many technical disciplines. All pieces which refer to surveys don't use numbers pulled from a hat, they use numbers pulled from the bibliography at the back.

Target audience It's a mix. Most of the pieces seem aimed at management, from team leader to project manager, but the discussion will be of interest to most programmers, especially those suffering from the Bad Management Blues, or who are thinking of taking a step sideways into a team lead role.

What's good? Quite a lot. This isn't a long book, and it's not going to revolutionize your life, but it makes for a decent couple of hours reading. The author can certainly write, with a chatty style obviously honed by a career based on presentations. All the pieces are easily digested, and usually contain a nugget of something interesting.

There are a few nice points in here re how and why you should manage your software project, but for me, the interesting thing about this older title is that it's a very different world he's talking about! For example, one piece, from 1989, talks about the difference between programmers working on identical tasks. They show nice charts and I was amazed to see PASCAL and BASIC in there. I expected to see COBOL of course, but the small size of the C wedge was shocking. Of course, there was no wedge for C++, let alone Java or Perl.

As with any older title, there are technological fossils like this to be marveled over in several essays, but it's quite interesting how the author pronouncements are generally, well, reasonable and right. He's not Nostradamus, and doesn't predict specifics, but there is a nice discussion on language uptake (he rails against FORTRAN and COBOL in a world of Modula-2, Oberon and SmallTalk! I suspect more people now now use the either of the former languages than all the latter languages put together). In this essay, he talks about how some of the third generation languages are wonderful, but suffer from inadequate or confusing libraries. He suggests that only wide and deep libraries really make people change languages in the real world. I know (from reading his new title, "Slack", review coming) that he's much further from the code now, but I wonder what he makes of Perl or Java? (Certainly the thing that lured me from C++ to Java was the libraries. Well, I missed the STL which makes the Collections API look like a child's homework.)

Other essays talk about the Microsoft anti-trust trial, or the fate of IBM. In both cases he seems to be more-or-less on the money, simply by being slightly cynical and not making any mad assumptions. Of course, by the same token, nothing he predicts is particularly startling, but still, of interest when reading.

There are a quite a few pages devoted to things which don't relate to technology specifically, and hence, don't appear dated now. These generally concern scheduling, or people management, and generally are as good as people expect this author to be. When he's good, he's very good. I want to work with a manager like him someday, just to see what it's like! However, even in these people-skills sections, I can't help but wonder what he'd revise in the light of the whole dot-con debacle.

What's bad? Well, this is a fix-up title, and some of the essays are, to be frank, crap. I doubt any but his most ardently completist fans want to read an essay on his experiences trying to work with desktop video for example. A couple of the essays just struck me as, well, rather pointless. Sometimes funny, but pointless. These tended to be the "Not previously published" ones, and I think there's a reason for that.

Alternate titles Oh, sure. There's a shelf full of titles like this in your nearest bookshop. I don't generally like any of them though, so I'll just recommend his earlier Peopleware and his latest, Slack.

You can purchase Why Does Software Cost So Much? from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

David Kennedy writes "Applied Java Patterns is an adequate Design Patterns reference for those who must have a Java version of the classic Gamma et al (aka Gang of Four, or GoF) Design Patterns, but it's only adequate. If C++ or Smalltalk hold little fear for you, stick with the original sources: 'This isn't the definitive Java Design Patterns book we're looking for -- move along.'" Read on for the rest of David's review. Applied Java Patterns author Stephen Stelting and Olav Maassen pages 561 publisher The Sun Microsystems Press / Prentice Hall rating B reviewer David Kennedy ISBN 0130935387 summary Adequate Java implementation of "Design Patterns"

Check your sources.

The title is published by Sun Microsystems Press, and the two authors are instructors for Sun Microsystems. As you would expect, this means you won't find any discussion of Java's darker corners; this isn't a particularly damning criticism in a book about Design Patterns, but it does mean that, for example, you won't see discussion on why double-checked locking implementations of the Singleton pattern don't work. (I might be reading more authorial/editorial bias into this than was intended of course -- I'm a bit paranoid. Too much caffeine, I expect.)

What's the book about?

From the blurb:

"[...] After briefly reviewing the fundamentals of design patterns, the authors describe how they can be applied effectively to the Java platform and present proven techniques for all types of patterns, from system architecture to single classes. Next, they present a pattern catalog."

In other words, what we get is an adequate intro, followed by about 275 pages of pattern catalog (mostly from Gamma et al, with a few threaded items from Doug Lea's Concurrent Programming in Java). This is what you're buying the book for, and on the whole it's decent material.

It continues:

"In addition, they identify patterns in the core Java APIs and present techniques for pattern use in distributed development. [this title] also features a section on pattern use in systems built with J2EE and Jini technology and coverage of the servlet, JSP, and EJB APIs."

Just about! This entire section is very much secondary to the catalog. The core Java APIs discussion is about 20 pages, the distributed section about a dozen, and the rest only 15! I've seen as much discussion of the pattern usage in the JDK in asides in, for example, Bloch's Effective Java (an excellent book by the way).

Of much more interest are the appendices. In reverse order -- Appendix B is a welcome bibliography. Appendix A is an odd decision on the part of the publisher. Appendix A is "Full Code Examples." Normally I'd think that this is a good thing, but appendix A is 224 pages, as compared to 273 for the whole pattern catalog. I feel it would have been better delivered on a CD. I realise this adds, what? $5?, to the cover cost, but the book would have been substantially thinner, with a knock-on effect on price.

A more important consideration is that this appendix distracts from the catalog, and adds little (other than working framing code) to the discussion of the patterns.

Target audience?

Experienced Java developers - but ones who haven't been exposed to Design Patterns before. I doubted that this was a huge audience, but then realised that Java is often used as a teaching language now, and I may be wrong in assuming most graduate programmers would be comfortable with the C++ and Smalltalk examples in Gamma et al. I could see this being a useful niche title for those mono-linguists starting out their professional careers.

What's good?

Overall, this isn't a bad title. It's decently written on the whole, has passable explanations of the main Patterns, and is presented clearly. It's just that there's nothing superb about it, and the problems (below) offset the overall competent tone. (It's a weird book to review: the majority of the content isn't original, and as a repackaging exercise I can't comment on, say, how brilliant it is to have a name of the Factory concept at long last.)

What's bad?

Too much for a simple port of GoF to Java. Let's start with the obvious flaws and then move onto "missed opportunities":

• Diagrams
  Sorry, but there is no way that the UML diagrams in this title are acceptable in a professional publication. They're woeful, jagged-edged screen-capture affairs.

• Appendix A
  As discussed above, the book has a schizophrenic feel with a LOT of material relegated to, or repeated in, Appendix A. A much more useful approach would have been to provide more material on the applicability of each pattern, or to flesh out some of the alternative implementations discussed.

• The example application
  This title tries to do something laudable, but ill-thought out. What they do is start to discuss an example application (the Personal Information Manager) in the first pattern, and then carry that example through to all the other examples. This isn't a bad idea, but think about it. How do you use your pattern books? I flick through mine. I pull it off the shelf and read one pattern, or pass it to a colleague saying, "You want to change that to a [whatever]."

  When reading this title my flatmate was struggling with some OO design homework -- flicking to the pattern under discussion (Composite) starts us into another discussion of the PIM! This isn't what I want and puts me off the title immediately as I feel like I'm missing some background. The examples need to be more standalone. (To be fair, this only affects the blurb text, the code is independent.)

• Oh editor, where art thou?
  While talking over the Composite pattern with my confused flat-mate, I noted that the Deliverable snippet actually gives the code for the ProjectItem again (page 163). Sadly, it's also wrong in Appendix A. On the full read-through this type of simple proof-reading error occurred too often.

• Oh code reviewer, where art thou?
  Here's a hint for publishers. When writing a book for a professional audience which necessarily thrives on pedantry, try and have examples peer-reviewed first. Much of the code in Appendix A is not great. Now, I realise we're developing educational examples here, and we want to keep the focus on the pattern, but the impression given by the full code examples isn't good. Continuing the above example, the error handling of the Composite pattern is feeble. (Static ints defined in an exception class and then if-elsed on the main class to get printable versions? Yeugh.) I'm being picky here, but this is a book about better design, and people-in-glass-houses, etc. In addition, the core concepts aren't original, and so it's this (slightly sub-standard) example code which gives the added value, or rather, should.

• Fly-leaves
  You know what I love most about Design Patterns? The fly-leaves -- to find a pattern I open the cover, skim the list and turn to appropriate page. Brilliant for a reference title. Applied Java Patterns misses a simple trick here. A hardcover edition would also be nice. As would those nice GoF ribbons. (My apologies if there is a softcover version of the GoF book featuring neither fly-leaves nor ribbons and I've been comparing apples to oranges.)

So, overall the impression that this book gave me was of an opportunity missed. Too many little details wrong, or lacking when compared to the GoF title.

Alternate titles?

There is another Java Design Patterns title: Addison-Wesley's Java Design Patterns -- A Tutorial, by James W. Cooper (2000, ISBN 0-201-48539-7). I can't say I recommend this title either -- it's much thinner, comes with a CD, takes a more tutorial tone, but suffers many of the same flaws (sloppy editing, lack of 'flickability,' chunks of dodgy code and some bloody examples).

Sorry, but the undisputed king still reigns -- the original GoF book is still superior in almost all respects. Only a lack of recent examples, and the fact that the examples are only in C++ and Smalltalk can be called criticisms. (Details: Design Patterns: Elements of Re-usable Object-Oriented Software, by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides. Addison-Wesley, 1995, ISBN 0-201-63361-2)

If you feel that the GoF book is a bit, well, academic and intimidating for your taste then might I suggest a side order of John Vlissides's companion volume, Pattern Hatching: Design Patterns Applied (1998, ISBN 0-201-43293-5). This slim volume talks about applying patterns -- where, how, etc -- in a clear way, using a tutorial approach. The example system developed helped me "get" some of the concepts first time through. The examples are in C++.

I don't want to give the idea that there are no new Design Pattern books worth reading - for example, for J2EE work I think highly of Core J2EE Patterns by Deepak Alur, John Crupi, and Dan Malks (2001, Prentice-Hall, ISBN 0-13-066586-X).

So, to sum up, this isn't a bad book, but it does feel like a pale imitation of the GoF title, and offers very little to anyone who develops in Java but has access to the GoF book. Any publishers or wannabe authors listening? Seems like now might be a good time to think about issuing The Design Patterns Java Companion, along the lines of the existing Smalltalk title. (Hmm, maybe I should take my own advice ...)

You can purchase Applied Java Patterns from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

David Kennedy contributes the review below of Richard Hightower's new book Python Programming with the Java Class Libraries, subtitled A Tutorial for Building Web and Enterprise Applications with Jython, writing "This book tries to be suitable for both new and experienced programmers, and suffers from this decision. However, it presents all the central programming concepts clearly and is a decent primer on Jython. It is illustrated with copious code, and covers plenty of advanced topics. Worth reading if you're interesting in the Jython language. Oh, and ignore the sub-title." Python Programming with the Java Class Libraries author Richard Hightower pages 448 publisher Addison-Wesley rating B+ reviewer David Kennedy ISBN 0201616165 summary Solid technical primer on Jython. Probably best for those with some comp. sci. experience.

First Impressions We all know not to judge a book by its cover, but let's be honest; when looking at a bookshelf groaning with Learn ${technology} in 21 Days! and ${technology} for Utter Fools, it can be useful to have a filter to apply.

I have the following book-cover rules:

• Ignore everything with a cluttered cover. If I find the cover confusing, I doubt the content will be better.
• Look for an O'Reilly "animal" cover.
• Look for an "Addison-Wesley Professional Computing Series" cover. These tend to be white, with a blue stripe down the side, usually accented with magenta. C++ programmers especially should have several titles from this excellent series on their shelves.

Given my third rule, I am dismayed to see that Addison-Wesley have chosen to go with a cartoonish cover featuring a luminescent python constricting a brown sack marked "Java Beans." It's not the worst cover art I've ever seen, but I have to admit that I probably wouldn't have noticed it on the shelf. I know this seems like a minor criticism, but it is a crowded market.

Target audience So, who is this book targeted at? The blurb and publicity material make it clear that the volume has a split personality, seeking to satisfy both new programmers and experienced programmers.

I find this an odd decision, and while I can understand how it can be tempting to address both audiences at once, the end result feels more than a little fragmented. Let's have a look at the two cases.

If I was a new programmer, or was merely new to Python, would I choose this book over something more obviously targeted to me like the O'Reilly title, Learning Python (Mark Lutz and David Ascher)? I think I'd go with the O'Reilly title here if I was a novice, I mean, doesn't "building Web and Enterprise Applications" sound a little ambitious? Would a new programmer even understand the sub-title? (I've been working for over four years and I'm still not sure what exactly Enterprise is supposed to mean!)

Similarly, if I was an experienced programmer, perhaps in Java, would I pick up this book to get a handle on Python? Well, I might, but I might be dismayed at the amount of material on simple matters like if statements.

This is a pity, as the book probably works better for an experienced programmer, or at least one who has done some work in other languages. The sidebars are usually interesting and technically dense, delivering maximum information in limited space.

I think my main problem with the decision to deliberately split the readership into two target audiences is that I've seen it done better. For example, as mentioned above, Learning Python is probably the main competing title. It too addresses both the novice and experienced programmers, but does so in a much more transparent way. Rather than prefixing sections with "Advanced topic," thus alienating some readers, the more natural box-out approach is used. This gives a much less schizophrenic feel to the text, with the reader able to read the box-outs as and when they feel interested and able to understand the material. When reading Python Programming with ..., I sometimes felt like I was being directed in what to read.

I've been quite negative about this split up to this point, and would like to emphasize that the latter part of the book doesn't really suffer from this problem. Once assured that the new programmer has the basics under his belt, the text assumes a much more natural flow, with the standard optional box-outs. However, I should say that some of the material in the later chapters is non-trivial, and the smoother presentation of the more difficult material leads me to suggest that the author would have been better served by targeting the experienced programmer alone.

Let's look at the publicity blurb and contents in more detail:

" The goal of this 'first of its kind' book is to teach new programmers some of the basics of Python programming. Using skill-based exercises and interactive programming sessions, it helps new programmers develop an understanding of concepts and practical techniques. For experienced programmers, the book demonstrates Python's breadth of capabilities and demonstrates the ways that Python interfaces with the Java APIs for professional application development.

Topics include:

• Fundamental programming concepts, including statements, expressions, interpreters, and compilers.
• Python basics, including operators, string formatting, namespaces, classes, errors, and exceptions.
• Object-oriented programming concepts.
• File input/output.
• Python's intrinsic functions.
• Formatting, parsing, and manipulating strings.
• Interfacing with the Java APIs and working with Java Streams.
• Using Python and Java Swing to create GUIs.
• Working with SQL and JDBC.
• Python and Java applets."

This is a fair representation of the contents. As you can see the poor new programmer is soon expected to work with some non-trivial examples, with the streaming, database and applet sections all being welcome. The material presented particularly benefits from the fairly long example applications.

In addition, I feel that the appendices are interesting and worthy of mention.

• Installing Jython on Windows
• Installing Jython on Linux.

  Both installation guides are comprehensive and ensure that installation of the language itself shouldn't present any barrier to the novice, or those who are used to having a sysadmin install their work environment.

• The Power of Scripting.

  This is a nice section discussing the blurry distinction between programming and scripting languages, why you might want to script and use Java at the same time, what alternative languages are out there, and why the author feels Jython is interesting and useful.

• Java and Python: A Comparison

  This is an interesting section driving home why Jython is a nice alternative to Java for some applications. It presents some mini-applications, weighted towards Jython's end of the toolbox. They are a small GUI application, a statistics application and some string parsing.

• Regular Expressions.

  A decent workshop on Jython's regular expression facilities.

Oh Editor, where art thou?

I know that having a few mistakes is unavoidable, but there are a few howlers that slipped past the editing process. I particularly dislike this in an introductory book as it causes confusion in the reader and impedes his absorption of the material.

Some of the errors are typographical, and more than a few involve tabbing in code samples. Normally this would be merely irritating, but forgivable. Unfortunately, the significance of tabbing in Python makes this a much bigger problem for the novice reader!

There are also some properly editorial errors. As an example, the first time we see a user-defined function is in Chapter 4, on control flow. One of the canonical examples is wheeled out, a function to return (min, max, range) given a sequence of numbers.

This example is a nice one and is a good indication of why I generally like this book -- it has the user working with collections and mixed types right from the start, doesn't make a big deal out of defining a function, and includes a nice little box-out on efficiency. It also jumps right to a discussion on intrinsic operations and making sure to use them as they're more efficient and well-tested. It also blows up right after that, confusing the name of the argument list with the intrinsic function name and the name of the rewritten function. I wasn't able to untangle the paragraph until I saw the code. Bad editor, no treats!

So, is this book any good? Yes.

Python Programming with the Java Class Libraries is a well above average introduction to using Jython, best suited to interested readers already possessing some Java experience and a decent computer science background. It doesn't hesitate to tackle more complex topics, often with significant amounts of code (good thing), and the author demonstrates a wide knowledge of the field with many interesting box-outs often leading to further reading.

Readers completely new to the programming field will still find this book useful, but may well be intimidated by the advanced material scattered all over the first few chapters and the steep learning curve.

If that is the case, I would recommend that they stick with something like Learning Python should they wish to learn Python specifically, or any of the many other introductory texts on the market if they don't.

Those new to the field who choose to stick with this book will find that there is sufficient advanced material to ensure that the book remains valuable to them for some time to come.

Disclaimer There are two things I'd like to make clear:

• I did not pay for this book. I was given a review copy by the nice people at Addison-Wesley publishers. The author put my name on his list following a review of his previous title. This was decent of him as my previous review had some negative comments.
• I'm not a experienced Python developer. My background is C++ and J2EE. A more experienced Python user may have additional issues with the coding style presented. I did not feel particularly able to judge beyond the basics.

You can purchase Python Programming with the Java Class Libraries from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

AlphaAlien (from neonerds.net) writes: "Another Microsoft Programming Language -- AsmL. AsmL is the Abstract State Machine Language. It is an executable specification language based on the theory of Abstract State Machines. AsmL allows you to test incomplete code due to it being executable on the fly. This doesn't mean it'll execute invalid code though, only that you can execute code segments for instant experimentation (similar to the test-debug function in Visual Studio, but more flexible/powerful). In case you're not tired of all these new Microsoft languages, here's another, Pan. Pan is an experimental embedded language and compiler for image synthesis and manipulation, based on principles from functional programming. The Pan compiler turns descriptions of images and image effects into efficient machine code for use with either a stand-alone program, DirectXTransform for web-page embedding (viewable with IE 5.5 or later), or as a PhotoShop plug-in for use with hosts like Adobe PhotoShop and JASC PaintShop Pro (has only been tested with latter at this point, but should work with former)." You can download Pan from here.

Bob Abooey writes: "SoftwareMarketSolution has an interesting interview of Joel Spolsky, of Joel on Software fame. Joel, a former programmer at Microsoft, discusses some of the reasons he thinks some very popular software companies or projects fail, including Netscape, Lotus 123, Borland, etc." This interview brings out some mild boiler-room stories which sound like they could be the basis of a good book, along the lines of Soul of a New Machine .

bhamon writes "Here's something from the you-have-too-much-time-on-your-hands dept. I've been watching the sci-fi show Earth: Final Conflict, it's about aliens that land on earth to bring peace but really want to enslave us ... blah, blah, blah. There's has been much integration between human and alien systems, bringing new technology. What I've been wondering is which current hardware would most be best to integrate with unknown alien technology? Which operating system would be most easily adaptable to be made compatible with alien systems? Would we still include legacy support for DOS applications??"

Mr. Fusion writes "I'm sure this might affect the actor's union one day, but News.com is reporting that Lucas is going to have an animated lead CGI character in the next Star Wars movie. As long as they leave out Jar-Jar, I'll enjoy the ride." This is a fluff interview, but its interesting for me (I'm an animation junkie of course). Talks about the work he's doing on clothing, hair, and skin texturing. All interesting. I'd love pictures tho.

alumshubby writes "The Washington Post, undoubtedly among others, reports that the AOL & Time-Warner merger has gone through. Note that it was unianimous, and the FTC extracted a promise that the new behemoth would 'protect consumer choice.'" And, on the more amusing side check out this alternative coverage. On a more serious note, we've also got information from the FTC, and coverage from CNNfn, and ABCNews.

Bushwacker writes: "Recently, the OS/2 SuperSite has announced some big (somewhat unfortunate) news about the Warp Client v.4. There's both good and bad news here: First the bad news -- Contrary to hopeful rumours spreading around, A Warp version 5 will not come out this year, if ever. IBM will instead release 'Convenience Packs' which are like FixPacks, but cost you money. The good news -- Unlike the free FixPacks, Convenience Packs will provide more important upgrades which cover a larger field than their lesser cousins. Maybe one of them will include the fabled Project Odin? At least XFree86 is still free ..."

Concealed writes "There is an article in the new Wired which talks about the future of nanotechnology and 'intelligent machines.' Bill Joy, (also the creator of the Unix text editor vi) who wrote the article, expresses his views on the neccesity of the human race in the near future. " From what I can gather this is the article that the Bill Joy on Extinction story was drawn from. Bill is a smart guy -- and this is well worth reading.

James Ensor writes, "I'm sure you'll all be just thrilled to hear that Ericsson has developed and is implementing a way to do targeted ads on Internet enabled cellphones. They envision TV-like FMV commercials in the future. I can hardly, umm, wait."

DeepDarkSky writes "This is a general interest story in the NY Times about Morris Chang - the founder and chairman of Taiwan Semiconductor - and the dynamics of semiconductor manufacturing in Taiwan, and how the earthquakes a while back affected it. Since Taiwan is the leading manufacturer of chips, with Intel, Motorola, and IBM (also Transmeta, as I vaguely recall in the press releases) all having chips manufactured in Taiwan, I thought this would be an interesting read. More significantly, also in the NY Times, another story about the U.S. House of Representatives voting to strengthen military ties with Taiwan. Perhaps they are all too aware of the U.S.'s (and the world's) dependence on Taiwan's chip manufacturing prowess (reminded by the earthquakes) and are eager to protect this source against China?" (free NYT reg. req.)

Sam Smith writes "Does the /. community know of a free email service which offers a POP3 box accessible by email client? None of the major ones that I have found do. Preferably a site which runs under Linux, but it can be something else if needbe."

Keith Dart sent us a link to The Intel CPU Roadmap. From there you can keep track of the nine bazillion different CPUs Intel is going to be releasing in the future. Nice to see the next few years mapped out clearly.

Is it just me, or has today been looong as heck? Allright, first off, the Slashdot Q&A thing is still coming, and we have a (ahem) Victim to start routing questions. Contact Clifton Wood with your questions. Linux, or other. Easy or Hard, Bring it on. We'll post it, and let the Slashdot Readers try to answer it! Next, Sam Smith sent me A Psion 5 Review thingee. It's funny and interesting if you need a distraction. Lastly, Matthew Miller Sent us a link to some interesting info about MacOS 10.