The Fnordistan Department of Software Engineering

I have been using Cincom’s VisualWorks for my Smalltalk programming. It’s a nice tool, but one thing I was really missing was syntax highlighting. Nowhere in VisualWorks’ Application Developer’s Guide is there any mention of syntax highlighting.

Finally, I stumbled across a reference implying that there was a way to do this in VisualWorks, and after a Google search, learned about RB Code Highlighter. This is a package in Cincom’s StORE open repository. StORE is accessible from within VisualWorks, but the documentation isn’t exactly clear. You have to poke around on the Cincom community blogs and Smalltalk wikis and newsgroups before you really start learning about these things.

IMO, Cincom has a great Smalltalk product but they don’t do a good job of marketing it or letting new users know about the tools available for it.

As any programmer knows, a good Integrated Development Environment makes your programming time more productive and more enjoyable. IDEs do not make the actual think-work of software engineering and programming easier, however. As my philosophy of coding evolves, I am arriving at some programming principles. So I hereby present:

Fnordistan Software Engineering Principal #1:

Don’t do it in an IDE until you can do it in a text editor.

I first started learning Java in a teaching IDE called BlueJ. You know what? It hobbled my ability to program in Java until I cast off the shackles of the IDE and realized instead how things worked in the “real world” (inside my computer). I had trouble writing Java code, let alone compiling it, unless I had BlueJ to help me. I didn’t really understand where Java “existed” on my machine, or how I could have multiple JVMs in the same development environment, or how you dealt with things like classpaths and external libraries in JAR files.

When I finally took the time to do my coding in a plain old text editor (OK, I used vim — it’s cruel to expect even a beginner to do without syntax highlighting, at least!), and ran javac and java on the command line, things began to make sense. My IDE-constrained conception of “Java programming” fell away, and what now seems blindingly obvious came as revelation and increased competency.

This is not to bash BlueJ — I understand that it is a teaching tool, and it’s primarily intended to teach Object-Oriented concepts, not Java. But I didn’t really understand that at the time, and I chose BlueJ because all the “professional” Java IDEs intimidated me (as well they might a beginner!).

But the fact remains, operating solely within an IDE can leave you as a programmer “tightly coupled” to that IDE. I have even seen it happen professionally. Developers who do all their work within an IDE flounder when they have to step outside of it.

Now, bearing in mind all of the above, I love IDEs. They simplify and automate so many tasks, and put everything before you in such a visually appealing and easy-to-browse format, that going back to a plain old text editor and command line can feel like using long division with 10-digit numbers. Why should you, when a calculator can do the same thing in a fraction of the time and with zero chance of error?

But you shouldn’t use a calculator unless you can do without it if you have to. And you shouldn’t program in an IDE unless you can program without one.

I wouldn’t want to do a Java or C++ project without Eclipse or Microsoft Visual C++, respectively. But many times, the ability to step outside the IDE and run things on a command line, or package up a project so that it will build independently of the IDE, has been a lifesaver. (MSVC++ is particularly bad about this; by default it sticks all kinds of Microsoft-specific header files into every project, leaving you unable to compile with any other tool unless you strip them out.) I have become a firm believer in using Ant for my Java projects, and making sure that my Ant build script is set up so that it will run in whichever Java IDE I choose, or right from the command line, without any difference.

I would tell someone just learning any programming language that until they can write a hello world program, then compile and run it, without using anything more than Notepad.exe and the command shell (or on a Unix machine, vi and the command line), without even thinking about it, they should not touch an IDE. Really, they should be able to build at least a small project, preferably with some external libraries, with only a text editor and a command line. Once they can do that, then they can learn the power and convenience of an IDE.

That sounds pretty darn simple, right? Well, I have a sneaking suspicion that for some Java “developers,” that should have been a question during their interview….

(Java Solution)

I’m pleased to announce my first project available for public download: SmallRoller.

It’s really a simple little application, but I am pleased with it, and it’s my first real Smalltalk project.

Feel free to post bug reports or comments here.

I am a computer programmer. I like coding. In the IT industry, coding is near the bottom of the professional ladder. If you want real money, you need to do high-level infosec work, become a Project Manager (i.e. a “suit”), or join a start-up. Some people think of “coding” as little more than typing into an IDE, but I think writing computer programs is a creative endeavor. You should take pride in the code you write. Good code is enjoyable to write and satisfying to reread. You look at it and think “This makes sense” or even “This is pretty clever,” and if it’s really good, “This is some fine-looking code!” Hopefully anyone else who reads it will think so too.

Bad code is hackwork, and you know it when you write it and you really know it when you read it. You can tell when you read code that someone either didn’t have the time or inclination to make beautiful.

Of course, in the real world the objective is to get things done, finish your project, make it work. The end users don’t care about “beautiful” code, and if your code works well, it’s likely that no one else will ever see it, unless you’re writing a library or something else intended for reuse. So of course many people never bother trying to write code as poetry; some probably think the idea is silly.

I want my code to be functional, but I also want it to be beautiful. I don’t yet have the 10+ years of experience that some people say are necessary to become a really good software engineer. But I think that coding, like any other form of writing, requires devotion to the craft to become good. Some people never devote themselves, others have enough natural talent that they start out writing good code. Most of us can never become Big Names in computer science, but we can at least write programs we are pleased with and which are useful to others. I think devotion to the craft requires enjoying it enough that you spend free time working on it, not just doing all your coding at work.

I am very interested in Richard Gabriel’s efforts to introduce a Master of Fine Arts in Software. I have flirted with the idea of going back to school for a Ph.D. in Computer Science, but if there were a program for a Doctorate of Fine Arts in Software, I’d definitely be interested in that.