| The purpose of computing is insight, not numbers. --Richard W. Hamming | The goal of computing is automation, not interaction. --me, with apologies to Hamming |
Software development environment criteria:
|
If computers aren't reliable, then they can't be depended upon, and their prime asset of mechanically and perfectly repeating programmed procedures is lost. Not only that, we waste astronomical amounts of time trying to figure out what is wrong. To attain reliability, we need to start with a reliable operating system, and then we need to insist on high reliability in the application software that we obtain or write.
Those of us who learned computing under Unix already know about reliability, and many of us strive to attain similar reliability in our software. Unfortunately, many people learned computing in the buggy and unreliable world of the old Mac OS (version 9 and earlier) or Windows. These operating systems are not reliable enough for me to use; Linux is a free alternative for both which is much more reliable. (Note that the newer Mac OS X is based on a form of Unix, and recovers the missing reliability. Not only would I consider using OS X, I actually bought my daughter a computer using it for college.)
The application software which runs on Windows generally attains reliability comparable to the operating systems themselves, and marketing features becomes more important than releasing defect-free software. Well, enough about reliability (I should say, don't get me started). Unfortunately the pervasive viruses and spyware exploit Windows defects to make everything much worse.
If we want to move forward toward the ultimate goal in computing, we aren't looking for fancy interactive environments. The underlying engine of our computing should be something which is programmable so that another program can control it in an automated system. Forcing people to load a large interactive program and type some minimum number of mouse clicks is not always the best way to go.
As a simple example, people ask me why I don't use Framemaker or Microsoft Word to create documents. The reason is simply that their proprietary file formats make it very difficult or impossible to control them with another program. I use DWB (Documenter's Work Bench), which, like TEX or HTML uses simple text file inputs which are easily created by a program. When I make a viewgraph describing one of my radar databases, everything is fully automated. I don't need to look at anything until the viewgraph comes out of the printer. That's less work even than using a powerful program like Framemaker. Look into groff for a free clone of the DWB system, which has most of the DWB features and which I sometimes use.
If you have been working with computers as long as I have, you know the value of portability. In general, computers and computer companies come and go, and if you can move your stuff from one to another it can only help you. For years I was the only workstation user in my group who didn't have an SGI workstation on my desk. In 1991 I bought an HP; it caused me no significant problem to port my programs to this new machine when I got it, and it was much faster than the SGIs at that time. In 1997 I replaced my HP with a dual processor Linux box. (The HP I replaced wasn't the original 1991 model; I had upgraded it once in the interim. The Linux box had a better display than SGI or HP offer, and I used to run it at 1536x1152 at 95 Hz refresh.
Microsoft didn't invent the concept of locking people into proprietary extensions of programming languages; the major computer vendors have been doing it for years. I have always refused to bite, and it has saved me a lot of trouble over the years. (Many organizations face major crises in porting software away from obsolete hardware.)
Well, we have some guidelines, and some things not to do, but how do we develop software with high productivity? First, avoid developing it at all if you can. Second, be ready to do some rapid prototyping, especially at the user interface level. Learn about scripting languages, as discussed in the white paper by John Ousterhout, the preface to the book Advanced Perl Programming by Sriram Srinivasan (1997), and the web document by Nat Pryce. (Another version of Ousterhout's paper is published in Computer Magazine, March '98, Scripting: Higher-Level Programming for the 21st Century) pp. 22-30.) If you can glue together some available, reliable components, with a script of some kind, you can change things around rapidly and you get very high productivity.
We use tcl/tk for developing GUI software. The C component of the project goes into the interpreter, and most of the code is implemented in tcl or object-oriented incr tcl. This gives us some fantastic capability in very little development time. For non-GUI-oriented stuff, perl can do the job. Some of these systems can be whipped together mostly in perl, with a couple of small C programs if necessary for high speed. Perl is fast in its own right, and is a full-featured programming language which can do things like read binary data. Similarly, python is a newer alternative. It has some funny syntax things, but is perfectly usable for scripting. Ruby is even newer, and is known for its ruby-on-rails system which enables writing rapid database-backed web apps by using a default database design.
So can't I be more helpful than that? Sure, I will--after all this is my personal web page, not company policy! If your company, group, or family (whoever is around when you are writing programs, in other words) has a preponderance of tcl, perl, or python gurus, then I recommend that you try that language. The support can be invaluable. If you're on your own, I'd go with tcl since it's probably the simplest to use. If you don't want tcl I'd lean toward python before perl. If you're doing web work, then Ruby or PHP could play a role. (Disclaimer: I did use perl for quite a while, but never actually have used python, Ruby, or PHP.)
You may have noticed that I have said nothing about Java. Aren't I aware of the fact that Java is the greatest thing since sliced bread, suitable for everything from embedded devices like cell phones to web browsers, to large scientific apps? Well, I'm aware that people say that. The reality is that Java is a good language to learn the basics of object-oriented programming, so most universities teach it heavily. They graduate thousands of students who know Java best and give it additional momentum. Sun has certainly promoted it heavily. But it's a heavy-weight tool with very complicated libraries, and mediocre performance and productivity. It was supposed to be highly portable, with a slogan of "write once, run everywhere," but I more often hear "write once, debug everywhere."
Sure, if you need to write a couple of small programs at a company which has a Java expert in every cubicle, it might make sense to use it. If you have a cell phone with embedded Java, you may have no choice but to use it. But the original IBM PCs came with Basic, so a lot of programs were written in that for compatibility, not because it was the world's greatest language, even then. The reality is that the top software hackers have abandoned Java in droves, and often switched to dynamic scripting languages. These guys know what works best, and it's always educational to see what they are doing!
For example, we have a system which accesses a Sybase database to display radar and photometric signatures of satellites. These are compressed data ranging from 10 to 30,000 points. We need to display some tables from the database, as well as modify some fields, and uncompress and display the data. Using tcl/tk and incr tcl along with extensions BLT to plot graphs and sybtcl to access the database, we put together a prototype in just a few months. The vast majority of the code being executed is reliable, well-tested, freely available components of the packages mentioned above. The few things which need to be done rapidly are done in a few thousand lines of 'C' which were added to the interpreter. We are easily able to modify the user interface with high level incr tcl coding.
To provide a user manual plus on-line documentation, we write the documentation using DWB, and use a tcl script to translate it into HTML. Then the same document can be either printed or displayed with the itcl html viewer or a web browser, complete with hypertext links. (The latter are included by defining a DWB comment syntax (.\"H) which is ignored by DWB but translated into the appropriate HTML by the tcl program.)
So what about using free, public domain, or GNU license software. Could this stuff possibly be reliable enough to satisfy a reliability fanatic like me? Doesn't the lack of support make using this stuff impractical? No, exactly the opposite is true. With source code available, I can do my own support if I need to. There are also consultants and companies out there who support scripting languages like tcl/tk. The net is a great source of support in the various newsgroups like comp.lang.tcl and comp.lang.perl. Most importantly, more people use this stuff than use most proprietary software, and many of them are top programmers who improve the software, find bugs, etc. As a result, I find that the free systems such as Linux or tcl/tk are usually more reliable than proprietary systems. For more info, check out the article The Value of Free Software by Jon Udell from the December 97 Byte magazine, pp 109-112. See also the the web paper The Cathedral and the Bazaar by Eric Raymond for some interesting first-hand experiences as well as insights into the free software process.
But of course many companies are on the open source bandwagon these days, and there are a ton of references newer than the above. If you're not aware of them, consult Google. Even the US Government (and many foreign governments) are using open source much more.
So it directly follows from the above that we can identify a few good and bad ideas, for fun only. The proofs are left to the reader. Of course many great computing ideas become obsolete in time. (I have some wonderful analyses of the merits of Fortran, Lisp, Eiffel, PHP, OS/2, etc., but this page is too small to contain them.)
Good ideas:
|
Mediocre ideas:
|
Bad ideas:
|