IDEs, education and the UNIX philosophy

I’ve never really been a big fan of IDEs, though I can appreciate how they can help speed up the Edit-Compile-Test cycle. For almost two years now I’ve been trying to use a text editor + command line strategy. However, at the moment I’m in a position where I need to start using IDEs again. In particular my software engineering class uses KDevelop and over the summer I’ll be working on a research project developing an Eclipse plugin, so I need to get familiar with Eclipse before then.

I must say that I was initially put off by the idea of having to use Kdevelop for C++ development in my software engineering class. I was really hoping to be able to use Emacs, GCC and make full time, adding to my current level of Emacs and BASH knowledge. But I have been using KDevelop for about 2 weeks now (somewhat grudgingly I must admit), there are a number of things that KDevelop makes rather smooth. Creating an SVN repository for your project and committing to it is rather well integrated with the interface. At the same time, you can’t directly checkout out a working copy and start working on it as a project: you need to check it out manually to a directory, import the directory as a project and then edit the project options to have it be version controlled. Not exactly a very smooth workflow. KDevelop’s integration with the Qmake program to automatically create Makefiles is also a time-saver. Makefiles are files which contain instructions (used by a program called make) to build large projects containing lots of files. However it is very tedious to write these Makefiles by hand and KDevelop mostly takes that trouble away. Though I’m only just starting to explore KDevelop, I think I’ll enjoy using it.

However, on a larger scale, I’m still in two minds on the use of IDEs. I still firmly believe that IDEs should not be used as primarily teaching tools, certainly not in a course like Software Engineering, which is for people who are fairly sure that they will be computer science students. I learned about Subversion before using Kdevelop. I can understand and appreciate how KDevelop helps speed things up and more importantly when things go wrong or the interface doesn’t quite work the way I want it to, I can easily drop into a shell and fix things. However I know much less about Makefiles, since I’ve never really used them. I know enough about it to understand that there is a significant amount going on under the hood which is being kept hidden from me. If something went wrong I’d be helpless to fix it. It’s not a feeling I’m comfortable with. I really wish that we had been told about Makefiles and how they work and then been told about Qmake and how the integration with KDevelop speeds things up. At this point I really hope we learn about what goes on under the hood and do so soon.

One of the reasons that I am uncomfortable with IDEs is that I’m a strong believer in the UNIX philosophy. This school of thought as applied to programs can be stated thus:

Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.

I have some doubts about the text streams part, but I firmly believe in the first two segments. Once again coming back to education, it is important that students learn the UNIX philosophy and learn it well. They may not necessarily be writing completely separate programs for every little thing, but the need to preserve modularity in software is generally acknowledged. By learning how programming actually depends on lots of different tools each with their own functions, but with good interfaces, students can better understand how to write modular software. The IDE encourages the idea that powerful software comes in monolithic chunks. Even if the idea is modular and depends on other programs under the hood, that fact is not always obvious to the student. It is much easier to understand the power of modularity when your tools are clearly modular in nature. Consider Emacs: it is extremely modular and extremely extensible by virtue of it’s embedded Lisp interpreter. When you want to give Emacs the powers of an IDE you string together a number of Elisp packages. More importantly you are actively encouraged to write your own Elisp code to bend Emacs to your own. This flexibility is on a completely different level even when compared to modular IDEs like Eclipse.

I suppose that many of my gripes with IDEs would disappear if they really were integrated. But they’re not. I’m using a bunch of tools for my Software Engineering course: Umbrello for UML, Doxygen for code documentation extraction and Mantis for bug tracking. The only integration here is between Doxygen and KDevelop. This means that designing, implementing and then documenting a feature will mean using several different tools. Umbrello can generate code templates from my UML diagrams, but it can’t update the diagrams as I change the code. That means that when I need to write utility classes or methods, I have to put them in code and then put them in the diagrams again manually. By using an external bug tracker I need to remember to check off on the buglist when I fix something. In a truly integrated environment, the bug tracker would be part of the IDE. As a developer I could then add information to the bug report, such a link to a specific part of the code where the bug exists. Anyone looking at my code later would be able to see that there was a bug associated with that part of the code which had been fixed (or was still active). Of course, this would mean that version control would have to be really tightly integrated so that all the changes ever made could be pulled up and compared at a moment’s notice. If I need to play the juggle-the-program to do my work, I would much rather use distinct programs and tie them together with Elisp or BASH script. In such a case a common text interface would be very useful. UNIX philosophy wins again (to some extent).

Of course, I am picking on the tools I’m using and that may not be a representative sample. I’m also aware that KDevelop isn’t exactly the gold standard in IDEs. At this point some open source enthusiasts will be pulling out the do-it-yourself card: if you don’t like the state of KDevelop, write some code to fix it. An understandable argument, and normally I’m all for it. Do it yourself is a lesson well worth learning if you’re in the technology field. But in this case, I feel it is somewhat besides the point. Like I said, I’d rather just use Emacs. That’s not to say however that I won’t ever be swayed. Right now, I would willingly use an IDE if it unified the tools that I’d be using and actually sped things up.

Ultimately it comes down to the simple fact that as someone who intends to write software as a livelihood (or as part of a livelihood at any rate), I insist on using the best tools for the job. Right now that tool is Emacs + GCC (and all the supporting tools like make). If an IDE does come along that offers me the same customizability and raw power that Emacs, I would not hesitate to give it a fair chance to prove itself. This is not to say that Emacs doesn’t have some problems, but it’s better than the competition for my use. On the same note, I also wish very much that my fellow students would learn to understand what really makes a tool powerful. However considering that one of my classmates commented that he doesn’t like the terminal because of how much he has to type, I don’t think that will happen anytime soon. Education in computer science deserves a good few posts all to itself, and it has it’s own very large set of problems, but if you actually are reading this post, I think you already have enough knowledge to know when your tools don’t quite cut it. Just make sure you act on that knowledge.

9 thoughts on “IDEs, education and the UNIX philosophy

  1. However, not all could appreciate Emacs. Not because of its weaknesses, but, the long learning curve. BTW, IMHO, it doesn’t matter what you use to program, but how you program it.

    p/s: Long time ago, no IDE nor Emacs exists, just cards with hole. 😛

  2. I feel the same way. I am an emacs+console user and have tried multiple times to use IDE’s to do my job. “Integrated everything” is really nice for things like prototyping etc, but it shields the user of the IDE from what is really going on in all the steps of the development cycle. That IMHO hurts the user as they may not fully understand what is happening across programs and processes. For me, giving a dev the use of an IDE means trusting they understand CVS, MySQL, html, php, javascript etc on their own and most importantly how to work with the pieces outside the context of a web page. (debugging, rolling backs, benchmarking etc)

    “I have some doubts about the text streams part” – Not sure why. ( The man who coined the phrase you quoted (Doug McIlroy) based pipelining on “Standard Streams” which equaled the connection between the program being run and its environment. Standard streams (std{in,out,err}) are texual.

    “I have some doubts about the text streams part” – Not sure why. ( The man who coined the phrase you quoted (Doug McIlroy) based pipelining on “Standard Streams” which equaled the connection between the program being run and its environment.

  3. Hmm… so you want strong integration huh? You could try gasp Microsoft Visual Studio for development. 🙂 Microsoft is the king of integration yep these guys even integrated a web browser into the OS. I know…I know sacrilege you are only l33t if you use tools with a decades old user interface design.

  4. I somewhat disagree. Have you ever tried building a medium-large-scale application (say, a project with 50-60 classes) with emacs and gcc? I’m sure it’s possible, with persistence, but at some point, I would totally lose track of everything. I tried building Servlet/JSP with emacs and ant and it was terrible.

    The one thing I would agree with though is not to rely on the IDE for everything. I use the IDE to help me with remembering dozens of library functions and classes I can’t be bothered to memorize, and to view the overall state of a project–class organization, version control, UML diagrams, use cases, documentation– and as Byron said I feel I know enough about these tools to benefit from the use of an IDE. Try doing all that with Emacs. It’s simply impossible.

    My take on this is that once a programmer gets accustomed to them, tools like emacs and make are best used on an as-needed, fine-tune basis–the bulk of work can be done in an IDE. The IDE doesn’t exist so that people can slack off from learning emacs, vim, or SVN. It just makes the job easier for those of us who have enough experience with those tools.

  5. Thanks for all your comments. I’d just like to point out that the to-IDE-or-not-to-IDE debate is still far from settled. Sometimes they are the best tools, but sometimes they’re not. It’s productivity and easy of coding that matters.

  6. “Consider Emacs: it is extremely modular and extremely extensible by virtue of it’s embedded Lisp interpreter.”

    This is a strange thing to say in a paragraph talking about the Unix Philosophy, since Emacs comes from a completely different culture (MIT/ITS/Lisp vs Bell/PDP/C) and is virtually the antithesis of the Unix Way (everything in one process, communicating by function calls with rich data types).

    I love Emacs as much as anybody, but I wouldn’t claim it has anything to do with Unix. We even had a funny name for the Unix port of Emacs (“Gosmacs”) way back when that wasn’t the common place to run it!

    P: “Have you ever tried building a medium-large-scale application (say, a project with 50-60 classes) with emacs and gcc? I’m sure it’s possible, with persistence…”

    Yes, I’m working on a large system right now — not in C, but it has over 600 classes, and I don’t know what an IDE could do for me that Emacs can’t. find-tag is just as fast with 600 classes as with 6. Macros make O(n) editing tasks into O(1) editing tasks on any size project.

    What specific feature of an IDE helps you here? Everything I can think of that IDEs brag about, I do in Emacs every day.

  7. grep and ctags FTW!

    I’ve tried Eclipse CDT’s indexing, but it always takes ages, then doesn’t actually find anything!

    With ctags it takes seconds to create the tags file and always jumps to the right place. cscope is cool too, but I find grep -r (or lately, ack) is usually a faster way to find the places a function is used.

    And I *hate* IDEs that change files behind your back. Eclipse is especially guilty of this.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s