Software Development from Ryan

Dietrich Kappe has a nice post on the Pathfinder Agile Ajax blog about Bruce Johnsons remarks on the complexity of building tools for dynamically typed languages.

I think its important to note that, along with the halting problem, the reason that dynamically typed languages like javascript don’t have great tools is because they started out as languages for small tasks. Their advantage is that they don’t need complex tools - maybe just a text editor. You can whip up a script, debug, and maintain it very fast.

In contrast, typed languages are designed from the start for large maintainable projects. The extra language features they have are there for more than the support of their tools. They support readability, organization, and compile time error checking.

In other words, why make a tool for a language that wasn’t designed for tools? Why use a scripting language for a large project? Also, why build applications on web technology designed for documents? I can actually answer that last quetion… but another day .

There was some talk about Dojo during the GWT podcast with Bruce Johnson, Robert Hanson, and myself comparing it to GWT to build Ajax applications. Dojo has been around longer and may be more mature, GWT leverages java’s development tools, etc.

GWT really excels over the development lifecycle but the one area that I thought it fell behind, and did not think it had much of a chance of catching up, is with the fast tweak/test cycle that fits scripting so well. With GWT you would refresh your browser to see your changes but since GWT compiles java to javascript this would be much slower.

A release candidate for GWT 1.2 was released yesterday with an speed improvment for refreshes during debugging. Bruce Johnson suggests the most efficient develop method with GWT 1.2 in this issue report:

Now caching between runs. Startup is 20-30% faster, and refreshes are much, much faster. Since refreshes are very fast now, the most efficient way to develop is to leave a hosted browser open, make source changes, then click “Refresh”.

I tested this with gpokr and found that startup was 25% faster and refresh was about twice as fast - still not as fast as a refresh of a fully compiled gpokr running in a browser which is a remarkable 1 second. Compare this to the 7 seconds it takes to load the Dojo sample mail application in firefox, (this app seems to have far less functionality than gpokr so it should be faster, this illustrates the advantage of compiling code to javascript eliminating the need for nice looking, readable, debugable javascript that is a tradeoff with speed).