Java, the Obsolete Language

Just read someone's post on why Java is becoming stupider. I have to agree. The industry always strives to build complexity. I have successfully stayed away so far from all the new language features of JDK 5 (they changed the name yet again to JSE instead of J2SE at this year's JavaOne). After developing Corernstone Framework G3 on JavaScript, I have been convinced more than ever that Java will not be my language of choice for the foreseeable future. I have already left the building so to speak. However, this is not to be confused with our continued use of JVM. See my earlier post on Java the language vs. JVM the platform.

Long live Java!

Seaside and Other Thoughts

There were several recent posts on Seaside, a Smalltalk web framework. Only today did I watch its videos. It is indeed wonderful. Several things set it apart from the rest of the crowd:

1. A complete flow that would usually involve multiple servlets and forms is programmed in one method (using continuation although whose concept is not exposed to the developer directly).
2. All request handlers are blocks (closures), saving the need for separate servlets.
3. A natural hierarchy of components on the page gives it a portal like page model so that compnents (portlets) can interact on the server side.
4. Components can be easily reflected to reveal their information for easy debugging.
5. Requests can be of type goto or (subroutine) call.

My comments:

1. Number 1 is seen in many other frameworks (Apache Cocoon uses continuation in JavaScript; Ruby and Python both have continuation support). But Seaside's developer model seams very intuitive. I will start thinking about how to implement this in Cornerstone Framework G3.
   
2. Number 2 is a good use of closures (which JavaScript supports well; No such thing in Java). We already have extensive use of closures in G3.
   
3. Number 3 is what we have seen in portal servers. I was thinking along the same lines but to let the portlets not only be able to communicate on the server side but also on the client side. We will implement that in G3.
   
4. Number 4 is an obvious benefit of the underlying language (Smalltalk) being a dynamic one. JavaScript can do the same with ease. We will implement this great feature too.
5. Number 5 we already had in G2. It was only used in demos. No production use yet. But the Seaside demos show how useful it is. We will sure carry it over to G3.

These days I am really getting excited about G3 as I started to implement it. It will be the beginning of:

1. A web command prompt, a Unix shell prompt on steroids, enabling the user to do anything (web or local) through it, whose special case is a completely graphical UI that has no actual command prompt.
2. A world-wide spreadsheet. I find spreadsheet to be an excellent model for developing something (we call it application but an average Joe does have to know it). Now just imagine a new page to be a spreadsheet that links to other pages through a URL (a service delivered in the REST model). The world-wide web is ready for the next giant leap to a web of applications.

BTW, I have actually started to implement the bible reading application that Francis proposed because I find myself needing it yesterday. I was using an HTML editor to put things in a table and quickly realized it would not scale to meet my needs. So that application will be the first to drive the development of G3, in addition to the unit test cases that I have been writing.

These days I am too excited to sleep! I hope to disseminate the information to you guys soon.

First Impressions of Ruby and Rails

Ruby and Rails are the hot buzz of the moment. I recently bought the book Agile Web Development with Rails. I haven't finished reading it. Only read ActiveRecord (the OR mapping module and the M of MVC) Action Controller (the C of MVC), Action View (the V of MVC) and Ruby language overview. Here are my first impressions.

Rails

• It's a very good framework. There are many design decisions that we can learn from it.
• There are many areas that I can already see that Cornerstone on JavaScript will do better: multi-dimensional customization, a good template language, arbitary division of client and server code, much faster runtime, tight integration with Java (meaning near native access to all Java resources), one language to learn across client and server, etc.
  

Ruby

• The more details I read about it the more I think it's an OK but not great language. Its liberal accomodation of so many different syntaxes for the same semantics introduces inconsistencies everywhere. Many design choices are less than optimal (:symbol, Class::classVariable, @_privateInstanceVariable, etc.).
• JavaScript, in comparison, is much more concise and consistent and yet as powerful at least. It is very easy to do FP (functional programming), OOP and AOP in JavaScript, not to mention it is available on every computer of the world (through the browser).

I think the current enthusiasm behind Rails is more of a vote against the complex state of the art of doing application development using Java, which Spring and Cornerstone 2.0 alleviate to some degree. Since Spring and Cornerstone 2.0 cannot go far enough with hands tied up by Java, people naturally gravitate towards the best current solution of Rails.

BTW, in a short review of Cornerstone 2.0, I was amazed at how many features are there because of Java's lack of dynamic nature, which can be removed completely when we switch to JavaScript. For example, we will completely do away with properties files. Configuration will be done in JavaScript assignments (Emad, remember you were advocating a language for configuration? Now you get JavaScript!). Registry will be just JavaScript source code living on different planes. The more I think about Cornerstone on JavaScript, the more excited I get. I hope to get down to work on it very soon!

The Web of Applications (cont.)

More web applications are coming onto the scene by integrating with and adding value to existing web applications. Case in point is Cheap Gas that integrates with Google Maps. Remember an earlier posts (1 and 2) on this topic? We will see more of this. This is huge.

AJAX Savvy URL

People are talking about AJAX savvy URLs. It's basically URLs that record the state of your AJAX page completely so that you can forward it to somebody who can then completely reproduce the page you see. You know what, we already have this technology. It has been deployed here. Notice the URL when you navigate around.

Backbase: Pretty Good UI Framework

Backbase looks pretty good. There are many things we can learn here.

Revamping Cornerstone Registry with OSGi?

We should explore using Eclipse's OSGi implementation. One con is the jar is big (almost 800KB). The open source implementation Oscar also seems to be big (>700KB). The Knopflerfish implementation has a 200KB option which is not bad. So do we need the full glofy of OSGi?

Java Plugin Framework

One interesting project to watch: Java Plugin Framework.