Well, it’s official, Jer’s Software Hut is a multi-product company. Someone went to the trouble to slide me five bucks for Jer’s Flash Card Viewer.
As I prepared the key file it occurred to me that the whole key system in the viewer hasn’t really been tested that much. In fact, I couldn’t quite remember how it was supposed to work. Had I made it so that double-clicking the key would work, or was it using the old drag-to-the-folder method? I played it safe with the instructions, generated the key, and sent it off.
Thus opens a grand new revenue stream for the Hut. With the dollar continuing to tank it is only worth about three or four beers, but that should cover my bar tab tonight when I go to hear a friend do some sort of musical act.
If I was smart, I’d use my connections in the textbook industry and get one of them to include JersFCV as a supplement to a language textbook. The downside is that it would cost me a chunk of cash and time to even start working on a Windows version. Whoever paid me would have to foot the development cost.
In fact, after writing the above I composed an email to my former boss in the Educational Software Biz. If he wants to sell Jer’s Flash Card Viewer to his clients, I’m sure not going to stop him.
OK, this whole comment — don’t bother reading it. It’s just me thinking out loud about programming in Java. You don’t care. Really.
Contemplating making a Windows version of JersFCV leads me to consider redoing the thing using Java. Speed shouldn’t be a problem for this guy, although there is quite a bit of math after each card to reprioritize the deck. Still, I expect the sorting and math will be fast enough. It’s not that Java is inherently slow (it’s a bit slower, but not that much), it’s that every Java code library I’ve even met really stinks when it comes to performance. (A code library is a big pile of stuff so that you don’t have to reinvent the wheel – if you want a slider you use the one from the library.) Which brings me to another thought about java code libraries. All the ones I’ve met are visually horrible. Think Windows 2000 and make it uglier. Yeah, they’re that bad. Still, it’s been a while, and I imagine that as computer operating systems have been working harder to make visually appealing interfaces (while on many applications hiding functionality in random places, but that’s a rant for another day), so perhaps the Java libraries have also improved.
I told you not to read it.
I didn’t read it per se I skimmed it and saw Java all over the place and thought, “Hmmmm coffee” in a Homer Simpson-esque internal voice.
Congrats on sale of Jer’s bits and pieces.
I have had this conversation in a professional environment many, many times. The conversation always (always) goes like this:
Non-Java Programmer: “Java is slower.”
Java programmer: “Usually not. Look, here’s a benchmark I put together, one in Java and one in [other]. See? The Java is faster.”
NJP: “What? Oh, I see, you did this (easy thing). You need to do this (optimization). See? The Java is slower.”
JP: “Well, if we’re going to start sacrificing readability for speed, I can do this, and this. Java’s faster again.”
NJP: “Impossible! There are all sorts of optimizations I can still do.”
[days pass]
NJP: “There! Here’s this (ridiculously optimized, unreadable, unmaintainable mess). But there’s no way you can get faster than this in Java.”
JP: “Uh, yeah, you win, I guess. Meanwhile, I completed the project in Java, and it’s pretty responsive. I did have to optimize (something that was measured as a bottleneck), but that only took a couple hours.”
In short, it’s true that other languages (typically, C++) can be made faster than Java, but it’s no longer true that C++ generally out-performs Java out of the gate. The STL in particular is a performance hog. The glaring exception to this is the garbage collection pause, which is usually not a problem unless you’re doing something heavy duty (and on server side development, there are lots of tricks to mitigate).
Finally, I have used some very polished UI programs written in pure Java (the Eclipse IDE is the best example), so I know it’s possible to do. I have no personal experience with this, however.
One performance metric that people don’t consider until too late is the time it takes the application to get out the door. Are you willing to spend extra man-months in development to save a few fractions of a second here and there during execution? For time-to-door benchmarks Java is excellent. Garbage collection is a big part of that.
I’ll take a look at Eclipse. Back when I wrote a still-unmatched Web application in Java, I ended up rewriting some pretty fundamental classes in the AWT to improve performance. There were other classes whose very existence was perplexing to me, ones that broke the same design patterns they were intended to enable. Swing was just getting started back then, and sucked mightily.
And dude, there’s no way that your c++ code can be faster than this super-optimized c routine. (Would the assembler programmer please step forward?)