The Fnordistan Department of Software Engineering

I have been writing programs in Smalltalk at home for my own edification, while in my regular job I am mostly working in Java nowadays.

When I first started learning Java, I had no idea — no idea — just how much Java owed to Smalltalk! I still didn’t really appreciate it until recently, when I started digging into Smalltalk more seriously. From the notion of everything descending from “Object” to garbage collection to the inheritance model to polymorphism, almost everything Java does is basically aping Smalltalk. Often not very well. I am using Java’s Collections a lot, and even though Collections are a relatively new transplant from Smalltalk, compare this:


for (Iterator iter = myList.iterator(); iter.hasNext(); ) {
myThing thing = (myThing) iter.next();
thing.doSomething();
}


with this:


myList do: [:thing | thing doSomething ]


I’m not just griping about syntax here; which one, conceptually, looks and feels more elegant, more intuitive? Look at all the method calls and casts you have to do just to iterate through a list of arbitrary objects in Java.

That’s the sort of thing I didn’t really notice until I started working with Smalltalk. Now I shake my head and wonder how much better life would be if it had been Smalltalk rather than Sun’s Java that had been poised to catch the wave in the 90s.

Now, some Smalltalk constructs still feel more awkward to me than the Java equivalents. For example:


if (boolValue) {
doThis();
} else {
doThat();
}


feels more intuitive to me than:


boolValue
ifTrue: [ doThis ]
ifFalse: [ doThat ]


But I realize this is a matter of taste, and being more comfortable with familiar syntax.

Frankly, I like Perl’s flexibility even better in this regard:


doThis() if $boolVal;


or


$boolVal or doThat();


Actually, this is all a good argument for programmers to be multi-lingual. I don’t think anyone can be a “master” of any language until they are fluent in many.

Here is a good article on the advantages of dynamic typing. I am becoming convinced that the “advantage” of static typing is that it provides minor babysitting services for bad programmers. Try writing a Java package that performs all sorts of calculations with int, double, float, and long data types and has to go back and forth between them…. the need to cast, convert, and develop special ways of handling “loss of precision” will drive you nuts.

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 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.