2010-10-31

Extend what?

I just spent part of my day writing some code to make it easier to embed a fairly high profile open source piece of software in unit tests.  For the most part it is a very useful piece of software and it has a beautifully narrow API.  Unfortunately the design of some of the key server classes is not...shall we say, brilliant.  I could rant for hours about how this isn't exactly rocket science and how I wish that people would try to learn from frequently made mistakes, but I'm not.

If you design and implement a piece of server software, please make sure that it is possible to fully configure and embed the server itself in just a few lines of code.  And no, I am not interested in using a crapload of onion programming inheritance hierarchies of test classes.  I'll write my own unit test classes thank you very much -- you can keep your antiquated junit 3 base test classes and roll around in the mud with them if it pleases you.  Don't expect me to infect my code by having to extend your ill designed base classes.

Also, if you insist on using singletons then at least learn how to design singletons properly and, more importantly, when not to use them.  It is exceptionally tedious to have to serialize unit tests or fork off new JVMs just because people can't be bothered to design things properly.

Aargh!

Verbiage

I just clicked on a link to a New York Times article.  The headline promised the answer to a question.  Of course, the New York Times being what it is the author of the article wasn't going to let the reader off easy.   The piece was lengthly and, after a couple of paragraphs, I realized that it would be a painfully dull read.  There was not a lot of information to convey, so the author was watering down what little there was with dull filler.

I bet most of these hacks dream of writing novels, and I sincerely hope none of them are ever published.  At least not if they are going to bulk up their novels with the same sort of inane drivel that they fill their NYT articles with.  To paraphrase Philippe Starck: these books would not deserve to exist and it would be a crime to inflict them upon humanity.

I have a thing about filler in prose.  The first time I read a book by John le Carré I thought I might have hit a dud.  Surely, if people loved his books, they couldn't all be that bad.  I read a couple more. More of the same.  I was told that this was indeed his style.  Mr le Carré will waste four pages describing a doorknob.

I don't care if people think his books are great:  I think they belong in the back pages of uzbek knitting magazines.

The New York Times contains far too many articles that appear to have been written to weigh in at some pre-defined word count.  This lowers the quality of the writing and makes for tedious reading.  Most of the writers at the Times are not that good.  A select few are, the overwhelming majority are not.  So how about we drop the artificial word counts and start focusing on quality instead, hmm?  The newspaper industry is in enough trouble as it is.  No need to deliberately hasten the long ride down the drains.

Oh, and if you really want to learn how to bulk up a skinny article:  read some of Jeremy Clarkson's articles.  He writes a lot of car reviews and most of the time he has precious little to say about the car in question.  I don't blame him.  Most new cars are like one of Mr le Carré's novels:  supremely tedious affairs.  Yet Clarkson has mastered the art of producing good filler.  He is funny, he is provocative and he can write.

2010-10-26

Java, don't make long term plans

I have been using Java as my main programming language for about 7 years now.  Before that I had used Java for hobby projects since its first release some time in the 1990s.  The reason I switched from programming mostly C on UNIX to mostly Java in 2003 was the availability of asynchronous network APIs and a reasonably performant JVM.  It also didn't hurt that Java is still the only language I can think of with decently designed collection classes.  Later in 1.5 Doug Lea's cocurrency library also made it into the class library, which of course was nice.

These days a lot of things are conspiring against Java.  The most obvious threat to Java is its new owners:  Oracle.  It is becoming ever more clear that the Java community as a whole would be better off if Oracle had not bought Sun.

When Oracle took over Sun I have to admit that I was mildly optimistic.   Sun was perhaps one of the more promising companies from a technology point of view.  But it doesn't help being "promising" when you are coming of age and you have not made it out of your mother's basement.  Under competent management Sun would have leveraged its strengths and been the leading star in the cloud computing era.  Instead companies such as that book-shop from Seattle are leading the way.

Sun's slogan used to be "The network is the computer", but what they lived was "the computer is the computer and it is an expensive computer very few people would want".  Meanwhile they managed to realize exactly nothing in terms of being "the networked computing company".  Funny that.

I was mildly optimistic because I thought that Oracle might provide the much needed leadership to make something of Sun.  Unfortunately it turned out that not only are Oracle mostly concerned with shortsighted money-grabbing by hitting up Google for spare change, but they appear to be really terrible stewards of the Java community.

The one thing Java had going for it was a strong community -- bordering on the fanaticism usually associated with Apple technologies and products.  That community is very confused these days.   People are essentially asking themselves "is it over?".  With some regularity Java luminaries are jumping ship.   Just a few days ago Doug Lea announced he was not seeking another term on the JCP Executive Comittee.  Before him, Gosling and others left Oracle.

It probably isn't "over".  Likewise it sure as hell isn't "promising" anymore.

I am not sure if Apple decided to no longer ship their OS with Java pre-installed because of Oracle.  Steve Jobs and Larry Ellison are apparently personal friends, so I suspect this may be a dig at Google, since Android is in fierce competition with iPhone.  Jobs' friendship with Ellison and Oracle suing Google for the only successful use of Java on mobiles makes this a complex question.

Yes, I know that Dalvik is not a JVM, but to developers it doesn't make much of a difference.  Yes, I also know that J2ME is probably on more phones than Android, but I said successful.  J2ME has always been a piece of rubbish and I can not imagine that it will stop being a piece of rubbish any time soon.

An interesting side-note:  the percentage of Java developers using Macbooks at conferences is disproportionally high compared to the market share of Macbooks.  While desktop Java apps are not that interesting to me, it will be interesting to see what effect this will have on people who serve as key technology influencers -- ie developers and geeks.

In the short term I will still rely on Java as my main programming language,  but I think there is reason to be concerned about the future of Java and to start looking for alternatives.  With Oracle's non-stewardship of Java I would not make any long term bets in favor of Java.

Sure, Oracle may mend their ways, but Ellison doesn't strike me as the kind of guy who apologizes for behaving like a sugar crazed five year old.  The guy lives in a replica samurai village, runs a company that "doesn't do employee appreciation events" yet has no problem setting fire to a metric fuck-ton of cash to fund his fondness for wind-propelled maritime toys.  Java is his toy now and if he wants his lawyers and miscellaneous suits to use it as a slugger to hit his competitors over the head, then that is what will happen.

The safe bet is to start noting where the exits are.

Before we go on:  forking Java is not really an option.  We will end up with lots of incompatibilities and any target big enough to register on Oracle's radar will come under fire by hordes of patent lawyers and assorted Oracle trolls.  Don't go there.  Forking is not a long term solution.

One such exit may be Erlang.  What little I have managed to learn about the language seems very promising.  Now that CPU clock speeds have long since stopped being a scaling factor for performance, languages that have been inherently designed for concurrency become more important to utilize all those cores.  I have to admit that I still know too little about any potential legal pitfalls that may or may not be associated with Erlang, but if there are any:  now is the chance to learn from the Java adventure and make Erlang a safe bet.

I hope to get enough spare time to learn Erlang soon.  Or better yet, if someone is willing to pay me to learn Erlang while building something in it.

I see .Net as a non-option.  I have never had much faith in the Mono project and the .Net platform is always going to be intrinsically linked to Windows -- and Windows is the odd one out as far as operating systems are concerned.  It is the last of the ancient, weirdo, oddball operating systems.  The rest of the world is UNIX.

For those of you pushing PHP, Ruby, Python, Perl and miscellaneous scripting languages:  no I am not going to bother explaining to you why these are not replacements for Java and the JVM.

Groovy, Scala and other JVM-bound languages also are not an option for more obvious reasons.

C++ and Objective-C are also not an option.  I view these as by-products of the adolescence of OOP that should have been discarded as their use-by date expired,  but which have unfortunately stuck with us like a bad smell since the days when the mullet was considered the epitome of cool.

And C?  Be serious.

2010-10-25

Inheritance is evil.

A common mistake in Java code is the over-use of inheritance.  You should always favor composition over inheritance.  If you do extend a class, and the class you are extending is not an abstract class that has a damn good reason for existing, you had better have a good excuse ready.

On second thoughts, spare me the excuse and hand over your lunch-money.

If you extend concrete classes often there is something wrong with the way you program and you urgently need to learn how structure programs.  Seriously.  These are beginner's mistakes and if you think of yourself as something more than a beginner then this is reason for grave concern.

Of course with composition comes dependency injection and with dependency injection the temptation to involve something to do the injection for you.  In a word: don't.  If you belong to the subspecies of programmers who thinks it is better to wire up your programs in XML rather than code, then you are a moron.

Take it one step at a time.  Start by overcoming your fear of writing concrete classes that do one thing without prematurely being split into a bunch of classes.  Yes, there is surely a more general way to do anything you can think of, but you are not going to need it and anyway: you are not that smart.  If more than half your classes are generic fluff then you are not being productive;  you are just masturbating.

When you do need to break things up and the design you come up with calls for extension of concrete, non-abstract classes:  find a hammer and hit your big toe.  Hard.  If you do not have the stomach to do it properly I will be more than happy to do it for you.  This is good for you.  This motivates you to become a better programmer.  Treasure your remaining big toe.


I have just spent the better part of my evening trying to understand a piece of code that makes use of pointless "onion programming" -- where the behavior of a class has to be divined by peeling away successive layers of inheritance and inspecting each layer to slowly figure out what is going on.

This is fucking tedious.

Especially when no thought has been put into naming and the organization of packages is completely willy-nilly.  What you call things is important.  It tells other people what to expect.  If unsure: ask someone who knows a thing or two about API design.  If you spend half of your time coming up with good names for types and the rest of your time programming, well, then at the very least you will spend half your time not writing more shit code.

If you want one piece of advice it is this:  Chances are you are not very clever.  Also, your code does not really interest me.  I look at it because it causes friction or doesn't work.  (This is due to the you not being very clever part).   Not because I am admiring your work.  I am only interested in what it can do for me.  The less I have to read and the more I can assume, the happier I am going to be with your code.  The more involved I have to get the angrier I will be with you.  Please write your code in a manner that lets me get on with my life, and I'll stay out of yours.