Saving time and expertise

Last week I saw a couple of mentions about libraries that serve roughly the same technology, one coming from a mega-corp, the other from a single developer, and it got me thinking about other similar technologies.

Both of them purport to enable you to write code in your favorite high-level language (HLL) which, when compiled, produces not machine code or IL or p-code (showing my age here!) but Javascript for AJAX applications. To which I can only say, wow.

The first library is the Google Web Toolkit that enables you, to quote, "write your front end in the Java programming language, and the GWT compiler converts your Java classes to browser-compliant JavaScript and HTML." The toolkit takes care, though its own library, of browser quirks so you don't have to. You even have, and this is amazing, debugging abilities using the original Java code.

The second library is much less grand, but no smaller in scope. It's Script# and enables you to do roughly the same in a C#/.NET world.

Both of these toolkits enable you to concentrate on the language you know best (Java or C#) and ignore the languages you're not that familiar with (Javascript and HTML). Indeed that's what a normal compiler enables you to do as well: concentrate on C# or Java or Delphi and ignore the languages you don't know (IL and assembly). You trust the compiler to do the right thing so you don't have to worry about it.

This idiom pervades what we do as developers. We abstract the real world of hardware and the operating system behind some simple yet flexible and expressive language and framework and we gain huge benefits in productivity and functionality.

It's not the complete and utter panacea though. There are still some times when you need to get under the hood. But it doesn't matter: in the vast majority of cases, the hood can stay resolutely closed.

So, for example, using an ORM like our XPO (eXpress Persistence Objects) framework makes sense in the general case. You would rather write C# code that accesses an ORM which then forms the exact SQL statement needed on the fly, than having to write a generic parametrized stored procedure that can do the majority of cases. You need the ability to switch database engines more than you need the highly-optimized T-SQL stored procedures that give you the last percentage of speed gain.

Look also at all the discussions on DSLs (Domain-Specific Languages). All these DSLs are are an abstraction of some problem domain in some textual form (sometimes XML) and some "compiler" or "interpreter" that does the right thing given some specification or "program" in the DSL. The developer writes something in a high-high-level language and the compiler converts it to a normal HLL or interprets it directly.

Ant works the same way, but applied to building applications. You write your build script as a series of tasks that need to be done. The tasks are simply Java classes that you (or more generally someone else) has written.

The thing is, we all have way more software to design and develop than we have time or resources to do it. Any alleviation of this problem is good for us all. I'd try out these toolkits and libraries in your next project to see if they help or hinder.

Free DevExpress Products - Get Your Copy Today