Frank Schacherer Homepage
home technology bibliography

Programming Tools


"Ein Mann, der recht zu wirken denkt,
muss auf das beste Werkzeug halten." (A man who wants to do good work has to look for the best tools.)

- J. W. Goethe

This page holds a list of useful tools, mostly free software with short descriptions. Some of the non- free stuff is things that I used.


One of the main problems when developing on Windows and Unix at the same time is the different shells. Therfore Cygwin has to be the best thing since sliced bread. Cygwin allows you to use the Unix toolkit (make, less ..) and command names (rm ..) on your Win32 box. I'm not using the Bash shell that is supplied with it, though, but the normal "MS-DOS" shell with filename completion active (by setting HKCU/software/microsoft/command_processor/CompletionChar to 9) although it's not as smart as the Unix completion, it just grabs the first match it finds, not asking for ambiguous ones. For testing it might be worth to use bash and avoid to learn DOS-Style. A comparison between syntax and toolnames for Windows/Unix shells.


Your editor is where you will spend a lot of your time at the keyboard - or maybe all of it if you are using Emacs. GNU Emacs. This is my editor. Probably the most powerful editor of them all, because it is fully extendable and programmable. For every need there is a specialized mode - you can see some that I use here. Unfortunately it has a steep learning curve and other key-binings than standarrd Windows.

Vi. The Unix editor. This comes with almost every Unix flavour, but is even more arcane to use than Emacs and not as easily customized.

UltraEdit. This shareware editor is the best I have seen on Windows to date. It is extremely intuitive, user-friendly, configurable yet mighty. It has syntax coloring and a hex-mode, plus all the standard Shortcuts, Find in files, Regex, File-Compare etc. TextPad is also nice.


Graphical CASE tool usually have an integrated default editor which you might be able to switch to your favourite one. They integrate your work needs for editor, compiler, program execution, reference and debugging. And write some of the code for you, which often is quite crappy. Actually, the single step debugging is the main reason I use one. These tend to be commercial.

JPadPro. This is shareware and the best and most honest IDE for Java I have seen to date. Just uses the JDK, does not do some voodoo behind the scenes you don't control, easily configurable, with comment folding and a very nice tree for your packages/classes. The only disadvantage is that you cannot use another editor.

Nowadays, Eclipse is probably by far the most popular and powerful IDE platform, not only for Java -- and it is free.


Perl, the 800-pound gorilla of scripting languages. For small works glueing several programs together there are many mighty tools on Unix, like awk and sed. I use Perl to avoid learning them all, as you can do it all and more in Perl. It's also the favourite skripting language for CGI. And it's available on Windows, too.

Java. SUNs javac, java is object-oriented and portable with ample GUI support. It also used to be slow, but apparently not any more. I used to code Java a lot during my Ph.D. work.

Python. Python is a hell of a cool language. A fully object-oriented script language, complete with regular expressions, ultra-clean syntax and many built-in lisp like functions it combines the best of Java, Perl and Lisp into one neat package. Here are some notes.

The shells. Often a small shell script can do what a perl script could. I find the syntax of sh annoying, so I have a cheat sheet.

Lisp/Scheme. It's built into Emacs, so knowing a little is useful if you use Emacs.

Source Control

Source control makes it possible to work with several people on the same source tree, or to back up to a state where everything worked. Together with a bug tracking/change request software, you can develop in a coordinated way. A common system is CVS, which recently has been replaced more and more by subversion.

git is another popular, and more modern tool. I feel it is more complicated to use than CVS, but it has some advantage in making it easier to create and merge branches, and through this, it allows you a review step before adding code to the central repository, because you can make a branch, make changes, then ask a maintainer to merge it in (even when you have no rights to do so), and he will be able to diff and see what you did before it goes in.


Good documentation is important, because it helps you to think about your code and helps you to understand it later. I use normally what the language supplies as default. Javadoc with Java, or Perl's POD (plain old documentation) are both O.K.


The good thing about dedicated build tools instead of plain scripts is that they allow you to enter at different places in the process without commenting out code or changing your script, and that they figure out everything that needs to be re-done based on explicit dependencies.

make. There are multiple versions of this tool, the normal make, GNU make (which is the most widely used) and under Windows NT nmake. Since you can use make instead of nmake with Cygwin, and Windows has stuff like InstallShield, its probably not worth learning nmake. There are big books about make, but for 80% of your needs you can get away with 20% of the syntax. Here is a simple annotated example of a makefile. I actually only use it under UNIX - it's more of a UNIX tool I guess.

Nowadays, Ant seems to be the build tool of choice for Java types. I did not find it offering much of an advantage, forcing you to write Java classes.

Debugging, Bug Tracing, Profiling

Each language tends to have it's own tools. The default profiler that goes with perl is pretty ok. I usually keep to Kernighan's advice and think about my data and how the error can occur, than use a few interspersed print statements to track it down.


Here, you have to construct your own test cases and scaffold. The main point is that you have to automate this, or you will not do it enough. To automate it, you have to write test input and output files and skripts that compare the the output of a new version to the prepared one, to ensure nothing has changed. (Regression testing). Your test skript should be silent as long as everything is ok, only complain if errors are found. To do this you have to learn a bit of shell programming, mainly conditionals, loops, file comparison and length check and testing if a programm returned the ok signal.

Modern languages like Python have embedded unit test support.

Design and Modeling

I used Rational Rose, a commercial tool now owned by IBM for object oriented modeling in UML (and Booch etc, if you're so inclined).