Taprats: Computer-Generated Islamic Star Patterns Design Notes


This page contains some notes about the development process and what I like and don't like about Java. Most of it is pointless rantings. Feel free to skip it...

Taprats got really big really fast! I was aiming for about 5000 lines of code. The whole system weighs in at 12540. Mind you, that includes extensive commenting.

Anyway, It's a testament to Java that I was able to construct such a large system in so little time. Here are some things that help:

The package system
Java does modularity really well. Having the package system around greatly simplifies the organization of a project's sublibraries. Also, knowing it's there is a big incentive for thinking about how to best factor your code into packages. Associated with this is the broad range of access specifiers, including package-level access. I think there are probably too many of them, but having learned how to use them, they're very powerful.

I've tried organizing my C++ projects in a Java-like package structure, but the overhead is just too high.

Multiple entry points
I love the fact that I can throw a main() into every single class I write and test that class as a unit without building a make file, linking and maintaining a whole big separate dang program. It's a lightweight way to get the benefit of unit testing. A quick check reveals that in the Taprats source code, there are 37 mains defined in 66 files. And Taprats isn't even an application! I challenge you to do that in C++!

Inner classes
I'm sure we can all agree on the benefits of inner classes, both anonymous and not. I find they're tremendously useful during development. They allow you to insert the code you're thinking about while you're thinking about it. You don't have to go to a distant place in the file to write a helper class. You can insert it inline as you're writing the surrounding code. It's one of the best ergonomic benefits of functional programming, here in the OO world.

I have only one request, Java people: have a way to specify a constructor in an anonymous inner class. That would be the last barrier towards total utter coolness. It demands some sort of new syntax (perhaps Python's __init__?) but it's worth it.

Exceptions with stack traces
I love these! Often, a stack trace is all I need to find a bug in my code. And I don't even need to think about it. If there's a bug, out comes a stack trace. This makes a huge difference in productivity, and after returning to Java after a long C++ project, I feel like I'm making fewer serious errors and the ones I make go away faster.

To balance out all those good things, here are some things I don't like in Java, or at any rate didn't use:

Java 2
You'll notice the conspicuous absence of anything from Java 2 in Taprats. Most notably, I don't use the Swing components and I don't use Java2D, which seems like a crime given the graphics Taprats does.

Look, the Java people have done tremendously good work in advancing the Java state of the art. They haven't let the project get away from them. But I don't think the new stuff is ripe yet. My officemate is using Swing for a very large project and it still seems a bit clunky without offering that much over plain AWT. I'm all for the philosophy and design, but Java implementations and the library itself need to mature a bit.

As for Java2D, I was very excited when I first heard about this project a few years ago and I did everything I could to wait until it was ready so I could pounce on it. In the meantime I needed something to let me do my research in geometric art, so I wrote the code that eventually became GeoView. Given the limited kinds of 2D graphics I'm doing, I don't have a compelling reason to switch over to the heavyweight Java2D yet. But I'm looking forward to using it for some future project.

Finally, let's not overlook the pragmatics of the situation, summed up in the three Ls: Learning curve, Legacy and Linux. I am familiar and comfortable with the 1.1 AWT and don't want to jeopardize a project like this with a failed attempt to transition to Swing. I can adapt some classes I've already written from other projects to do what I need to do. And I do it all on Linux, where (at least up until recently) the state of the art was lagging so far behind that I had no recourse for learning the new libraries.

Java IDEs
This project was developed using the command-line 1.1.7v3 JDK from blackdown. And yes, every single file in this project was edited with vi. I'm not a die-hard vi fan (even Bill Joy said recently that he marvels that anyone still uses his editor) -- it's a simple learning curve issue again. I'm very efficient with vi -- it's built into my fingers. I believe in emacs, it's just hard to move to it when it slows me down so much.

As for IDEs, I have yet to try a single IDE that even makes me come close to leaving a simple text editor. They have awful user interfaces and mouse-centric editors. The useless features consume real estate and the good features hide in some dark corner. Really the only thing the IDEs have that I want is a debugger. I've never been able to get Sun's JDB to work. I eagerly await the completion of the Java front end for gcc. Still, debugging print statements work very well in Java given the combination of stack-traces-on-the-fly, and rapid compilation times with no linking.


Last modified: