Joy Of Programming

"Everything should be made as simple as possible, but no simpler."
Attributed to Albert Einstein

When I first used Java many years ago, I was amazed how amazingly easy (and fun) it was to create applets and applications that did file I/O, networking, multi-threading, and later, remoting and database access using just AWT, java.io, java.net, RMI and JDBC. The language was easy to read and program and the JDK was free to download. Best of all, it came with these amazing libraries built-in! And knowing those libaries and Object Oriented Programming was all you needed to know to get a job in Java. I and thousands of other developers left the overly complicated world of C++, MFC/Motif and COM/CORBA for the simple elegance of Java, and never looked back. Luckily for us, the birth of Servlets made Java the server-side language of choice for Enterprises. It may have spawned a million web frameworks, but Servlets by themselves were brilliantly simple and elegant, and a lot more fun than the alternative of Perl CGI that I had suffered through before.

Since then, Java has been getting increasingly complicated. First with the additions of Swing, DynamicProxies, NIO, and Generics, and now with Closures, Java is getting more powerful, but at the same time, definitely more harder to program. Even worse, we now have hundreds of APIs, and have even more on the way. Inorder to get a job in Java today, you need to know Swing, EJB/Spring, JMS, JTA, JSP, Servlets, HTML, Javascript, SQL, JDBC, Hibernate/JDO/JPA, Ant, Eclipse/Netbeans/IntelliJ, Struts/JSF, UML, XML, jUnit, SOAP, Tomcat/Weblogic/Websphere, and the millions of Open Source libraries! These days I write more SQL and XML than I write Java. It's gotten to the point that writing business software in Java, what most of us do for a living, is no fun any more.

The reason why programming in Java has become so painful today is that Java designers are sacrificing simplicity and elegance for power and flexibility. This attitude is best embodied by Swing, an abomination that is neither a widget toolkit like AWT, nor an application framework like MFC. It maybe the most flexible GUI framework ever made, but it's also the most hardest to work with. It has a steep learning curve due to it's excessive inheritance hierarchy and it's convoluted version of MVC, while it lacks basic features like data binding and a proper component model. Since Swing, Sun has given us EJB, JMF, Java3D, and JSF, all APIs that make doing the easy things hard, and the difficult things really really hard. That was exactly the mistake that C++ made before, and just like C++ programmers like me quit C++ for Java, Java programmers have started abandoning ship for simpler alternatives like Ruby and Python.

"Designers are not typical users – they become so expert in using the object they have designed that they cannot believe anyone else might have problems; only interaction and testing with actual users throughout the design process can forestall that."
Donald Norman in The Design Of Everyday Things.

The initial Java language and libraries were designed with a user's perspective. And it shows. Bill Venners calls it Designing for Usability. Since then, the new APIs have been designed by vendors and expert users, for other vendors and expert users, without any consideration for the actual users of the APIs: those that have to work with them every single day. If every new JSR had to go through user trials before being made into a specification, we would never have to suffer through the complexities of EJB.

All is not lost, yet. J2ME offers the same refreshing simplicity of the early Java APIs. And there are new Java libraries out there that are brilliantly simple and elegant. For example, I needed to convert some XML files into Java beans. Sounded simple enough, till I tried Apache BeanUtils, JAXB, and Castor. The first two were too complicated, while the last one had too many problems to work around. And then I found XStream. Amazingly easy to get started with, and yet supported even the most advanced scenarios. What a joy to use! Why can't all Java libraries and APIs be this way? Here's a plea to all those who design Java APIs - think of your users, and bring back the joy of programming to Java.