Extreme Rapid Development

Software development techniques like rapid application development and extreme programming have grabbed the spotlight, and Python, Lisp and Dylan are all languages that emphasize the extremes of rapid development.

They're also examples of interactive, incremental languages. Interactive means you can type in expressions one at a time and see the results immediately (as in a shell or a calculator). Incremental means you can add or modify functions and classes in a running program without having to quit, recompile and rerun.

These three languages are also called dynamic, because they let programmers make lots of changes. If you're more concerned with making fast changes to your software, rather than just making your software run even faster, then these languages may be for you. Dynamic languages are fun to use, because you can see results quickly and feel they're working with you, not against you. And even if you won't use dynamic languages on a daily basis, you can still expand your programming skills by learning the new approaches they enable.

Recently, a programmer at a leading Internet search company proudly showed me how he'd reduced his C++ edit/recompile/run cycle time down to five minutes. But with the IDEs reviewed here, cycle time can be as little as five seconds. And, the incremental changes you can make while the program is running can be substantial ones, not just minor bug fixes.

For example, I once ran a command-line Lisp program, interrupting it when I realized I needed a better understanding of the output. I then spent two furious days coding to replace the printed output with a GUI editor. Once I had the GUI working, I noticed the breakpoint from the original interrupt was still active. So, I let the program continue from the breakpoint—and the rest of the output was displayed perfectly in the GUI. This isn't standard practice for Java or C++ environments.

In this review, I'll examine four IDEs for dynamic languages. ActivePython's IDE is for Python, one of the fastest growing dynamic languages. Allegro Common Lisp and Macintosh Common Lisp are new versions of IDEs for Lisp, the oldest dynamic language, and perhaps the most adaptable. Functional Developer is an IDE for Dylan, a less-well-known language that allows the programmer a range of dynamic and static features.

ActivePython (PythonWin) 2.0
ActiveState claims it's "committed to making Python easy to install and use on all major platforms." The good news is it delivers what the company claims: In just a few minutes after downloading the package, I was executing Python code interactively.

The bad news is that ActiveState has merely done a nice packaging of existing Python tools without adding much to them. Basically, it provides the Python 2.0 interpreter, some documentation and the PythonWin IDE. The PythonWin IDE features an interactive window, a sourcecode editor, a debugger and two browsers—one for Python objects and one for source modules.

The first thing I noticed is that while there is excellent documentation for the Python language, there is almost no documentation on the IDE itself. I e-mailed a query to ActiveState's support line about this, and in 10 minutes I had a reply from Mark Hammond, the main developer of PythonWin, suggesting the best place to look was his book Python Programming on Win32 (O'Reilly & Associates, 2000). Hammond's book is helpful, but even with it you'll have questions about how to use this IDE. Then you'll have to answer those questions by trial and error—so the more experience you have with IDEs in general, the better off you'll be. That is a shame, because with the right documentation, this could be a very good IDE for beginning programmers.

The editor provides customizable syntax coloring, outline-like folding and unfolding of code, smart indentation, and several nice shortcuts to minimize your time looking through manuals and typing in code. First, when you type a "." after a module name, a pop-up window lists the module's attributes (methods and variables).

Second, when you type a "(" after a function call, the function's argument list and documentation are displayed. These features make it easy to remember what is what (at least when you have an idea where to start). If you're uncertain, the Python Path Browser (really a module browser) can help you find the right function. Beyond that, the nice debugger offers the usual features of setting and removing breakpoints, and stepping over and into functions.

In many ways, the PythonWin IDE design reflects that of Python itself. Python is a simple language of surprising power that is easy to learn, and in which a few powerful techniques go a long way. Similarly, the IDE has an excellent set of basic features that work very well for beginners and small projects. You could use it for projects of a few thousand lines or less, as long as they only require limited GUI functionality.

For larger or more complex projects, however, PythonWin has serious limitations. You can customize the colors in the syntax highlighting, but you can't rebind keystrokes, create macros or otherwise customize the environment. There is a multifile grep facility that finds matching lines across files, but there is no global replace function. Perhaps most damaging, user code runs in the same thread as the IDE, meaning that while your Python code is using the processor, you can't interact with the IDE; you have to wait until the code pauses. (You can interrupt the code by right-clicking on the task bar PythonWin icon and selecting "break into running code," but that doesn't always work.)

PythonWin provides complete access to Windows's COM and MFC objects and methods. If you're an experienced Windows developer, you'll appreciate this. Otherwise, you're in for a long, steep learning curve. There is a complete documentation package for every MFC object, but no overview to get you started. And most problematic, there is no visual GUI builder, like in Visual Basic or Visual C++. Instead, you'll need to write all the code yourself, and you'll need outside documentation to get started. Testing the code will be quick, though, because of Python's interactive nature. Overall, you'll be happy with this IDE if you want to use Python to develop small projects or if you just want to see what Python has to offer. But, you'll be somewhat frustrated if you want to develop large projects and are used to professional IDEs.

Allegro Common Lisp 6.0
Like Python, Lisp is a dynamic, interactive and incremental language. But many programmers don't realize that Lisp doesn't need to be interpreted. In fact, Allegro Common Lisp includes both an interpreter and a compiler. The interpreter is intended for typing in short expressions interactively, while the compiler is intended for all routine development. Fortunately, this is easy to do: One keystroke (or menu selection) compiles the whole project, and another compiles the function surrounding the cursor—with subsecond response time in most cases.

You can also incrementally compile or recompile while your program is running. To my mind, Lisp has the better model of incremental change. In Python, when you alter a class and reload, all the old instances still refer to the old class and methods. In Lisp, they refer to the new, updated class.

Compilation makes a big difference in execution speed. I tried the simplest possible benchmark: executing a loop that counts up to 10 million. The compiled function executed in a quarter second—nearly 50 times faster than the 11 seconds Python took (both on a 500 MHz machine). There are some applications where Python's speed doesn't matter, but for those where it does, Lisp offers an alternative.

You can run Allegro Common Lisp in a mode where Emacs is the text editor, with very tight integration between the editor and the running program. Emacs has fantastic support for Lisp, with code coloring, indenting, parentheses matching, automatic indenting, expression-level editing and much more. For non-GUI applications, this offers a very powerful IDE.

However, Allegro Common Lisp 6.0 is designed to be a visual IDE. You start by dragging components from a palette to a visual form, then edit the actions associated with each component until the application is complete. Figure 1 shows the main window with just a few of the components, along with an inspector for the main form.

Allegro offers three main classes of tools: an inspector, a tree browser and a grapher. The inspector, shown at the bottom of Figure 1, lists all the properties and values of an object, and lets you easily move between objects. The tree browser is designed for examining classes, not objects. The grapher gives an alternative view that can help make sense of the sometimes-tangled hierarchy that can result from a language that encourages multiple inheritance. The three tools have the right set of features, and they fit together in a way that works better than you might imagine. The tools are versatile (anything can be inspected, browsed or graphed), and the language has a regularity that the tools help reveal.

Other tools include a "make" system, a profiler that is nicely tied into the browsing and graphing tools, and a cross-reference tool that visually displays the call graph. There is also a toolset for interacting with Java (basically, you can instantiate any Java object and invoke any method from Lisp). I know people who have used a similar system as their main IDE for Java development, because they're able to interactively run methods and see results. Allegro also offers many sample applications, including a Web server and an XML parser.

MFC programmers can get at every MFC object with Allegro, but as in ActivePython, it's not pretty. Allegro offers you the choice of a layer on top of MFC, called Common Graphics, which makes life easier for the GUI programmer; it's a well-thought-out library. Unfortunately, the only thing common about it is the name. It's Windows-only, and no other vendor supports it.

My main complaint about Allegro is that you can't set breakpoints or step on a line-by-line basis, only function-by-function. Lisp is traditionally strong in debugging the language level, and Allegro provides all the basics: easily settable breakpoints and tracing of function entry and exit, and an error handling and restart mechanism that is more powerful and flexible than C++ or Java. To that, Allegro adds a powerful inspector and browser for objects and stack traces. These largely, but not completely, make up for the lack of line-by-line breakpoints.

Allegro is offered in multiple editions of differing capability and price (commonplace these days). The professional edition is the one described here. The free trial edition, which can't be used for commercial development, offers everything in the professional edition, but with heap size limited to 18MB. The enterprise edition adds SSL for secure Web applications and support for database access and Java bean and servlet integration. The enterprise platinum edition adds a CORBA ORB and object database. As a whole, Allegro does an excellent job as an IDE, scaling the range from small scripts up to large professional projects.

Macintosh Common Lisp 4.3

If you're developing on a Macintosh, then Digitool's Macintosh Common Lisp (MCL) is an excellent solution. On the surface, it seems to be more like ActivePython than Allegro. This is because MCL is based on editing text files using an Emacs-like editor, not on visually building forms. However, if you poke around in the documentation, you'll notice the IFT package, an optional tool that is a simple but very powerful visual GUI builder (see Figure 2).

Additionally, the source code to IFT is provided and is only a few pages long—a great example of Lisp's strength. Lisp is what Paul Graham called a "programmable programming language," meaning that if Lisp isn't quite the language you want, you can always implement the language you do want in Lisp. If you don't need a text-oriented IDE, the IFT package reveals that Lisp can be used to quickly create a visual IDE.

One of the reasons Lisp works so well is that it makes it easy to mix data and functions into a single textual form. In MFC and C++, the description of a GUI application is split among multiple resource files, and the code is divided among multiple classes. This makes it complicated and proprietary to keep track of what goes where. In MCL, it's easy to convert a dialog box or complete application into a single Lisp form, and then to edit it either as text or visually. (In Python you can almost do this, but not quite, because statements can't appear inside expressions.)

One of the best features of MCL's interface tool is that it can apply to any dialog. So you can use examples from the IDE (such as the "apropos" dialog in Figure 2) as the starting point for your dialogs. There may be cases where you're forced to edit the code because there is no corresponding visual editor, but the great thing is you'll never get stuck just because a visual component is missing.

The architect Christopher Alexander, grandfather of the pattern design movement, said that a house or town is truly habitable when it's built according to patterns the inhabitants understand. Lisp has a solid core of devoted programmers because it offers a small set of patterns that form a very elegant and powerful design language, a characteristic that led the science fiction writer Neal Stephenson to say "Lisp is the only language that is beautiful." Once you speak Lisp's language, it's easier to come up with comfortable, fluid designs than it is in C++ or Java. On the other hand, it requires some sophistication and an investment in time to learn—one reason Lisp has never enjoyed mainstream status.

The MCL compiler is excellent. The "count to 10 million" benchmark takes half a second. However, when I added one variable type declaration, it only took 0.06 seconds, almost 200 times faster than Python, and the same as the C compiler I tried.

A leading researcher in automated planning told me he uses MCL because it generates code that is just as fast as C or C++, and the development environment is much nicer. Handling of multithreading is also very well done. Even with a Lisp thread running in the background, response to actions in the IDE remains snappy. MCL is my favorite IDE on the Macintosh platform for any language and is a serious rival to those on other platforms.

Functional Developer 2.0 (Dylan IDE)
People used to shy away from dynamic languages because they were "too slow," because the runtime environment was too big, or because they lacked the safety of static type checking. Moore's law, the rise of Java and the fall of RAM prices have mostly eliminated the first two objections (and the first was in part a myth, as the Franz and MCL compilers show). The language Dylan (for Dynamic language) addresses all three objections.

Dylan was designed in 1992 by Apple's Cambridge Research Lab. It was Apple's next-generation language for the Newton and for all dynamic language applications. And because it was originally aimed at a wide range of applications, it offers variable levels of dynamism: You can be almost as flexible as Python, or you can have the static-type checking and run-time speed of C++.

This sounds like the best of both worlds. In many ways, it is. But when the Newton, the Cambridge Lab and much of Apple's market capitalization disappeared, Apple canceled the Dylan project. It was the right decision for Apple, but an unfortunate one for the software industry. This is because Dylan is, in most ways, a technically superior alternative to Java.

Fortunately, Dylan lives on in the IDE offered by Functional Objects. The IDE is clearly aimed at large professional project development, not at the small scripts that are typically done in Perl or Python. It feels like the IDE was written by and for real programmers; it has the right mixture of solid functionality without unnecessary frills.

The start screen offers a choice of starting a new project or opening an existing one (including a nice collection of examples; other IDEs should learn how to make access to examples so easy). The IDE includes a source code editor, an interactive window, a powerful debugger with line-by-line breakpoints, and browsers for the project source tree, profiling information and objects.

There is no visual GUI builder, which is a surprising omission in an otherwise professional product. So you'll have to code your GUI applications by hand, and you'll have two choices: a wrapper for the Win32 API (nicely done) or an abstract window toolkit called DUIM. DUIM's design is excellent and will partially make you forget there is no visual tool. However, you'll bog down if you need the functionality found in the Win32 APIs.

The editor is similar to the MCL editor—simple but extensible. However, it lacks the hints and documentation on method names that the other three IDEs provide. It doesn't color-code the syntax, but it does use color to provide optimization guidelines—a far more useful feature that I wish other IDEs would imitate (see Figure 3). The blue code is optimized, and the magenta code is not. In this case, the problem is that the parameter initial-disks and the field disks are declared to have the abstract type sequence. The color coding is telling you that if you used a concrete type like array instead, then the runtime type dispatch would be eliminated.

Compare this to Python, where every method call has a runtime dispatch no matter what, and you begin to see why Dylan can produce executables (EXE and DLL) that are comparable to C and C++ in size and speed. The argument is that you often end up with even faster code in Dylan, because you can spend more time optimizing the hot spots.

The basic edition of the IDE is a free download. It's the most capable of the free IDEs in this review for command-line applications, but it doesn't include support for any GUI applications. The enhanced edition adds support for CORBA and OLE, SourceSafe version control, the two GUI packages and a few other features. The professional edition adds libraries for database connectivity, networking and others. You can also purchase various libraries separately. The idea behind Dylan—to offer a range of dynamism appropriate to each piece of an application—feels right, and after using Dylan you will become frustrated with C++ and Java. This IDE is powerful enough to give you a taste of Dylan and to develop professional projects.

The Big Decision
Overall, ActivePython will work fine for small, command-line Python programs, but think twice before using it for large programs or GUI applications. Allegro Common Lisp is comparable to other full-featured IDEs like Inprise's Delphi or Microsoft's Visual Studio. You'll have to decide whether the features it adds (like interactive, incremental development and the ability to define problem-specific languages) are worth the features you give up (like line-by-line breakpoints).

Macintosh Common Lisp is one of the best IDEs for the Macintosh OS and well worth a look. Functional Developer offers a tantalizing glimpse of a language that spans dynamic and static languages, but it still has a few rough spots. All four IDEs will give you insight into new ways of developing code, and learning how to use them will make you a better programmer.