Saturday, March 27th, 2004
Lately I've been hearing all kinds of people say "Linux doesn't have a decent IDE". For those that don't know: an IDE is an Integrated Development Evironment, which means that you get a tool that includes all kinds of other tools with which you can easily develop programs. It's kind of like a mix between an editor, debugger, compiler, etc. Most of the time these users also mean that Linux doesn't have a decent GUI builder also known as a Rapid Application Development tool. They want stuff like Delphi, Visual C/C++ builder, Java builder or some other clickety-click 'programming' enviroment. And they're right, Linux doesn't have one. And that's a Good Thing.
Why is that a Good Thing? Because programmers are lazy. Now, usually that's a good thing. A lazy programmer is a good programmer because they don't want to do stuff twice. This forces them to create all kinds of neat stuff which they can re-use later on. On the other side, being a lazy programmer is a Bad Thing. Some programmers don't want to think about design or underlaying structure of programs. They just want something that works.
So, what does that have to do with RAD (Rapid Application Developement) tools? A lot. Today's RAD tools like Java Builder or Visual .NET allow you to click around a bit and put together a nice interface. Then you double click some button and add some code to load some things into some list somewhere. Double click another button and make it write the information in the list to a file. You're happily clicking all over the place, adding some code here and some code there, but you've missed a very important thing. You're mixing the logic of your program with the interface! In expensive manager-speak: You're mixing Business Logic with Presentation Logic. Ouch, that's a very bad thing.
One of the most important (and incidentelly one of the least tought lesson in IT educations) leasons in programming is: Low coupling! What?! Low coupling! Let me explain by quoting my favorite piece of programming-related writing, The TAO of programming:
"A program should be light and agile, its subroutines connected like a string of pearls." — TAO of programming.
The pearls are your Business Logic. The string is the interface. It's as simple as that. One pearl for loading a list of data, one pearl for the list (not the list you see on-screen but the list in memory) itself, one pearl for saving, etc. The user interface is the string which connects the pearls. From the load button, which calls the load pearl to the list you see on-screen which calls the list pearl.
Suppose you've mixed the business logic of saving the list into the save button. What if you want to extend your program so it can be controlled remotely via the network? You would have to move the logic of saving the list to a seperate function and have the save button and the remote save method both call that function. In the end, you are still decoupling your user interface and business logic. So why not start out with low coupling in the first place?
Of course it's perfectelly possible to write low coupled applications in Rapid Application Development tools, but they make it sooo easy too just add the business logic into the user interface. I once said to a proffesional programmer: "Then you add a function there to do this and that" and he replied: "Uhm, where's the button for adding a function?". Excuse me?
Most good open source developers know about low coupling. They also know about the power of the current tools for developing programs under Unix. They know that NO RAD tool can beat the development power of Vim or Emacs or some other advanced editor. Want to compile stuff from your editor? Vim does that. Debugging? Vim does that too. Advanced Unix editors do all of the stuff an 'IDE' can do and much much more. Except for designing an interfacei by dragging buttons onto some window. And that's just the way most developers like it. That's probably why there aren't any RAD tools for Linux like there are for Windows.
And besides; coding your interface from scratch isn't that hard to do at all. And because you have to actually assemble the interface yourself, you get a much better understanding of the underlaying code. Extending your program will become easier and faster. No more copy-pasting of code from all over the place and ending up with the same piece of code in four places all over your program.