Closer To The Ideal

I post this only because I am impressed with the extent to which the JVM world is now able to fight back against Microsoft. Record macros in OpenOffice with Groovy

Windows/Mac/Linux (OpenOffice): Free OpenOffice extension Groovy makes it possible to record and run Macros in OpenOffice. Don’t confuse Groovy for a cheap Visual Basic knockoff. Groovy has its own syntax similar to bash mixed with Java. If you were sticking to Microsoft Office solely for its macro capabilities, you may be able to break away with Groovy. Unfortunately, Groovy is not nearly as beginner friendly as VB/VBA. However, beginners will have no problem getting started with simple macros. Groovy is a free extension for all platforms with OpenOffice. Here is an ODT with several sample macros to help you get your feet wet (remember, you need to install Groovy before you can run the macros).

I first got interested in Java in 2003. I played around with it for year, doing minor toy projects. I finally decided that I hated it — too verbose, too redundant, too much aimed at the Enterprise, not dynamic or agile. Java is inappropriate for fast moving startups. I turned my back on Java and therefore missed the explosion of dynamic languages that run on the JVM: Jython, JRuby, JavaFX, Groovy, etc. In other words, I turned my back on the Java ecosystem just at the moment that it finally started to get interesting.

About a year ago I began to focus again on the world of the JVM. At first I was over-enthusiastic about JavaFX. Then I was frustrated by its lack of progress. Some at Sun have talked as if JavaFX was Swing 2.0, the future of Java GUI programming. But with JavaFX one has to jump through some hoops to integrate with Java code, whereas other JVM languages, such as Groovy, allow seamless integration.

Given that background, I am fascinated to read that Griffon is making it easier to do polyglot programming with the JVM languages:

If you’ve followed the Griffon news in the last 12 months you may be aware that Griffon is a fun and rapid desktop/rich application development framework inspired by Grails; that there are more than 40 released plugins and that polyglot programming is a pretty much a done deal (Groovy, Java, JavaFX, Scala & Clojure). Griffon was born as a means to get Swing applications off the ground quickly; a few months ago it gained the capability of mixing Swing and JavaFX components in the same application.

Just recently it went a bit further than that.

Swing is not the only toolkit that can be used with Java in order to create a desktop applications, JavaFX is clearly one alternative (though at the time of writing this entry it still lacks a full set of controls and a healthy ecosystem of 3rd part components, but that’s another story). There is also SWT, which provides better fidelity as it talks to native widgets directly as opposed to Swing. However that also imposes some restrictions (like skinning) but that has not kept the proponents of the toolkit (and Eclipse) from using it at every turn. There is also another newcomer: Pivot. Fresh from VMWare labs it quickly found a place at the Apache Incubator where it’s been nurtured and awaits the moment of graduation.

What do these toolkits have to do with Griffon? Well as it turns out there is experimental (i.e, not finished yet) support for both SWT and Pivot.

I didn’t realize that there was a web framework built using Clojure, but Compojure has been around for over a year now. Brian Carper wrote a small online game using Clojure/Compojure, and it sounds like an impressive combo. (My one dislike: templates made up of code.) He is highly critical of Rails:

This was a nightmare to do properly in Rails. Rails wants to dispatch to controllers, which are classes. To make this work in Rails I had to mangle this concept to fit into the idea of a hierarchy of classes and subclasses. There might have been an elegant way to do it, but I couldn’t think of one. I suspect someone will leave me a flame comment telling me how to do it.

I’m also surprised to learn that Clojure is over 2 years old. It is weird how much time I spend reading tech news, and yet so many developments go past me without me noticing.

This looks to be a truly exhaustive discussion of the issue of performance speed of software written in Java, versus software written in C. I am surprised that Java is as competitive as it is. This is very surprising to me:

It could also be notice that JRuby is faster than native Ruby.

I think this says a lot about how much time and energy and money has been spent optimizing the JVM:

Places where C/C++ proponents claim C beats Java, but it doesn’t appear (to me) to do so:

* Most ‘plain’ modest sized program. This will be programs requiring no more than the “usual” compiler optimizations and are not so tightly constrained by machine size or startup time. Examples might be things from simple compute-bound loops (string hash, compress) up to IDEs & editors (and most visual tools); DB cache/drivers, etc.

[SS: For the example where Java beats C/C++ a number of times visit www.caucho.org and their OSS PHP engine Quercus. You can check the numbers yourself using my http://code.google.com/p/wikimark/ For the example of super-fast memory DB in Java visit http://www.h2database.com it beats MySQL both in performance and footprint :) Of course it's specifically tuned for in-memory use. And Java is just an example of so called Managed Runtime (Microsoft term). If we are talking about Java performance we are mostly considering JITed code performance. But JIT can be effectively applied to C/C++ as well, see http://llvm.org Apple Mac OpenGL implementation is based on LLVM and all OpenCL implementations too. So anyone running their games on Mac or planing to use OpenCL will use the JIT. ]

Rich Hickey offers a great write up of the problems facing the funding of open source software:

There *are* companies that make software themselves, whose consumers
see a value in it and willingly pay to obtain that value. The money
produced by this process pays the salaries of the people who are
dedicated to making it, and some profit besides. It’s called
“proprietary software”. People pay for proprietary software because
they have to, but otherwise the scenario is very similar to open
source – people make software, consumers get value from it. In fact,
we often get a lot less with proprietary software – vendor lock-in, no
source etc. Most alarmingly, this is the only model that associates
value with software itself, and therefore with the people who make it. …

As should be obvious, Clojure is a labor of love on my part. Started
as a self-funded sabbatical project, Clojure has come to occupy me far
more than full-time. However, Clojure does not have institutional or
corporate sponsorship, and was not, and is not, the by-product of
another profitable endeavor. I have borne the costs of developing
Clojure myself, but 2009 is the last year I, or my family, can bear
that.

Many generous people have made donations (thanks all!), but many more
have not, and, unfortunately, donations are not adding up to enough
money to pay the bills. So far, less than 1% of the time I’ve spent on
Clojure has been compensated.

Right now, it is economically irrational for me to work on Clojure,
yet, I want to continue working on Clojure, and people are clearly
deriving benefit from my work. How can we rectify this? Barring the
arrival of some white knight, I’m asking the users of Clojure to fund
its core development (i.e. my effort) directly, and without being
forced to do so.

This is a great interview between Bill Venners and Rich Hickey. Hickey is the guy behind Clojure, the new JVM language that brings Lisp to the world of Java. I have so far only heard good things about Clojure. Hickey makes the argument that what is needed in modern languages is the automatic management of time and concurrency issues. In the same way that, during the early 90s, Java introduced (to the mainstrteam) the idea of automatic garbage collection, now we need languages to automatically manage the problem of multiple processes accessing the same object at the same time:

Bill Venners: What do you mean when you say the problem of mutable state is a time problem?

Rich Hickey: If somebody hands you something mutable—let’s say it has methods to get this, get that, and get the other attribute—can you walk through those and know you’ve seen a consistent object? The answer is you can’t, and that’s a problem of time. Because if there were no other actors in the world, and if time wasn’t passing between when you looked at the first, second, and third attribute, you would have no problems. But because nothing is captured of the aggregate value at a point in time, you have to spend time to look at the pieces. And while that time is elapsing, someone else could be changing it. So you won’t necessarily see something consistent.

For example, take a mutable Date class that has year, month, and day. To me, changing a date is like trying to change 42 into 43. That’s not something we should be doing, but we think we can, because the architecture of classes is such that we could make a Date object that has mutable year, month, and day. Say it was March 31, 2009, and somebody wanted to make it February 12, 2009. If they changed the month first there would be, at some point in time, February 31, 2009, which is not a valid date. That’s not actually a problem of shared state as much as it is a problem of time. The problem is we’ve taken a date, which should be just as immutable as 42 is, and we’ve turned it into something with multiple independent pieces. And then we don’t have a model for the differences in time of the person who wants to read that state and the person who wants to change it.

…The time problem is not easy to see in today’s mainstream languages because there are no constructs that make time explicit. It is implicit in the system. We don’t even know that’s what we’re doing when we use locks to try to make this work. Because what we’re trying to do is partition time up to say, I’m going to get a portion of time when I get to look at it, and you’re going to get a separate portion of time when you’ll get to write it. That time management we have to do manually. We have to use locks and come up with some kind of convention, because it’s not automatic. So that’s why I’m saying, the problem here is a lack of automatic time management. We have to do that manually, just like we had to call delete before we had garbage collection. Somebody allocated something, and we had to call delete. It was our problem. It was manual. Now when we want to change a date or look at a date coherently, we have this time management problem that we use locks to try to solve.

This idea has been gaining strength for at least 2 years now. Automatic thread management was one of the reasons why Sam Ruby argued that Erlang would be one of the key technologies of the next 5 years.

Brad Delong asks “Why does Berkeley think it should be in the business of building its own content management systems anyway?“.

His complaint:

May I say that a content management system that–if you have been off dealing with another crisis in the middle of a task–decides when you come back and try to save your work that you are no longer logged in and dumps you to a login page after which it dumps you not on the page you were working on but on the root page, LOSING YOUR WORK!!!1!!

Such a content management system is HELLSPAWN!! Is WROSE THAN HILTER!1!!!1!…

He is complaining about bspace, which is based on the open-source
Sakai, a content management system written in Java, and focused on the needs of universities.

I think Delong’s post is a good reminder of how infuriating it can be for users when software fails to behave in the ways users expect. I also suspect this is a good example of an issue that users will regard as a bug, but the programmers will see it simply as a potential future feature that they may or may not add (”Should we catch POST info if a user is not logged in?”).

I should add, WordPress has exactly the same problem. Last week I started writing what I thought would be a short post for this blog, but I got carried away by my theme and wrote a long post. Then I went to get some dinner. I left the browser open, with the post unpublished. I came back after dinner and made some more edits, then hit the publish button – and just like that, my work vanished, because while I was out getting dinner, WordPress logged me out (for some reason I’d assumed that the auto-save feature was also refreshing my session info).

One of the nice things about building my own CMS was that I was free to fix the bugs that bothered me most, and this was a big one for me. I added a feature to my CMS that caught any POST info and showed it on screen, even if the person was logged out. This allowed recovery of the post. I worked on my CMS from 2002-2007 and then abandoned it because I could not keep up with projects like WordPress. Nowadays I force myself to use other people’s open source software, because it is economically rational to do so, but I hate some of the choices they make, and some of the features that they fail to implement.

In the comments, Jacob Davies posts this comment, which I thought was very funny and very on point:

Conversation that has happened more times in my career than I care to mention:

Someone else: “How long of a title shall we allow? 32 characters? 64?”

Me: “FOR THE LOVE OF GOD WHY DO WE NEED TO SET A MAXIMUM LENGTH? IS THIS 1952???”

Someone else: “But what if they put in a really long title and fill up the database?”

Me: “THE VERY NEXT FIELD – THE ‘CONTENTS’ FIELD – IS A FREE-TEXT FIELD WITHOUT A LENGTH CONSTRAINT SO IF THEY WANTED TO FILL THE DATABASE THEY COULD DO IT THERE ANYWAY.”

Someone else: “Won’t it waste space if we allow a variable-length string in the title?”

Me: “OH MY GOD YES A TERRIFYING LOSS OF ABOUT 3 BYTES ON A RECORD THAT IS A MINIMUM OF 1024 BYTES LONG AND OFTEN OVER A MEGABYTE, YOU ARE SO RIGHT.”

Someone else: “Yes but every other system has a length constraint for titles.”

Me: “YES AND I SUPPOSE IF EVERYONE ELSE WAS JUMPING OFF A BRIDGE YOU’D DO IT TOO.”

etc

Computer programmers are subject to some kind of strange mental degeneration in which they rate the potential waste of 0.00001% of the capacity of a modern hard disk as more important than the ability to enter titles longer than 32 characters in length.

It is now clear that the intensity of the praise focused on Ruby On Rails in 2005 was partly a revolt against Java. “The Java hyper-enthusiasts have left the building” signaled the end of an era, and the end of a particular type of Java framework – heavy, overly complex, overly strict.

The Java hyper-enthusiasts have left the building, leaving a significant contingent of Java programmers behind, blinking in the bright lights without the constant drumbeat of boosterism. But the majority of programmers, who have been relatively quiet all this time, always knew that Java is a combination of strengths and weaknesses. These folks are not left with any feelings of surprise, but instead they welcome the silence, because it’s easier to think and work. Where did the hyper-enthusiasts go? To Ruby, apparently. This is chronicled in Bruce Tate’s book “Beyond Java,” which should probably be titled “Why Ruby is Better than Java.”

That was December of 2005. At that time it seemed like Java was slowly going to fade away, replaced by lighter languages that encouraged agile practices.

But that is not what happened. Instead, the Java platform evolved:

The idea of “Enterprise Ruby” has become less repellant since Dave Thomas’s infamous keynote at RalsConf 2006. There are a lot of large, lumbering organizations out there that have yet to adopt any of the newer agile language/framework combinations, and Rails has most definitely led the way. I personally believe that in order for Ruby to become more than just a nice language with a great community, it needs to gain adoption in those organizations, and it needs to do it damn quickly. JRuby is by far the best way for that to happen.

There’s another aspect to adoption I think has escaped a lot of Rubyists. In 2006 and 2007, Ruby gained a lot of Java developers who were running away from bloated, over-complicated frameworks and the verbosity and inelegance of Java. When I asked at Ruby conferences in 2005, 2006, and 2007 how many people had done Java development in a former life, almost everyone in the room raised their hands. When I’ve asked the same question in 2008 and 2009, it’s down to less than half the room. Where did they go?

The truth is that the Java platform now has reasonably good answers to Ruby in Groovy, Scala, and Clojure, and reasonably good answers to Rails in Grails and Lift.

Java and Groovy compared:

Groovy provides an excellent playground for trying out features that may be coming to future versions of the Java programming language. Its close relationship to Java makes it even more attractive for this than other less Java-like languages with the same features. In this blog posting, I have attempted to demonstrate Groovy features that may end up in a future version of Java. These proposed new Java features include property support, BigDecimal operators, switch on String, multiline Strings, and the Elvis operator. Other than the brief mention of BigDecimal operator overloading, I did not focus on Groovy’s operator overloading here for the same reason I did not mention Groovy’s closure support here: they both deserve blog posts of their own. I instead focused on smaller new features here that might someday be added to traditional Java.

Having read a little about Apache Wicket, I wanted to learn more, so I went to the website. I was surprised by their list of Java frameworks:

Echo
Cocoon
Millstone
OXF
Struts
SOFIA
Tapestry
WebWork
RIFE
Spring MVC
Canyamo
Maverick
JPublish
JATO
Folium
Jucas
Verge
Niggle
Bishop
Barracuda
Action Framework
Shocks
TeaServlet
wingS
Expresso
Bento
jStatemachine
jZonic
OpenEmcee
Turbine
Scope
Warfare
JWAA
Jaffa
Jacquard
Macaw
Smile
MyFaces
Chiba
JBanana
Jeenius
JWarp
Genie
Melati
Dovetail
Cameleon
JFormular
Xoplon
Japple
Helma
Dinamica
WebOnSwing
Nacho
Cassandra
Baritus
Stripes
Click
GWT

Damn. How can anyone keep up? And that’s just plain Java frameworks. They are, apparently, not counting web frameworks like Grails, written in Groovy, which runs on the JVM.

There are so many languages, so many frameworks, so much new stuff. It has become impossible to make any pretense of choosing the “best” technology for a job. Rather, we are all subject to circumstance now, the accidents of our lives that bring us into contact with a particular technology at a particular time. This has always been true, but it beomces more obvious to me when I see a list like this.

This part of what Wicket says about itself has some appeal to me:

Most existing frameworks require special HTML code.

JSP is by far the worst offender, allowing the embedding of Java code directly in web pages, but to some degree almost all of the frameworks from the list (except Tapestry) above introduce some kind of special syntax to your HTML code.

Special syntax is highly undesirable because it changes the nature of HTML from the kind of pure-and-simple HTML markup that web designers are familiar with, to some kind of special HTML. This special HTML can be more difficult to preview, edit and understand.

Wicket does not introduce any special syntax to HTML. Instead, it extends HTML in a standards-compliant way via a Wicket namespace that is fully compliant with the XHTML standard. This means that you can use Macromedia Dreamweaver, Microsoft Front Page, Word, Adobe Go Live, or any other existing HTML editor to work on your web pages and Wicket components. To accomplish this, Wicket consistently uses a single id attribute in the Wicket namespace (”wicket:id”) to mark HTML tags that should receive special treatment by the toolkit. If you prefer not to render Wicket namespaced tags and attributes to your end-users, Wicket has a simple setting to strip them all out, resulting in ordinary, standards-compliant HTML.

No “special sauce” in your HTML means designers can mock up pages that you can use directly in development. Adding Java components to the HTML is as simple as setting the component name attribute. And you can then give the HTML back to your web designers knowing that they can change it with confidence.

Wicket, more than any other framework gives you a separation of concerns. Web designers can work on the HTML with very little knowledge of the application code (they cannot remove the component name tags and they cannot arbitrarily change the nesting of components, but anything else goes). Likewise, coders can work on the Java components that attach to the HTML without concerning themselves with what a given page looks like. By not stepping on each other’s toes, everyone can get more work done.
Existing frameworks are not easy.

Most of the existing toolkits have poorly defined or non-existent object models. In some cases, the model is defined using special XML syntaxes. The syntaxes may be so cumbersome that special tools are required to manipulate all the configuration information. Since these toolkits are not simple Java libraries you may or may not be able to use your favorite IDE tools such as editors, debuggers and compilers.

Wicket is all about simplicity. There are no configuration files to learn in Wicket. Wicket is a simple class library with a consistent approach to component structure. In Wicket, your web applications will more closely resemble a Swing application than a JSP application. If you know Java (and especially if you know Swing), you already know a lot about Wicket.

The more I learn about Groovy, the less I understand why the world needs JavaFX.

Back around 2002 or 2003 I studied Java, but it seemed heavy to me, verbose, and slow to program with. My attitude has mostly been, life is short, so I’d rather program in light-weight, high level programming languages. I want to be able to go as fast possible. For the last few years I’ve mostly been doing web development, mostly with PHP, though I did one project with Ruby On Rails.

But then the iPhone came out. And then the iPhone app store. So I became intrigued with the idea of programming for cell phones. But I didn’t want to especially learn Objective C just to be able to work with the iPhone. I was relieved to hear that Google was coming out with its Android operating system for cell phones, and programming for Android would be done in Java. That opened the door to using the light-weight languages (derived from Java) for cell phone programming. Very cool.

So I began to delve into the world of Java, something I hadn’t done much in the last few years. At first I was attracted to JavaFX, which Sun was hyping. But then I began to wonder why JavaFX was suffering such a slow uptake, and why programmers seemed less thrilled about it than I.

Now that I’ve started to study Groovy, I realize why JavaFX has so little traction: it isn’t needed. Much of what I liked about JavaFX is already present in Groovy. Lexecorp expresses some of the same hesitation that I feel:

I wonder whether I will be able to like JavaFX! Have I been spoilt already by Groovy (it does, virtually, the same thing)? Maybe, but I managed to accept the long winded Java language well after Perl’s expressive power had spoilt me. I learned to love Java for its platforms and immense libraries, so what can I love about JavaFX?

Consider this tutorial, which showed how to draw a coffee cup, and which showed off the clean, declarative style of JavaFX:

def plateGroup = Group {

translateX: 250
translateY: 300

content: [

// The gray ellipse under the plate
Ellipse{centerX:0 centerY:10 radiusX:160 radiusY:50 fill:Color.DIMGRAY},

// The thin "lip" of the plate (provides a sense of 3D)
Ellipse{centerX:0 centerY:3 radiusX:170 radiusY:50 fill:Color.LAVENDER},

// The large plate ellipse
Ellipse{centerX:0 centerY:0 radiusX:170 radiusY:50
fill:RadialGradient{
centerX:0.5 centerY:0.75
stops:[Stop {offset: 0.0 color: Color.WHITESMOKE},
Stop {offset: 0.5 color: Color.LIGHTGRAY},
Stop {offset: 1.0 color: Color.DARKGRAY}]
}
},

// Recessed plate center
Ellipse{
centerX:0 centerY:5 radiusX:90 radiusY:22
fill:RadialGradient{
centerX:0.5 centerY:0.75
stops:[Stop {offset: 0.0 color: Color.BLACK},
Stop {offset: 0.4 color: Color.LIGHTGRAY},
Stop {offset: 1.0 color: Color.GHOSTWHITE}]
}
}
]
}

def cupGroup = Group {

translateX: 152
translateY: 20
scaleX: 3.0
scaleY: 4.0

content: [
// Cup body
Circle {centerX: 100 centerY: 100 radius: 50
fill: RadialGradient {
centerX: 0.4 centerY: 0.0 focusX: 0.5 focusY:.65, proportional:true
stops: [Stop {offset: 0.0 color: Color.GHOSTWHITE},
Stop {offset: 1.0 color: Color.SILVER}]
}
},

// Cut top of cup
Rectangle{stroke: BGCOLOR fill: BGCOLOR
x:25 y:50 width:150 height:50},

// Outer rim
Ellipse{fill: Color.WHITE centerX:100 centerY:100 radiusX:50 radiusY:8},

// Inner rim
Ellipse{centerX:100 centerY:100 radiusX:48 radiusY:7 //inner rim
fill: RadialGradient {
centerX: 0.4 centerY: 0.0 focusX: 0.5 focusY:.4, proportional:true
stops: [Stop {offset: 0.0 color: Color.GHOSTWHITE},
Stop {offset: 1.0 color: Color.SILVER}]
}
},

// Create “coffee in cup” by intersecting coffee ellipse with inner rim ellipse
ShapeIntersect {

fill:Color.SADDLEBROWN

//Inner Rim
a: Ellipse{centerX:100 centerY:100 radiusX:48 radiusY:7} // inner rim dimensions

//Coffee
b: Ellipse{centerX:100 centerY:102 radiusX:46 radiusY:6} // coffee dimensions
}
]
}

Stage {
title: “Coffee Cup”
width: 500
height: 500
visible: true
scene: Scene {
fill: BGCOLOR
content: [plateGroup,cupGroup]
}
}

That’s impressive! Look how clean the code is! So much simpler than Swing! But then Andres Almiray turned around and demonstrated how to draw a coffee cup with Groovy:

group( id: ‘plategroup’, bc: ‘none’ ) {
// gray ellipse under the plate
ellipse( cx: 0, cy: 10, rx: 160, ry: 50, f: color(’darkGray’).brighter() )

// thin ‘lip’ of the plate (provides a sense of 3D)
ellipse( cx: 0, cy: 3, rx: 170, ry: 50, f: ‘lavender’ )

// large plate
ellipse( cx: 0, cy: 0, rx: 170, ry: 50 ) {
radialGradient( cx: 1, cy: 1, fy: 100, r: 270 ) {
stop( c: ‘whiteSmoke’, s: 0 )
stop( c: ‘lightGray’, s: 0.5 )
stop( c: ‘darkGray’, s: 1 )
}
}

// recessed plate center
ellipse( cx: 0, cy: 5, rx: 90, ry: 22 ) {
radialGradient( cx: 1, cy: 1, fy: 20, r: 180 ) {
stop( c: ‘black’, s: 0 )
stop( c: ‘lightGray’, s: 0.4 )
stop( c: color(’white’).darker(), s: 1 )
}
}

transformations {
translate( x: 250, y: 300 )
}
}

group( id: ‘cupgroup’, bc: ‘none’ ) {
subtract( id: ‘cup’, asShape: yes ) {
circle( cx: 100, cy: 100, r: 50 )
rect( x: 25, y:50, w: 150, h: 50 )
}
draw( cup, keepTrans: yes ) {
radialGradient( cx: 0.4, cy: 0, r: 100 ) {
stop( c: ‘whiteSmoke’, s: 0 )
stop( c: color(’whiteSmoke’).darker(), s: 1 )
}
}

// outer rim
ellipse( cx: 100, cy: 100, rx: 50, ry: 8, f: ‘white’ )

// inner rim
ellipse( cx: 100, cy: 100, rx: 48, ry: 7, id: ‘innerRim’ ) {
linearGradient( y2: 1 ){
stop( c: ‘whiteSmoke’, s: 0 )
stop( c: color(’whiteSmoke’).darker(), s: 1 )
}
}

intersect( f: color(’darkOrange’).darker().darker() ) {
shape( innerRim )
ellipse( cx: 100, cy: 102, rx: 46, ry: 6 )
}

transformations {
scale( x: 3, y: 4 )
translate( x: -16, y: -70 )
}
}

transformations {
translate( x: -50, y: -50 )
}

Damn. Doesn’t that look similar? There are some syntax differences, but both use a declarative style, and both require less work than using Swing.

Groovy offers some solid MVC frameworks. For web development, there is Grails, which is an imitation of Ruby On Rails. For the desktop, there is Griffon. Consider this post on Transentia:

Although it is early days yet for the project, Griffon aims to bring the same “Configuration by Convention” goodness to desktop GUI development that Grails has brought to Web development. In fact, Griffon ‘borrows’ heavily from Grails: many of the build scripts, etc. are straight carry-overs, meaning that anybody familiar with Grails can get started easily.

This is all that is needed to get started:

griffon create-app GT
cd GT
griffon run-app

These three shell commands give a simple immediately runnable application.

As with Grails, Griffon imposes a clear MVC structure for the code and also creates a standard project filesystem heirarchy.

I haven’t yet worked with Griffon, but the setup described on Transentia looks very clean. Certainly, everything I’ve learned so far about Groovy has left me impressed. And since Groovy integrates with regular Java far more smoothly than JavaFX, why do we need JavaFX? Can anyone name one thing that JavaFX gives us that Groovy hasn’t already given us?

As I recall, when I was getting into programming in the late 90s, and especially when I was getting into PHP, there was a debate about the value of light-weight scripting languages, such as Ruby, Python, Perl and PHP. Some old-school programmers insisted that working with those languages didn’t count as “real” programming – those languages were too easy. And many old-school programmers were critical of the performance hit one takes with the light-weight scripting languages. After all, for some tasks, a routine written in C will run more than 100 times faster than the same routine written in PHP. A two-order-of-magnitude difference in execution speed needs to be taken seriously. Of course, on the flip side, a programmer can rapidly prototype new software with a light-weight scripting language, whereas using C would take much, much longer, and then it would be harder to change once it was done.

Back then, the decision was seen as either/or: either use a light-weight scripting language, or use a lower-level language that is more efficient.

In recent years, the new style has been “both”: mix the high-level and low-level languages. Use light-weight scripting languages to prototype some software, then look at the bottlenecks and drop into a lower level language for those parts of your code that need the speed. For instance, consider what David Heinemeier Hansson says about Campfire, the chat software he helped developed. First written in Ruby On Rails, it soon became clear that the code that polls to see who is in the chat room needed to be as fast as possible:

We rewrote the 100 lines of Ruby that handled the poll action in 300 lines of C. Jamis Buck did that in a couple of hours. Now each poll just does two super cheap db calls and polling is no longer a bottleneck.

Campfire and a shared todo list is different because they’re not working on a shared resource. There’s no concept of locking. Or two people dragging the same item. So a 3 second delay between posting and showing up doesn’t matter. It does when you’re working on a shared resource.

In between C and the light-weight script languages are those languages that added some extras, such as Java, C# and Erlang. Java and C# offer object orientation and automatic garbage collection, whereas Erlang offers automatic concurrency. The crew at 37 Signals has decided to re-write the polling in Campfire, using Erlang:

Last Friday we rolled out the Erlang based poller service into production. There are three virtual instances running a total of three Erlang processes. Since Friday, those 3 processes have returned more than 240 million HTTP responses to Campfire users, averaging 1200-1500 requests per second at peak times. The average response time is hovering at around 2.8ms from the time the request gets to the Erlang process to the time we’ve performed the necessary MySQL queries and returned a response to our proxy servers. We don’t have any numbers to compare this with the C program that it replaced, but It’s safe to say the Erlang poller is pretty fast. It’s also much easier to manage 3 Erlang processes than it was the 240 processes that our C poller required.

The diversity of language choices allows programmers to find exactly the right level of abstraction. When do you need programmer efficiency, and when do you need the code to execute efficiently? One needs a variety of languages so one can always get the right level abstraction for a given project. I think this is part of what Larry Wall was talking about:

Doing it right involves treating the evolution of the language as a pragmatic scope, or as a set of pragmatic scopes. You have to be able to name your dialect, kind of like a URL, so there needs to be a universal root language, and ways of warping that universal root language into whatever dialect you like. This is actually near the heart of the vision for Perl 6. We don’t see Perl 6 as a single language, but as the root for a family of related languages. As a family, there are shared cultural values that can be passed back and forth among sibling languages as well as to the descendants.

As I previously wrote:

Larry Wall is a deep thinker. And he has been developing a deep philosophy of computer languages. Yet the world of Java has, quite surprisingly, opened up and become a world of many languages: Groovy, JavaFX, JRuby, hecl, Jython, etc. No one would have guessed, in 2002, how much Java was going to open up. But while Larry Wall has been thinking about Perl 6, the Java community went ahead and created the reality that he was merely thinking about: “So there needs to be a universal root language… [and] shared cultural values that can be passed back and forth among sibling languages as well as to the descendants.”

I’ve written a little Java in the past, but I’ve always hated how heavy it is. Double casting a variable when you declare it leads to code that strikes me as overly verbose, for my purposes. Most of the time, I work on code that should be built quickly, and execution speed is not a concern. However, I’ve recently started studying Groovy, and I like it quite a lot. It is a light-weight scripting language that runs on the JVM. Using it, one can drop back to standard Java any time one needs a performance boost, or one needs to take advantage of a library that is specific to Java. You could knit together software made of Java pieces, using Groovy as the glue.

This, it seems to me, is the new style. We no longer face an either/or decision about high-level and low-level languages. Rather, the new pattern is, start high, and then drop down to a lower level whenever you need the extra power.

(In this post, I will let hecl stand in for all scripting languages that aim to make programming easy to do on cell phones.)

All through the 1980s and for most of the 1990s, Apple made efforts to make programming easy. In 1987, Apple released Hypercard, probably the single easiest programming environment ever. Apple’s dedication to empowering people – allowing minimally-technical people to program – earned it a great deal of goodwill, so much so that Bill Atkinson (the inventor of HyperCard) basically gave it to Apple as a free gift, in exchange for the promise that it would be included on all Macintosh computers. Sadly, in this decade, Apple has forgotten about Hypercard. My sense is that this represents a larger trend within Apple: a general retreat from the goal of giving minimally-technical people easy programming tools. The death of Hypercard lead to mourning among its many fans (myself included). Danny Goodman summed up the feelings of many:

I shed my buckets of tears for HyperCard (and what might have been) many, many years ago. The first crude demo that Bill showed me was, at its root, what the World Wide Web has become. Coulda, woulda, shoulda.

Despite valiant post-version 1.1 efforts by dedicated and exceptionally bright serfs (their recollection brings fond memories), HyperCard never truly recovered from its detour to the Claris dungeon and the dungeon masters. It’s a tale of perhaps the biggest opportunity Apple missed in its self-defense against a rising Windows tide.

When I look at the current product, I see facets that are still ahead of their time, not the least of which is the extraordinarily elegant HyperTalk language by Dan Winkler — a kid straight out of college, who Bill Atkinson said was the only programmer who could keep up with him. At the same time, aspects of the product have been embarrassingly behind the times for years. Kevin was well on his way to fixing that, but the scenery changed.

Back when Apple was still proud of HyperCard, and boastful of its use by minimally-technical people, this is the kind of article that I read over and over and over again:

I thought it was really cool to see – not because I’m interested in quilting, or the program is anything brilliant (it’s simple and functional), but because enabling stuff like this is part of what I built Hecl for: to make mobile phone applications easier, quicker, and simpler to create. Someone went and typed in the code on Heclbuilder, got the program running, and now a number of people have a handy tool to do some calculations for their hobby, which is a heck of a lot easier than fooling around with SDK’s, Eclipse or Netbeans, and so on and so forth.

But this is no longer Apple talking, rather, it is David Welton, talking about Hecl.

The other tool for programming by minimally-technical people that Apple has promoted has been AppleScript. Influenced by HyperTalk (HyperCard’s programming language), Applescript has a syntax that in many ways mimics English, and therefore it is easy for English speakers to learn.

The digital revolution continues to change our lives. The biggest change over the last few years has been the mass acceptance of cell phones. Most people that I know no longer have landlines, they only have cell phones. This is the next great frontier for computer programming. And yet, Apple hasn’t yet made Applescript available to run on the iPhone. Yet hecl can run on Android.

Personally, I would love to be able to write apps for the iPhone. But I don’t want to have to learn the Object C language. I don’t have the time. I agree with Simon Brocklehurst’s criticism of this decision:

Recently, Apple bowed to the inevitable, and has released an SDK for developer testing. The language they chose to base the SDK around is Objective-C. This wasn’t a complete surprise – after all, it’s the “native” language of Mac OS X. However, while it’s not a surprise, I wonder if it’s not a major strategic error on Apple’s part. The point is this: the Mac is a niche platform, and is especially niche in terms of numbers of developers building applications in Objective-C. Compare that to iPhone, which because of its technological lead, has the chance to become a major volume player in the mobile phone space. If Apple wants iPhone to succeed, it seems strange to attempt to force developers to use an unpopular language for programming it. That isn’t the way to win – developers have many, many choices of platforms they can spend time developing for.

Brocklehurst thinks Apple should pick a popular language for its SDK. I think Apple should pick one that is easy to learn. A light weight scripting language. If Apple came out with an implementation of Applescript that ran on the iPhone, then I would start writing iPhone apps tomorrow.

But for now, it doesn’t seem like Apple is planning on doing that. So when I look around for relatively easy ways to get into cell phone programing, other light-weight scripting languages jump out at me. And they lead me to platforms other than the iPhone.

So maybe hecl is the new Applescript/Hypercard? For people who want to put together a quilting site with a cell phone connection, what is the easiest way for them to do that? Who is, right now, showing commitment to the old ideal of empowering minimally-technical people to write the apps that they want?

Over the years, I’ve learned a great deal about programming from Artima, in general, and Bill Venners in particular. I was aware, circa 2003, that he was a big fan of Java. It is interesting to see him now decide to use a new language, and to compare Scala to the dynamic languages, as part of that process:

One of the most commonly cited productivity benefits of dynamic languages is that they enable much more concise programs compared to Java. While this is true, the productivity benefit here is actually conciseness, and that doesn’t require dynamic typing. I show how type inference in Scala lets you get much of the conciseness of say, a Ruby or Python program, but in a statically typed language.

Another productivity benefit of dynamic languages is that, via a feature called open classes in Ruby or Python, you can add a method to a class and then call it. You can’t do this in a static language. Nevertheless, I point out that the productivity benefit isn’t actually in the dynamic adding of the method. The benefit, instead, is in being able to call the method. And that you can do in static languages using various other techniques. In C# 3.0, for example, you can make it possible to call new methods on classes via C#’s “extension methods” feature. In The Feel of Scala talk, I show how you can use Scala’s implicit conversion feature to obtain that same productivity benefit.

Another oft touted productivity benefit of dynamic languages is that duck typing allows you to pass classes with common structures but no common supertypes to a method, which treats them uniformly. I point out once again that the productivity benefit isn’t actually the duck typing per se, but the ability to pass the different types. I demonstrate three ways to achieve that in Scala. First, I show “view bounds,” which is a completely static approach that involves implicit conversions. I also show structural typing in Scala, which is dynamic in the sense that reflection is used to invoke methods at runtime, but static in the sense that everything is checked at compile time. Lastly, I demonstrate using plain-old duck typing, exactly the same dynamic technique used in Ruby and Python, but this time in a static language. I show that as with duck typing in a dynamic language, spelling errors result in runtime errors, but then demonstrate that with a compiler plug-in, you can move that run-time duck typing error to a compile-time error, effectively extending Scala’s static type system.

Lastly, another commonly cited benefit of at least some dynamic languages is that their syntax is more flexible, allowing you to make domain specific languages. While this is also true, the benefit comes from the flexible syntax, not the dynamic typing. During the talk I show that dynamic typing is not required for syntactic flexibility. I demonstrate the flexibility of the Scala language, showing how you can define new control constructs and make internal DSLs.

To get a sense of how much Venners has changed, consider what he said to Matz when they spoke about Ruby:

In Ruby, I can add methods and variables to objects at runtime. I have certainly added methods and variables to classes, which become objects at runtime, in other languages. But in Java, for example, once a class is loaded or an object is instantiated, its interface stays the same. Allowing the interface to change at runtime seems a bit scary to me.

Some of this stuff used to strike him as scary. Like a lot of Java folks, Venners has become more open to the new methodologies advanced in recent years by the light weight dynamic languages.

David Van Couvering is sympathetic to my frustration regarding Sun:

 I remember when Rich Green did the Big Splash announcement for Java FX at Java One two years ago - I just groaned.  It was basically an “if you announce it they will come” strategy as far as I could tell – there was no there there.  The technology for the most part had not been built.  It was an announcement of an unrealized vision, not an actual working product.  And meanwhile there were not one but two competing solutions – Flex and Silverlight – from two of the best consumer software companies in the business.  Things did not look good – and still don’t.What made this whole Java FX thing really grating to me was that we as a company had to pull out all stops to get this thing to actually happen, since our VP of all software had put his reputation on the line by announcing it.  They pulled the best and the brightest from the NetBeans and Java Swing teams to work on Java FX.  They pulled our UI design resources.  They pulled our QA resources. And the now NetBeans was working on life support, and JavaFX struggled along, and continues to struggle along.   

Sun in 2009 reminds me of Apple in 1997, before Steve Jobs came back and rescued the company.  Great technology, great people, terrible leadership. I’d be pleased if there was someone else out there who could rescue the company. Sad to say, at the current moment, it looks like the company is going to disappear into IBM.

So, late last year I started learning JavaFX. I thought this would be a great way to learn about other areas of computer programming (since I mostly do PHP programming for websites). Sun Microsystems seems committed to pushing JavaFX as the next Big Thing. Sun has pulled their best people off of other important projects so that it could maximize its investment in JavaFX:

For almost two years now, Sun has been promoting JavaFX, the centerpiece of its vision for Java as a viable rich-client technology, and an alternative to Adobe’s Flex and Microsoft’s Silverlight. At heart, JavaFX is a JVM-based domain language for constructing rich user interfaces, as well as a set of APIs for that language.

…In spite of a thriving Swing community, and despite Swing’s large user base, Sun has re-focused its efforts around JavaFX over the past year-and-a-half, at the expense of Swing development. The most visible aspects of that change in focus is that many of the most experienced Swing developers left the company, such as Chet Haase (see Artima’s interview with Chet Haase), Hans Muller, or Scott Violet. The important Swing-related JSRs have also been stale for a long time now: the latest JSR 295 and 296 updates occurred in June, 2006, according to the JCP’s Web site.

For all the money that Sun is throwing at JavaFX, I’m surprised at how slowly it is finding a market.

I had assumed that JavaFX might make some progress in two areas:

1.) Online games.

2.) Cell phones.

Of course, online games was always a long shot, since Flash is so deeply entrenched. I was just looking at the games over at Casual Collective, they are all built with Flash. Online game developers are comfortable with Flash, and probably nothing can change that situation in the medium term.

Then there were cell phones. Here I thought JavaFX would make big progress. Jonathan Schwartz emphasized this in his talks at JavaOne. It’s been almost a year now, yet the press still doesn’t mention JavaFX when they talk about cell phones:

Heavyweights in the field include Nokia   and its Symbian operating system, BlackBerry maker Research In Motion, upstart Apple  and a staggering Microsoft  with its Windows Mobile system.

Each bring a special approach to the fight. Nokia has the unmatched size and reach, holding 40% of the smartphone market. RIM’s knockout punch is email. Apple’s iPhone is a showboat that dazzles crowds with media prowess. And Microsoft is fighting to carry an enormous Windows franchise to smartphones.

…Google funded Android, a smartphone operating system that HTC fashioned into a touchscreen phone called G1 sold exclusively by Deutsche Telekom’s   T-Mobile.  And while other phone makers, notably Motorola, have selected Android as its software partner, a new crop of G-phones has yet to arrive.

Meanwhile, Apple continues to advance its platform:

Apple unveiled new software for the iPhone that will support some long-anticipated features, such as copy-and-paste of text and picture messaging, as the company pushes to stay competitive in the phone market.

Apple also gave its vast network of software developers a slew of new options for upcoming applications, such as support for subscription models and automatic alerts, a move applauded by analysts.

“They’ve taken a few more steps ahead of the pack in the race,” said CCS Insight analyst John Jackson, adding that, in spite of the omission of certain features until now, the iPhone was still the most high-profile cell phone.

“Two years on they still have the cool phone and business model that everybody’s talking about and trying to emulate.”

Last year the folks at Sun were pushing the idea that JavaFX was the natural choice for Android. That might happen eventually, but for now, few developers have bought into Sun’s vision. Search for “Android JavaFX” and all you find is propaganda from Sun and some developers griping – you don’t find a single site singing about this idea with enthusiasm.  Search for “JavaFX” and all of the news is for developers – there are still no mentions of any consumer products. Sun seems to be running behind the rest of the pack. Most of the news articles focus on how amazing JavaFX will be when it is finally all done, and “all done” seems to always be a few more releases in the future:

However, some notes casually buried away in the 1.1 release notes suggest otherwise: the javafx.ext.Swing package isn’t available in the common profile so won’t work in mobile applications – this means no standard desktop UI components such as buttons, trees and listboxes. You do get one component, javafx.scene.control.TextBox. But the richness of the desktop component set just isn’t there in the mobile configuration. When you look at the existing mobile demos, you’ll quickly realize the colorful, motion-blurred, willy waving – such as a custom image masquerading as a button – divert attention from the lack of GUI components.

Yes, we’ve known all along that you need to build to the Common profile if you want to run on a mobile device; but if easy-to-use UI components aren’t part of that API, doesn’t that defeat the whole purpose of the very UI-centric JavaFX? More UI controls will be hitting the Common profile before JavaOne 2009, but until then mobile developers might find things a little half-baked. The Register does point out one saving grace: unlike the situation on the desktop, JavaFX mobile does not particularly lag offerings from Adobe (whose Flash Light isn’t in wide use) or Microsoft (which doesn’t even have a real mobile version of Silverlight yet).

It’s easy to want to root for Sun. They’ve been good to the open source community. They’ve donated billions of dollars worth of effort and software (Open Office, Java, etc). A world in which they are thriving seems likely to be a better than one in which Microsoft or Adobe are winning with their proprietary systems. Yet Sun doesn’t seem to have any understanding of how to succeed with consumer level technologies.

I’m still hopeful about JavaFX, mostly because I have faith in Google, and Android will allow Java to run on cell phones. But, damn, I am surprised about how slowly this technology is reaching the market (after all, Sun first announced JavaFX at the JavaOne conference back in 2007).

Larry Wall says that version 6 of Perl will hopefully become a root language that will lead to many other languages:

If you allow a language to mutate its own grammar within a lexical scope, how do you keep track of that cleanly? Perl 5 discovered one really bad way to do it, namely source filters, but even so we ended up with Perl dialects such as Perligata and Klingon. What would it be like if we actually did it right?

Doing it right involves treating the evolution of the language as a pragmatic scope, or as a set of pragmatic scopes. You have to be able to name your dialect, kind of like a URL, so there needs to be a universal root language, and ways of warping that universal root language into whatever dialect you like. This is actually near the heart of the vision for Perl 6. We don’t see Perl 6 as a single language, but as the root for a family of related languages. As a family, there are shared cultural values that can be passed back and forth among sibling languages as well as to the descendants.

Poor Larry Wall. Everybody seems to like him. I’ve never heard anyone say anything bad about him. Yet the beginning of work on Perl 6 was announced in 2002. This project remains vaporware. Larry Wall has mentioned it in every interview for the last 7 years. Now it is 2009 and Perl 6 has still not yet been released to the public. And in the meantime, the world of computing has changed a great deal.

Larry Wall is a deep thinker. And he has been developing a deep philosophy of computer languages. Yet the world of Java has, quite surprisingly, opened up and become a world of many languages: Groovy, JavaFX, JRuby, hecl,  Jython, etc. No one would have guessed, in 2002, how much Java was going to open up. But while Larry Wall has been thinking about Perl 6, the Java community went ahead and created the reality that he was merely thinking about: “So there needs to be a universal root language… [and] shared cultural values that can be passed back and forth among sibling languages as well as to the descendants.”

There are several good posts over at David N. Welton’s blog, and I’m going to post short excerpts here.

Welton is one of the two people working on hecl:

Hecl is intended as a complement to the Java programming language, not a replacement. As such, it tries to do well what Java doesn’t, and leaves those tasks to Java for which it is best suited. Hecl aims to be a very immediate language – you can pick it up and start doing useful things with it quickly. It is also meant to be easy to learn. Where Java is verbose and rigid, Hecl is forgiving and quick to write. For instance, System.out.println("Hello World"); vs puts "Hello World" – 41 keystrokes (shifted letters count double) versus 22. Hecl is built to “scale down”.

This makes Hecl ideal for large applications written in Java that would like to provide a user friendly scripting interface, rather than, say, a clunky XML based configuration system. Examples include: scripted web pages, command/control logic in long running applications, and, I’m sure, many environments I’ve never considered.

hecl strikes me as arising from the same economic/technological forces that have in recent years lead to the explosion of script languages running on the JVM: JRuby, Groovy, JavaFX, etc. hecl doesn’t necessarily run on the JVM, but, as I say, its existence seems due to the same underlying trend – the reality that for many projects it is economically rational to trade away program execution speed in exchange for greater programmer productivity.

The mobile phone is a good environment for Java and yet hecl might work even better in this environment (in that sense, it might be a direct competitor of JavaFX). They’ve apparently gotten a prototype working:

Thanks to Neal McBurnett, Hecl for Android finally got to run wild and free on a real phone. There were some glitches, but by and large, things seem to work, which is always exciting, and something of a relief. Neil says it runs fairly quickly, and looks good. Once again, a big thanks to Neil, and now on to fixing the bugs!

Welton also writes the only article I’ve ever read that says something negative about git:

The whole thing seems kind of shaky in the sense that it’s not very confidence inspiring: I feel like it wouldn’t take much to make a wrong turn and find all my files gone forever. I can see some of the advantages, and will likely stick with it – git is quite convenient for local files that I might not have bothered putting under version control in the past, but it’s also a bit more “bureaucratic” in that you have more steps to do, and you have to fill in the forms just so… or else!

And this is the only negative thing I’ve ever read about github:

However, I have a nagging doubt. Github apparently bases everything around the developer. In other words, projects hosted there are mostly attached to a developer who ‘owns’ the project, rather than existing on their own. There are a few exceptions – there seems to be a ‘rails’ role account to manage Rails, rather than having it belong to, say, DHH, so it’s not impossible to do something in a project-centric fashion, but it doesn’t seem to be very common either.

What I’m wondering is what sort of effects this might have in the long term. Github, and git itself, make it very easy to ‘fork’ projects. Could, or will this lead to a situation where people don’t try so hard to get their code in the ‘official’ branch? What happens when someone loses interest in their project? Sure, someone else can fork their repository, but if all the links were pointing to the first guy, because he was the main hacker on a project for X years, they’re not going to switch overnight even if guy B takes over maintanance. And in the meantime, casual searchers might turn up the ‘dead’ branch, or simply be confused as to who’s doing what. This could make things confusing for someone who just wants to check out some code and start using it…. trying to sort out various revisions and ancestry of a project could be quite discouraging.

Finally, Welton thinks of Coase and his Theory of the Firm when considering how smaller transaction costs in certain industries might be leading to more freelance gigs and less permanent jobs:

So if one wanted to look, in a less anecdotal way and slightly more scientific way, about whether the US, or other countries, are turning into “gig economies”, one could do worse than look at the transaction costs associated with utilizing contractors as opposed to permanent employees. If those costs have fallen (it may be easier to find people, thanks to the internet, for example), perhaps it is more efficient to have more contractors and fewer full time employees and so the equilibrium will tilt in that direction. Of course, another explanation might simply be that the economy is bad, and companies don’t have the budget to take on more people, so they get by with what they can in the short term.

For me, this is one of the main ideas I took away from the work of H. T Goranson. During the 1980s Japanese manufacturing firms used their focus on quality to beat American manufacturing firms. By the early 90s American companies were trying to catch up with the Japanese innovations in quality. Many American economists and business analysts worried that the next great zone of innovation would be agility. Organizations such as DARPA were sufficiently worried that they gave out a lot of grants to people like Goranson. His work concluded that, at least in the American context, small firms were uniquely innovative, but their innovations would be at least partially wasted if they could not be brought into the supply chains of the largest manufacturing firms. In this context, agility was defined as the ability to overcome the transaction costs associated with dealings outside of a firm. A truly agile supply chain would be one where numerous small suppliers could be quickly brought together into a completely new supply chain, with little additional cost (that is, the annoyance of dealing with lots of small firms would somehow be minimized). The model was Hollywood, which, in just a few weeks, is able to pull together a vast and diverse group of professionals to create a new movie. Goranson looked at everything from legal traditions to social mores to technological innovations that contribute to agility.

Needless to say, that kind of agility has become an increasingly important part of the economy, and possibly has become a unique competitive advantage of America.

I sent this email to some programming friends of mine:

Some real surprises (for me at least) in this year’s December usage stats for languages:

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

PHP is now the 4th most popular language in the world. It has edged out Visual Basic. I think this means that a lot of data entry forms and corporate intranets (the mainstays of Visual Basic) are now being done over the web, so PHP and HTML are being used for more and more of those projects. Visual Basic still has a huge advantage in terms of form widgets, and the level of interaction that can be achieved with forms. Maybe HTML 5 will narrow the gap somewhat? The use case for Visual Basic would fade a great deal, at that point.

It is a little odd, maybe, that PHP is the top ranking script language. It is universally regarded as less professional than Ruby or Python, but it is way more popular. Facebook is built almost wholly in PHP. Yahoo has used PHP for several recent projects, such as Yahoo Bookmarks (a competitor to del.icio.us, I think).

Very surprising (to me) to see Ruby moving down. It has been synonymous with “Web 2.0″ phenomena.

Java remains the most popular language. Have to admit, when I studied it, Java itself bored me to death, but I have become fascinated with JavaFX, since its release a few weeks ago. It is very light weight and simple (compared to Java). None of the freaking double declared typing and “narrow casting” and “wide casting” that I hated about Java. In my spare time, I’ve been working on a spaceship shooter game, mostly as a way to learn JavaFX.

One of my friends wrote back:

Somehow I’ve managed to never write a single line of Java code in my career. I count myself lucky. :)

I responded:

Yeah, I agree. It is kind of amazing to me how many smart people have worked on Java, and how awful it is. Stuff like “If you want your object to be serializable, then it must implement the Serial interface, even though the Serial interface does not have an implementation.” Hate that!

And the double declaration of a variable’s type, usually declared with a widening cast:

Integer automobiles = new LotInventory(94);

Who really wants to waste neurons in their brain keeping track of stuff like that?

Most of Java seems overly complicated and overly abstract – theoretically correct in an academic computer science kind of way, but not actually useful.

Even the die-hard defenders of Java are less willing to defend the language. I think this is the influence of Ruby. Since the emergence of Ruby, there has been an explosion of script languages that run on the JVM: Jython, JRuby, Groovy, Scala, and now JavaFX. And, of course, some of the best known writers who built their careers around Java (Bruce Tate, Bruce Eckel, etc) have become big fans of Ruby.

I read Bruce Eckel’s book back in 2003. That was when I started trying to learn Java. My only serious attempt at a Java project was in 2005, when I was trying to build a client side file uploader, a modified version of the software they discuss in Matthew Robinson and Pavel Vorobiev’s book about Swing. I decided I hated the language and gave up trying to learn it. Little did I know that the Java platform was about to get interesting. The big change in the Java community happened a little before Bruce Eckel wrote his essay “The departure of the hyper-enthusiasts“:

The Java hyper-enthusiasts have left the building, leaving a significant contingent of Java programmers behind, blinking in the bright lights without the constant drumbeat of boosterism.

But the majority of programmers, who have been relatively quiet all this time, always knew that Java is a combination of strengths and weaknesses. These folks are not left with any feelings of surprise, but instead they welcome the silence, because it’s easier to think and work.

Where did the hyper-enthusiasts go? To Ruby, apparently. This is chronicled in Bruce Tate’s book “Beyond Java,” which should probably be titled “Why Ruby is Better than Java.” The book is roughly edited; you’ll find yourself thinking “haven’t I read this paragraph before?” in any number of places, but that’s a disappointing experience I’ve had with several O’Reilly books of late. In many places he plays fast and loose, and almost at the end of the book he declares that he doesn’t have time to learn these other languages in any depth — although he has no trouble condemning the same languages in his rush to Ruby. Such a statement should be in the first paragraph of the book: “I’ve decided that I love Ruby, so I will condemn other languages without fully understanding them” (in one sentence repeated in a number of places in the book, for example, he declares that C# is no more than a clone of Java). I’ve been on the rollercoaster of language-love myself in the past and have made similar mistakes; one error in particular was dismissing Python’s scoping-by-indentation when I first saw it (months later realizing that we always indicate scoping by indentation anyway, even when we have curly braces available). Now I try to investigate and support my ideas about these things more thoroughly. It takes a lot more time and effort to do so, but it also leaves a more lasting impression.

Eckel correctly points out that the wonders of scripting languages are purchased with loss of efficiency, and some of the ugliness of Java or C or C++ are due to the compromises they make to gain efficiency:

Martin’s argument is that Java’s List interface requires you to say aList.get(aList.size -1) to get the last element, and this seemed silly to him. Which it is, if you have unified all sequence containers (that is, list containers) into a single type, as Ruby and Python do. Java, however, follows the C++ STL approach of providing different types based on the efficiency of various operations. The Java libraries do not unify to a single list type because of efficiency issues, so you have to decide if you are going to be fetching the last element from a list a lot, and if you are you use a LinkedList, which does have a getLast() method — a fact which was completely left out of Martin’s original discussion, and the ensuing firefight (other than some ignored comments).

Elliotte Rusty Harold (who took over the management of the Java track at the SD conference from me; I actually lived in the building next to his in Brooklyn for two months once) observed that Ruby’s library design didn’t seem so simple and clear to him, and he went into detail about many of the methods in the list class, pointing out that they often seemed to make no sense and wondering whether anyone was actually using some of them. Elliotte has spent a lot of time on library design recently, producing the XOM XML library which, I think, represents some very clear thinking. Look at what he writes; I think he makes a good case.

…Understanding the constraints under which Josh Bloch designed the Java libraries might make you understand that design a little better. Personally, I prefer the simplicity of Python’s single list class to Java or C++’s multiple implementations, but a single list implementation must make efficiency compromises. Library design involves compromise, and if such a compromise disagrees with you you’re likely to feel it was a bad choice.

Eckel is writing in 2005, but already it is clear what a revolution Rails represents:

And of course, who can ignore Rails? The backlash from heavyweight web frameworks has been significant. We now know that EJB 1 & 2 were based on an entirely flawed set of use cases. Because of the damage this (still slowly dawning) realization has wrought to Sun’s reputation, it’s hard to know whether EJB3, which probably should have been called something else to disassociate it with the failures of its predecessors, will succeed, despite the fact that EJB3 is like a breath of fresh air. You look at the code and it makes sense; no bizzarre and obscure interfaces and concepts to puzzle over while thinking, “I wonder why I have to do this? Well, these guys are clearly smarter than I am.” (I tried to understand EJB1, but when I first heard that entity beans didn’t actually work, my brain refused to let me invest any more time, which turned out to be the right choice). As a result of all this, someone said “hey, all I want to do is create a database and use it from the web. Why should I do all that work?” As it turns out, such activities seem to be about 90% of all we ever do in “Enterprise” programming, and EJB 1/2 were solving an entirely different problem, and making the 90% incredibly difficult in the process. Thus, the Rails approach of “just connect the database to the web.”

In retrospect, he makes only mistake in his whole essay:

However, I can’t see Ruby, or anything other than C#, impacting the direction of the Java language, because of the way things have always happened in the Java world. And I think the direction that C# 3.0 may be too forward-thinking for Java to catch up to.

But, as I said before, there has been an explosion of light-weight scripting languages that run on the JVM, and I think part of that is the influence of Ruby. And part of that, too, is simply that programmers want programming to be joyful and joyfulness of programming is something that only the scripting languages can deliver.

(Weiqi Gao offers a counter argument: “I classify myself as one of those developers who don’t get Ruby, just like I don’t get Perl. Both are too hard for me. And there seems to be something in my brain that prevents me from learning both. It’s strange I never had the problem with C or C++ or Python or Lisp or awk.“.)

Java code tends to be more verbose (and also more academically correct) then anything I want to work with. Consider this simple example:

Socket socket = new Socket(”time.nist.gov”, 13);
InputStream is = socket.getInputStream();
InputStreamReader isr = new InputStreamReader(is);
Buffered reader = new BufferedReader(isr);
reader.readLine(); // skip blank line
String message = reader.readLine();

So, socket returns an InputStream object. I’ve no problem with that. But inside of the InputStream object is a string of information that I want, and I can not get at it directly. Instead I have to give the InputStream to an InputStreamReader. And then I have to give that reader to another reader? Are you kidding? In PHP this would be:

$handle = @fopen(”http://time.nist.gov:13″, “r”);
$emptyLine = fgets($handle, 4096); // skip blank line
$buffer = fgets($handle, 4096);
fclose($handle);

Personally, my feeling is that life is short, so I don’t want to waste time with low level programming languages. I want to move fast, and the scripting languages allow me to move fast. Back in the 90s I got my first taste of programming with HyperCard and then later Applescript and then PHP. I studied how to use C to program System 7 projects on a Mac, but C was slow going. I’ve realized, over the years, for the things that I want to do with my life, I prefer the speed with which I can program in script languages. And that is why I am excited that script languages like JavaFX have arrived on the JVM. Amy Fowler sums up the aspects of the language that make life easier for the programmer:

But longer term, how many applications won’t be rich internet applications? Increasing graphics hardware acceleration is enabling the trend towards more beautiful and fluid interfaces. Ben Galbraith highlighted this point in his excellent User Experience JavaOne talk when he pointed out that user expectations have now been raised beyond just usability — they now expect to be wowed (recall Maslow’s Hierarchy of Needs from Psych 101). It may be that consumer applications are leading this charge, but in the end we’re all human beings and there is no reason why we shouldn’t feel as pleased with the applications we use at work as with those we use at home. And note that “beauty” encompasses both aesthetics and purpose.

So how do you get a beautiful application? You have it designed by people who understand visual design and usability. Period. Karsten Lentzsch once made a great point that “finding the design” is really the hardest part of building a GUI. And up to this point, the Java platform has been aimed at developers, most of whom couldn’t “find” a design if it landed on their MacBook Pro. So we have to provide a paradigm in Java which enables designers and developers to work more seamlessly in constructing beautiful applications. We believe that JavaFX script, in conjunction with existing designer tools (Photoshop, Illustrator, etc) and development tools tailored for building GUIs, is how we’ll get there.

It’s really different from Java and THIS IS A GOOD THING. For defining visually rich user interfaces, it has some major advantages over Java:

• declarative syntax (without XML; no offense to the XML community, as XML has its place, but its verbosity is simply noise in a hierarchical GUI description)
• first-class functions for callbacks (no more writing of anonymous inner classes — the JFX compiler handles those gory details)
• expression-based binding (this is the power drill for GUI development; once you use it, going back to the hand drill is painful)

I’ll confess that I didn’t want to like it at first (felt a little like I was cheating on Java), but after I got over the hump of learning to declare what I wanted, rather than coding procedurally, it became quite addictive, especially binding. But don’t take my word for it; try it out yourself before you render an opinion.

The argument against the scripting languages is that they are slow (meaning, their run time on the computer is slow), but I think Matz (I mean Yukihiro Matsumoto) summed up my feelings on that subject when he said:

In my point of view, efficiency and productivity are the same thing, because we focus on programming efficiency, not runtime efficiency. I don’t care about runtime efficiency. The computer goes faster and faster every year, so I don’t really care about performance. Actually, I care about performance when I’m implementing the Ruby interpreter, but not when I’m designing Ruby. The implementer should care about performance, but the designer shouldn’t. If you care about performance, you will focus on machines in design instead of on humans. So you shouldn’t focus on performance in design.

Nikolay Barkhatov feels that a web site should just be an interface to an application:

More I think about web development more I believe there is a clean separation between actual application and web application. Moreover, I believe there is no such thing as web application. Web interface is just an adapter to real application. It’s hard to convince managers to architect application the way where web adapter decoupled from actual application. Managers simply do not see benefits of doing that and do not allocate time for it. Product development ends up with one giant mess called web application where tier separation is a formal thing everybody talks about but nobody can clearly draw the line between them. And finally there is a requirement to quickly come up with remote API for third party developers… Very sad…

It is curious to me that such an idea seems natural, even akin to common sense, to a Java programmer, and yet it has little appeal to non Java-programmers. Why is that? This is a cultural thing. The people drawn to Java are the type of people who want to do everything the theoretically (or academically) correct way.

On some level, Nikolay Barkhatov’s idea sounds very smart. And yet, a lot of other smart people have decided to take another path. David Heinemeier Hansson is a smart person, but he didn’t feel the need to separate the website from the application he was trying to build. Instead, he create the web framework Ruby on Rails, to make it easier to marry code together with a web interface, while keeping things organized. The framework implements an Model View Controller pattern, so that the code and the web interface can work together in an intelligent way. Ruby on Rails was such an obviously good idea that other people began imitating it. Every computer language now has an imitation of Ruby on Rails. For instance, for those using the PHP computer language, there is the Symfony framework.

But having said all that, I admit that I’m fascinated by the idea of separating the application from the web interface. If I wrere to try it, I would write the application in one language, and the web interface in another language. I don’t trust myself to write both in the same language, the temptation would be to cheat, and mix the two together.

If I were to try to separate the application from the website, I might write the application in Java and the web site in PHP. I would use XML to get the data from the Java appliation to the PHP. For instance, suppose I build a site for value investors who want to see whenever a stock falls below a P/E ratio of 10. The application would sit on the server, intake stock information from various sources, look for low P/E ratios, and output the results as XML files. The PHP could read the XML files and construct the website from that.

One advantage of this approach is that the caching is automatic. The PHP only needs to read from static XML files.

How to handle input from users? I suppose that is where the separation of concerns breaks down, and perhaps this is the issue that has made frameworks more popular than tiered approaches to sites. True separation could be maintained if you use normal HTML/PHP forms that are submitted to PHP code that then transforms them into XML files that the Java could then read. But this gets clumsy. I wonder if there are any types of sites where this would be the optimal setup?

Almost every complaint that Frank Sommers has with JavaFX is something that I am pleased about. Apparently he wants Sun to focus on its current customers, rather than on its future customers. To me, that attitude is what often leads to bankruptcy. Smart, well manage companies often manage themselves rationally to bankruptcy. To my mind, JavaFX is Sun’s attempt to break out of that death spiral, to do something new. I am hoping this will prove as much of a new and positive direction for Sun as the iPod proved for Apple.

Frank Sommers writes:

In spite of a thriving Swing community, and despite Swing’s large user base, Sun has re-focused its efforts around JavaFX over the past year-and-a-half, at the expense of Swing development. The most visible aspects of that change in focus is that many of the most experienced Swing developers left the company, such as Chet Haase (see Artima’s interview with Chet Haase), Hans Muller, or Scott Violet. The important Swing-related JSRs have also been stale for a long time now: the latest JSR 295 and 296 updates occurred in June, 2006, according to the JCP’s Web site.

Most recently, SwingX contributor Jeanette Winzenburg wrote on the project’s online forum that Sun all but abandoned its support for SwingX, because its engineers are busy working on JavaFX:

… the official terminus is “frozen” – but as that happened already in July and everybody in the core team is well over their ears into FX it looks rather permanent to me…

I think it quite funny that [Sun engineer Richard Bair argues] in favour of that support/evolution mainly by stating that nobody (definitely not the experienced engineers/architects) at Sun has any time for it – because you all are wasting it it on FX (biased me again ) Fancy demos – especially in a language unrelated to the project at the center of this forum’s topic – are just that: fancy demos. They don’t solve any real world problems. Chet’s termed the effort to produce them so cutely as CDD – Conference Driven Design.

Winzenburg’s note seems to echo the sentiment of many experienced Swing developers. JGoodies’ Karsten Lentzsch noted, for example, that:

I’m worried that Scott Violet, Chet Haase, and now Hans Muller left Sun. AFAIK Jeff Dinkins isn’t working on Swing anymore, and Amy Fowler has changed her focus too.

None of my Java customers is interested in JavaFX. They want to get their Swing UIs running. They are looking for Java desktop blueprints, for a cook book that explains how to address the everyday Swing task. My customers were excited about the JSR 296 (Swing app framework) and 295 (beans binding). But now it’s unclear what’ll happen to these projects. I don’t see Sun’s Swing strategy.

If you look at the JavaOne 2006, 2007 and now 2008 what have we got for Swing, or in other words for the Java deskop *now*? A cool demo (Aerith) in 2006, more cool demos in 2007, and JavaFX in 2008. All my customers do the “boring” stuff: editors, forms, navigation, buffering, data binding, layout. That’s how they make money. Who cares about them? They need a framework, better components, not animated 3D flipping images.

And Kirill Grouchnikov recently wrote that:

I don’t know what the future holds for JavaFX. Sun is heavily betting on it… All I know is that JavaFX has effectively halted all core Swing development. Over the last 18 months, we have seen significant architectural initiatives (JSR 295 and JSR 296) changing leads and frozen. All client-facing improvements in Java2D, AWT and Swing in Java 6 Update 10 are completely driven by the requirements of JavaFX.

…Do you agree that Sun’s recent focus on JavaFX has hurt the cause of client-side Java?

It is impossible to keep up with all the new technologies that came out over the last year, especially one’s that I probably won’t ever use. I admit, I was confused, till now, regarding Adobe Flex, Microsoft Silverlight, JavaFX. Apparently these were all aimed at the same basic market, the same one that Google Gears aims at: ????????building applications that have a front-end that lives and runs as a desktop app, but pulls data from the web. I’m pleased to now at least understand what all these are about. I can’t see myself building this kind of software in the near future, so I guess I can ignore these technologies. If I do end up doing this kind of software, I’m sure I’ll use Google Gears, simply because I already have some slight introduction to the Google API.