Knowing .NET

Change and Configuration Management

AnthillPro3 (Urbancode)

Automated Build Studio (AutomatedQA)

FLEXnet Connect (Macrovision)

Perforce: the Fast Software Configuration (Perforce Software)

Team Foundation Server (Microsoft Corporation)

CA Wily Introscope ChangeDetector (CA / Wily Technology)

Collaboration Tools

Adobe Acrobat Connect Professional (Adobe Systems)

Code Collaborator (Smart Bear Software)

Confluence (Atlassian Software Systems)

NetBeans IDE (Sun Microsystems)

Sugar Professional (SugarCRM)

TeamCity (JetBrains)

Database Engines and Data Tools

Coral8 Engine (Coral8)

dbdeploy (ThoughtWorks)

MarkLogic Server (Mark Logic)

SQL Anywhere (Sybase iAnywhere)

SQL Refactor (Red Gate Software)

Visual Studio 2005 Team Edition for Database Professionals (Microsoft)

Design and Modeling

Compuware OptimalJ (Compuware)

Corticon Business Rules Modeling Studio (Corticon Technologies)

MagicDraw UML (No Magic)

RAVEN (Ravenflow)

stpBA Storyboarding for Microsoft Visual Studio 2005 Team System (stpsoft ltd.)

Stylus Studio 2007 XML Enterprise Suite (DataDirect Technologies)

Enterprise Tools

Cape Clear ESB Platform (Cape Clear Software)

Liferay Portal (Liferay)

Mule (MuleSource)

Appistry EAF (Appistry)

Pentaho Open BI Suite (Pentaho)

TeamCity (JetBrains)

Libraries, Frameworks and Components

JViews (ILOG)

NetAdvantage for .NET (Infragistics)

telerik r.a.d.controls for WinForms (Telerik)

.NET Framework 3.0 (Microsoft)

Intel Threading Building Blocks for Linux (Intel)

Microsoft XNA Game Studio Express, XNA Framework (Microsoft)

The Mono Project (Novell)

Mobile Development

AccuSPEECH (Vangard Voice Systems)

Carbide .c++ Professional Edition (Nokia)

Crossfire (AppForge)

Qtopia Greenphone (Trolltech)

NetBeans Mobility Pack 5.5 and Sun Java Wireless Tookit 2.2 (Sun Microsystems)

Qtopia (Trolltech)

Project Mangement Tools

6th Sense Analytics (6th Sense Analytics)

DevPlan (TechExcel)

Rally Enterprise (Rally Software)

TargetProcess (TargetProcess)

Teamwork (Open Lab)

V1: Agile Enterprise (VersionOne)

Security

AppScan (Watchfire)

beSTORM (Beyond Security)

DevInspect (S.P.I. Dynamics)

Fortify Defender (Fortify Software)

Fortify Source Code Analysis (SCA) (Fortify Software)

Metasploit Framework (Metasploit)

Automated Testing Tools

AgitarOne (Agitar Software)

CodePro AnalytiX (Instantiations)

Mindreef SOAPscope (Mindreef)

Parasoft Jtest (Parasoft)

Parasoft SOAtest (Parasoft)

TestComplete (AutomatedQA)

Bug and Defect Tracking Tools

JIRA (Atlassian Software Systems)

OnTime 2007 Hosted (Axosoft)

Software Planner Professional (Pragmatic Software Co.)

TestTrack Studio (Seapine Software)

Utilities

Adobe Captivate 2 (Adobe Systems)

AutoPatch (SourceForge)

ElectricCommander (Electric Cloud)

TEKchecker and StyleWriter (ClearSpecs Enterprises)

TextMate (Macromates)

VMware Lab Manager (VMware)

Web Development

Adobe Flex 2 (Adobe Systems)

IntelliJ IDEA (JetBrains)

Kapow Mashup Server (Kapow Technologies)

LignUp Communications Application Server (LignUp)

Mindreef SOAPscope Server (Mindreef)

NetBeans Visual Web Pack (Sun Microsystems)

Web Sites/Developer Networks

CM Crossroads (CMC Media)

IBM developerWorks (IBM)

Sun Developer Network (Sun Microsystems)

Koders.com (Koders)

Krugle (Krugle)

Makezine.com (O’Reilly)

The Code Project (The Code Project)

I’m the moderator of the “Development Environments” category of the Jolt Awards and this year the finalists are:

Development Environments

• EiffelStudio Open Source Edition (Eiffel Software)
• IntelliJ IDEA (JetBrains)
• IronPython (Microsoft)
• Microsoft XNA Game Studio Express, XNA Framework (Microsoft)
• NetBeans IDE (Sun Microsystems)
• Wolfram Workbench (Wolfram Research)

This makes for three interesting match-ups at the “sub-category” level: EiffelStudio and IronPython are primarily language-driven, IDEA and NetBeans are broadly capable Java heavyweights, and XNA and Wolfram Workbench are for the development of specialized types of applications. Oh, how I wish the judges’ discussions could be published.

Books (Practical/General Developer Interest)

Agile Software Development: The Cooperative Game (Addison-Wesley) by Alistair Cockburn

Catastrophe Disentanglement (Addison-Wesley) by E. M. Bennatan

Eric Sink on the Business of Software (Apress) by Eric Sink

Practices of an Agile Developer (Pragmatic Bookshelf) by Venkat Subramaniam and Andy Hunt

Software Creativity 2.0 (DeveloperDotStar) by Robert L. Glass

Software Estimation: Demystifying the Black Art (Microsoft Press) by Steve McConnell

Weinberg on Writing: The Fieldstone Method (Dorset House) by Gerald M. Weinberg

Books (Technical)

Code Quality (Addison-Wesley) by Diomidis Spinellis

How to Break Web Software (Addison-Wesley) by M. Andrews, J. Whittaker

Java Concurrency in Practice (Addison-Wesley) by Brian Goetz et al

Rails Recipes (Pragmatic Bookshelf) by Chad Fowler

Refactoring Databases (Addison-Wesley) by Scott W. Ambler and P. J. Sadalage

Head First Object-Oriented Analysis and Design (O’Reilly) by B. McLaughlin, G. Pollice and D. West

Ruby Cookbook (O’Reilly) by Lucas Carlson and Leonard Richardson

CSS: The Missing Manual (O’Reilly) by David Sawyer McFarland

Not a bad bookshelf…

Congratulations to all the finalists!

Microsoft has posted version 1.1.13.8 (whatever the heck that means) of their F# compiler, which gives me an excuse to discuss the book Practical OCaml by Joshua Smith.

Practical OCaml is a new release from APress. My favorite technical book of last year was Practical Common Lisp, by Peter Seibel, and I hoped that Smith could duplicate the feat. It looks like the book has a different editorial team, but follows some similar structural advice. Even if nothing else, both books are reasonably sized (~400 pages, not ~1,000) and divided in a manner that makes them very appealing for those interested in learning a programming language.

My main motivation for reading this book (other than the hope that APress had discovered a way to bottle the lightning of language evangelism) was that “pure” functional languages are inherently parallelizable. That is to say, the language semantics are such that a sufficiently smart compiler could correctly take care of threading the computation over multiple cores/processors. Since I am of the belief that the manycore era is going to require a sea-change in programming approaches, I think it behooves those interested in the future to gain experience with such languages. Concurrency is treated only tangentially in Practical OCaml and I am under the distinct impression that OCaml is not inherently parallelizable (I believe this to be the case with F# as well). Nonetheless, it’s certainly true that concurrency is “easier to think about” when using functional approaches, so there’re still things to be gained.

What I didn’t realize was that OCaml is a very, very good language for writing domain-specific languages. It’s pattern-matching semantics are quite advanced and lex/YACC libraries (ocamllex and ocamlyacc) are part of the standard distribution. While I feel that tools like ANTLR and concepts like Parsing Expression Grammars have the potential to displace lex/YACC, there’s no questionthat lex/YACC is the dominant “species” in the world of compilers.

Having said all that, I’m afraid that Smith’s book is not nearly as persuasive as Seibel’s. I abandoned LISP long ago and Seibel made me reconsider that decision. I wanted to learn OCaml but could hardly sustain my enthusiasm through the first chapter. The first sentence of Practical Common Lisp is “If you think the greatest pleasure in programming comes from getting a lot done with code that simply and clearly expresses your intention, then programming in Common Lisp is likely to be about the most fun you can have with a computer.” That’s a good opening and I think accurately captures the undeniable aesthetic appeal of LISP. The first sentence in Smith’s “Why OCaml?” introduction is “It’s a fair question.” That’s a bad opening. At least, it’s a bad opening when followed by five paragraphs whose greatest substantive claim is “OCaml helps the programmer to easily express normal concepts and actually express difficult concepts.” If that doesn’t take the wind out of your sails, rest assured that it is preceded by “Returning to the title question, if I were to answer the question in more mundane terms, I would say that….” That’s the type of opening that calls into question the author’s precision.

The tutorial that follows is structured well-enough, but the concepts are not presented as well as they could be. Here is the complete discussion of the I-would-think-important concept of mutable variables:

It can be tempting to use mutable references, but I suggest that you resist that temptation. I have generally found that, except in a few cases, the use of a mutable reference could be removed by fixing my designs.

This is not a rule in any sense of the term because sometimes a mutable reference is really the best choice. File input/output (I/O) is a good example because file I/O is often a nonfunctional chore. Some other functional languages deal with these nonfunctional chores by using monadic computation, but that might not always be necessary.

You can hide mutable references in OCaml classes to make their use less problematic (this is discussed in more detail in Chapter 19).

This is on page 23 and is not preceded by a discussion of why mutable references are undesirable or what monadic computation is…I can’t resist: the index has only 1 reference for “monadic computation” and that leads to page 251′s explanation that:

Monadic computations and monads in general are creations that open up a small loophole for purely functional languages. Although a purely functional language cannot have functions with side effects, it can have values that describe and contain side effects. This boils down to computational sleight-of-hand that comes with a cool-sounding name.

Oh. Alright then. I started the book under the impression that issues of mutability might be fairly important to understanding a functional language, but apparently they aren’t.

APress is 1-for-2 with their Practical… series, I hope Practical Haskell comes up to bat next.

In the meantime, if you want a really good book I suggest: Practical Common Lisp.

Compilers: Principles, Techniques, & Tools 2nd Ed. by Aho, Lam, Sethi, & Ullman is the perfect book for two niches: people writing C compilers for embedded processors and CS students running the gantlet of compiler courses. I don’t want to say that those niches don’t exist and that for people in that situation The Dragon Book, as it’s universally known, is anything but essential reading. For the rest of the world, that is, that broader-than-professional-compiler-writers-but-still-a-marked-subset-of-the-world-of-professional-programming niche, the book is not compelling.

The Dragon Book, as the text has been universally known, is widely considered a “hard read” and, like Shakespeare or Joyce, even a smart person reading it without guidance or prior exposure will have difficulty gauging the amount of attention one should give a particular point. It’s near-universal reach probably does make it “the one book to have if you’re having only one,” and it’s depth has kept it a spot on many a shelf for many a year, but in all honesty I found myself disappointed while reading it.

The entire second half of the book is devoted to optimization and OS- and machine-level code generation. It remains the definitive text on this subject, but this subject is outside the realm of interest for the large majority of people who might be interested in writing compilers. Today, most people interested in compiler construction are far more interested in language design issues than in chip-level instruction sets and graph-based optimizations. Whether a minority or a majority, I can’t say, but many (potential) compiler writers are interested in targeting the CLR and/or the JVM and thereby embrace a simplified runtime environment.

It seems sadly out of touch with current debates: the index lacks references to, for instance, “duck typing” or “packrat parsing,” two techniques that are unquestionably, on the one hand, “all the rage” and, on the other, theoretically intriguing. To not cover either, in a book that spends 200 pages on lexical and syntactical analysis, seems almost willfully pig-headed. The book covers its chosen principles in depth (bordering on “is this a book on compilers or automata theory?”) but does not venture outside those lines.

Another instance: on page 966, in the appendix, there’re two paragraphs discussing “object-oriented vs. phase-oriented” compiler design. To call that perfunctory is to be kind — perfunctory coverage would at least mention theVisitor design pattern.

Again: just in the past few days, there’s been talk about how one could / should generate method dispatch in a dynamic language. Joel Spolsky says that Ruby is slow because of method dispath. Avi Bryant says that’s true, but only because of naive code generation (Ruby today does not follow The Hugunin Directive : “Use fast paths for common cases, using native constructs if possible.”) Ted Leung refers to Avi’s discussion as “the 20-year-old method of in-line method caching.” The Dragon Book, in contrast, explains how to construct a stack frame.

Similarly, The Dragon Book spends a tremendous amount of time on “lexing” efficiently (lexical analysis is the first step of writing a compiler: transforming a stream of characters into a stream of tokens) and such is the influence of theory that I would be shocked to ever see a lexer not based on deterministic finite automata (DFAs). Anyone who ever wrote a lexer using, say, String.Split() and a hashtable would be banished from The He-Man’s Compiler Writers Club. This despite the fact that such a lexer would be highly transparent in purpose and design and would almost certainly be able to handle any reasonably-sized source code input (I was going to qualify this, but for heaven’s sake, we’ve got gigabytes and gigahertz today).

As for “tools,” the discussion is solely focused on lex & yacc. A quick example of how creaky the discussion is: the one source code snippet showing input to lex shows a function that returns a pointer and whose signature specifies it as returning an int. So…there’s a piece of C code that hasn’t been updated in twenty years. True, lex & yacc are the ancestors of virtually every compiler-construction tool. More’s the pity, as the general design of these tools could be made recognizable to those who’ve used tagging languages like PHP or ASP. For that matter, a generation that’s familiar with DOMs and XML parsers brings more than a blank slate to the tasks of tree-walking and rewriting.

So The Dragon Book sadly exemplifies the barriers-to-entry in the world of language design and compiler construction. This is a great book for the 500 teams worldwide building C compilers (yeah, seriously, there are hundreds of C compilers). For better-or-worse, it’s undoubtedly the textbook of choice for many CS curricula. It is not a good text for those interested in today’s active debates and discussions about language design and implementation.

This entry is hReview microformatted.

One of the cable channels (FX, I think) has been playing “The Core” in medium rotation lately. I’ve been trying to expose myself to it in small amounts, to inoculate myself and accept it as cheesy “so bad it’s good” fun(ref. “The Fast and the Furious”: One of my favorite movies of the past few years.)

A few years ago, during a bout of business travel, I saw “The Day After Tomorrow,” like, 7 times on various airplanes and I really thought that was the worst that could be done, but I just saw the last 10 minutes or so of “The Core” yesterday. OMG. So bad. So very, very bad.

How did I miss this? The tool TOAD by Quest Software is utterly essential to developers using Oracle (and, I would guess, DB2). It’s not quite utterly necessary for SQL Server developers who have access to one of the higher-end Visual Studio SKUs. But… ah hah! … it is available for MySQL for free. (Irritating registration required: still worth it though.)

The Jolt Awards are the major industry award for software development tools (compilers, libraries, etc.). One problem we face every year is proper classification of tools. Traditionally, we try to refine / fine tune the previous year’s categories (Development Environments; Libraries, Frameworks, and Components; etc.). Problems arise frequently balancing the number of products in a category (20 entries in one category, 3 in another), when clearly competitive products end up in different categories (happens all the time with categories “Web Development Tools” versus “Development Environments”), and when a product cuts across categories.

Brainstorming yesterday, we wondered if it would not be better to generate the categories dynamically. One idea was to use checkboxes for predefined activities (“defect tracking,” “code generation,” “GIS mapping”) and use some form of entropy measure to divvy them up into our 12-or-so categories. Easy enough mathematically. Another, more dramatic idea, was to create a tagging system for software tools and see if we could come up with a more dynamic view. The main challenge we see is that it seems like a small world: there are only a few hundred tool releases every year and it’s difficult to imagine many people becoming engaged in the task of tagging them.

Do the Web 2.0 dynamics of distributed collaboration apply to small numbers? A del.icio.us for software development tools?

My favorite technical book of the past year was Practical Common Lisp by Peter Seibel. Believe me, if it could convince me to return to Lisp, it’s a well-written book.

However, all the cool kids are learning Ruby. Ruby has some Lisp-like flexibility in comparison to more popular languages like Java and C#, but it doesn’t have Lisp’s elegance / terseness of syntax. If you want to learn Ruby, the best book is Programming Ruby: The Pragmatic Programmers’ Guide, Second Edition.