A Shadowy Flight Into the Dangerous World of a Programming Language That Should Not ExistPosted: February 6, 2008
This is absolute lifeblood for top-flight engineers working in the Enterprise Software space. And it means that contrary to conventional wisdom we often build rather than buy.
All of this leads up to my favorite Guidewire tool, GScript, the programming language that shouldn’t exist. Consider the following problem faced by Guidewire: we sell fully-functional Claims, Policy and Billing systems to companies, but those companies invariably want to heavily customize our applications. How can we let them do so?
Java is our primary development language here at Guidewire. All of our core systems are built on top of it. Therefore you might expect that we let our clients extend/modify our apps using java. Unfortunately java is a poor fit for this task. Since it is statically compiled we would have to adopt a plug-in or dependency-based approach to extensibility. That falls down because it encourages a complicated architecture and it means that we developers would have to guess exactly where to put hooks for our clients in advance. I can pretty much guarantee we won’t be able to guess that very well. So java is out.
We need something that we can ship to our clients in source code form, so that they can edit, add and delete as they see fit. So we need something like a scripting language.
JRuby? Jython? Rhino? Groovy?
These are the best know scripting languages for the JVM. They all have a bit of momentum in the industry, but each has its drawbacks. One drawback that all of them share is that they are all dynamically typed. Now, without wading too deeply into the static vs. dynamic typing wars, our opinion is that static typing is necessary to support a good editor and to catch as many errors as possible early in the development cycle. If you buy that assumption, then none of the existing JVM scripting languages are viable.
Here’s a Crazy Idea: Build It
Against all conventional wisdom, Guidewire decided to allow some of it’s engineers develop a new language that satisfied all of our needs. That language is internally referred to as GScript. It supports all of the standard OOP tools and it allows us to ship our business logic to the client so that they can modify it directly. We also provide an editing environment for the language with support for code-completion and verification of all the GScript classes.
I’ll save another post (or twenty) for singing the praises of GScript, but that’s not the point of this post. The point of this post, for engineers out there looking for a cool place to work, is that Guidewire actually let us do it. Rather than settle for the conventional wisdom, Guidewire is willing to let good engineers do great things. GScript has put us, as a company, in a position that our more conservative competitors can’t touch.
And, most importantly for you, the developer, it makes Guidewire a killer place to work.