David R. MacIver

It has occurred to me that this blog is eminently findable when starting from my name, and that consequently the companies who I’m interviewing with at the moment will no doubt see several rather annoyed rants on computer related subjects attached to said name.

Rather than retract these, I wish to quote the words of a great man on this subject:

(Hotlinking done with permission)

I do hope the existence of these rants doesn’t put you off. If it does, then we’re probably not compatible anyway. Sorry.

David

Rah. Dynamic typing is evil. It lets you do totally unsafe things.

Err, no. Wait, that’s not right. Static typing is evil. It’s ugly and gets in the way and real programmers don’t make type errors anyway, do they? Are you saying you’re not a real programmer???

No, wait. Umm…

I’m so confused…

Want to know what I really think about static vs. dynamic typing? (no you don’t. I’m going to tell you anyway).

I wish the entire goddamn argument would go away.

Seriously, shoo. Buzz off.

There’s no reason there should be a one true language in which you do everything. None. Sometimes language Foo is better, sometimes language Bar is better. Given this, there’s no reason Foo can’t be dynamically typed and Bar statically typed.

Neither is better. Each have their strengths and weaknesses. People have their preferences, tasks have their requirements. Sometimes you’re better off choosing one or the other, sometimes you’re more comfortable choosing one or the other. When there’s a compelling reason to make a decision between the two (which is so much less often than the fanatics on both sides of the argument want you to think), follow that reason. When there’s not, use whichever you prefer.

But, in the mean time, shut the fuck about it. Far too many good and interesting discussions about languages turn into poo flinging between the type system monkeys. Shut up, grow up and get over it. There are more interesting things to talk about in the subject than whether certain operations should fail at run or compile time.

That is all.

Warning: This post contains rant and is short on actual reasoned arguments.

There are a number of things that are often considered bad practice in Java. These include static imports, star imports, shadowing, omitting braces, notUsingReallyLongVariableNames, etc. Also, many Java developers object to features like first class functions, operator overloading and type inference, because they might ‘overcomplicate’ the language and cause people to produce unreadable code.

Given that this is a post about concision, I will now shorten the above rules into a single rule:

It is bad practice to do anything which might cause you to write less code.

“Oh.” says the (hypothetical - I don’t think anyone actually reads this blog) reader, “Another whiner who doesn’t like typing. Just use an IDE!”

This is not about typing. I know perfectly well that the IDE can do ‘typing inference’ (so to speak). This is about reading. Making your code more verbose does not make it more readable. In many cases it makes it less readable because you’re hiding the actually important stuff inside layers of crap. Further, even when all of it is relevant, expressing it in an overly verbose way makes it much harder to take in.

Even ignoring the functional programming argument, I think the Java community and conventions would gain a lot by losing their fear of terse code.

Well, I’ve not done a *lot* of work on it since I last posted, but there are a few improvements. In particular the parser has been sanitised and expanded, support for generics has been (experimentally) added, and I’ve actually used the project in anger.

It’s currently insufficiently expressive to do most of the things I want, so I’ve been engaged in the great evil of editing generated code - using JTypeBuilder to generate *most* of the boiler plate and then adding my own bits of code to fix things.

I’m probably going to have to replace the code generation entirely at some point. Freemarker is very nice, and there are a lot of things I’d consider using it for. I’m not sure a compiler backend is one of them.

I’ve decided to start a new personal project, and I’m going to make it open source from day one. The project is called JTypeBuilder and is hosted at Google Code and released under an apache 2.0 license.

The basic idea is that it is used for generating data models and producing an awful lot of associated boiler plate code. It produces immutable classes for representing the data, mutable classes for generating the immutable ones and methods for passing back and forth between them. The immutable classes all have the obvious equals and hash code implementations, as well as a toString method which produces a JSON like representation of the class.

It currently just consists of a couple freemarker templates and some simple wrapper code for them. When I get around to it I’ll add a parser and command line interface for nice representation of the data models.

I have vague intentions of using this for some sort of simple ORM package. Another possibility is using it as part of a compiler backend for targeting the JVM - it can be used to generate the data types. All of this is in the future though - right now it’s simply a tool for reducing boiler plate code (and a fairly incomplete one at that).

Update: Phew. That was a succesful day. The parser and code generator now work, and are hooked together with an extremely rudimentary command line interface (it’s little more than a proof of concept). Still to do are improvements to the interface and customisability, as well as general improvements to code generation and parsing. Nonetheless, there is now a working tool there. Yay.

Actually, come to think of it, the biggest thing that needs fixing at the moment is the build.xml. It’s a really shocking piece of spaghetti XML put together with the intent of having something working quickly rather than actually producing a portable build script… Lots of hard coded paths.