java rants

Today someone decided to pretend they knew something about how a modern statically typed language developer works.  Perhaps they are big emacs fans or something because they felt that static-types leading to autocomplete in an IDE was somehow a feature in the language FOR THE IDE.  The IDE gets no benefit, in fact, editors like emacs and TextMate are much simpler. But I can tell you that the developer gets a tremendous benefit by having this metadata database not only present in the code and easily queryable but heavily exploited by her tools.  What is amazing about this metadata database is that it is actually populated by that same IDE.  There are very few times that I even type a Type — 90% of those times are when declaring a new Type — the rest of the time the IDE is very patiently maintaining and leveraging that database for me.  Even better, when someone else is looking at the source code, or even using the library, they instantly get 80% of the documentation. All that is left are the semantics of the calls. Perhaps we need to have some sort of meetup where we look over each others shoulders and actually understand how someone who is on the other side really works rather than dynamic-typing language people assuming that the programmer is maintaining the huge metadata database present in the static-typing language developers code.  And on the otherside that static-typers are assuming that the dynamic-typing language developer is memorizing all kinds of arcane method call names, argument shapes and the shapes of all the libraries they are using. Do you really memorize all that trivia?

A month and a half ago I had put out a call for what I was calling the ‘ideal web application template engine‘ along with a list of requirements that I thought would be present in such a system.  Since then I looked a bunch of them and decided that I like the simple markup that mustache defined but none of the implementations were up to doing what I wanted.  This led me to embark on building a new engine with for that markup for my chosen platform, Java, which I called creatively, mustache.java.  Though it claims to be ‘logic-less’ I would say that it has some amount of logic. It will loop over a set of objects and it will check booleans, but I think it is about as close to logic-less as you would want to be in a template language.  So, let’s look at each of the requirements and how I ended up implementing them:
Continue reading →

The laundry list of repositories that are filling the POM in Maven projects has to go. The ideal of having a central store of all artifacts is clearly dead and we have to move on. My proposal is two fold. First, the repository to end all repositories that doesn’t actually store the files but simply redirects to a known good location for the group id / artifact id / version combination. The second is that we create an ad hoc standard for artifact discovery based on the group id. For example, if the group id is com.sampullara.cli-parser then you should be able to find a repository that stores all artifacts at http://cli-parser.sampullara.com/repository/. Perhaps we could even put some sort of discovery file at the root to find them. This would allow anyone to distribute Maven artifacts to developers without having to publish to any central location. It would also drastically reduce the amount of repository cruft that is creeping into so many of the POM files I have seen recently. Further, it would make it really easy for github, googlecode, apache, etc to help their developers automatically publish with just the right naming conventions in place.

Come to think of it, maybe the whole thing is a little suspect. Maybe we should have been using URLs the entire time. How much value are we getting out of the layer of indirection? This is intended to be a discussion…