Recently, I attended the No Fluff Just Stuff Atlanta Software Symposium. One of the big buzz terms there was “dynamic languages.” For those of you who don’t have a Computer Science degree, a dynamic language is a programming language which performs many functions at runtime that a static language would perform at compile time.

For instance, a method call in a static language is linked to its code at compile time and is immutable. In a dynamic language, however, this determination is made at runtime. That means that in a language such as Groovy, I can add methods to an object that its class may not have been written to have.

In Java, dynamic features are very difficult to use. The closest thing that it has to a closure, for instance, is the anonymous inner class. Using one is about as simple and elegant as dressing an elephant while performing ballet in a tar pit. In Groovy, however, closures are a first class feature.  Also, dynamic code runs on the Java Virtual Machine therefore calling traditional Java code from Groovy or Scala for instance is rather painless.

The next point (which my roommate made) is - “Why would anyone want to do this?” If Java does what you need, albeit painfully at times, there is no need to move off it. If Java doesn’t do what you need, or if it makes it hard to do what you need to do, then Groovy or Scala, or Jython, or JRuby may be useful. It would be foolish to think that any of these are a wholesale replacement for the Java language, but it is equally foolish to think that Java can be the best at doing everything you may need.

I have been using Subversion for my source code management (SCM) for several years now. It has followed me from Georgia Tech, through several personal projects, and two jobs. It is a well supported, well documented, and well understood product with thousands if not millions of users. Being a good developer, however, I find myself asking “what next?”

One answer, which has been implemented by Sun for their Java, OpenSolaris, and Netbeans projects as well as by Linus Torvalds for the Linux project is a decentralized, distributed SCM. In these systems, instead of having one single trunk, every interested party has their own trunk which people check out from. These changes are kept locally until it is pushed to or checked out from a remote tree.

In these systems a single maintainer is considered to be keeping the “golden” version. He is responsible for making sure that all checked-in code passes tests, conforms to code standards, etc. This is the version of the project which is considered stable. End users check out from him. He checks out from the Quality Assurance team when they report that their code has been checked for new bugs and problems. QA, in turn, checks out from developers and creative when they announce that they have finished work.

Linus Torvalds presented the Linux SCM system, Git, at Google and his speech can be found on YouTube.

For people who are interested, the solution from Sun is called Mercurial. Both are Free software.

I am a fan of biking, just ask any of my coworkers who have had the pleasure of seeing me haul into the office after a nice jaunt. I am also a application developer and web addict. Given the ubiquity of cheap wi-fi, the pleasure of not having to park or follow most traffic laws, and an investment in a laptop which weighs 3 pounds and has a 5 hour battery life, I tend to do a lot of work on the trail.

This has lead to an interesting problem. Most of my job is creating web applications which fail when you do not have any internet access. Now not being able to check my email when I am on the side of Stone Mountain may not be a problem, but not being able to update my spreadsheets, compose mail, or save my changes to the next great American novel is.

Many sites do not see the need for dealing with intermittent connectivity and instead take an all or nothing approach. Things are changing, needs are changing, and this attitude should change. Over the past few years there have been several technologies developed and proposed which mitigate these issues.

One that I have worked with is the Dojo Storage API. This API is a part of the Dojo project, an open source Javascript library. It provides wrappers for Adobe Flash’s shared object functionality which means that I can write Javascript code which will call Flash and save data to the user’s machine even if I am not online.

There are a few downsides to using the Dojo Storage API. First, a user must have Flash installed and must not have disabled shared objects. This is not a very large concern because of the large userbase of flash, however; Apple’s iPhone does not have a version of Flash and is not capable of using this API. Secondly, this API is part of the Dojo Offline SDK which has not had a stable release.

Of course this is still a far cry from an official, supported, implemented standard such as ones being proposed by the W3C (and subsequently ignored by Microsoft, Apple, Opera, Mozilla or bascially whoever DIDN’T propose the standard), but it offers a general step in the right direction.