A Shadowy Flight Into the Dangerous World of a Programming Language That Should Not Exist

Guidewire is a kick-ass company is many, many ways, but the most important way it kicks ass for engineers is the organizations openness to any, and I mean any technological idea. This means that a good engineer can present a totally radical solution to a problem and, if people buy that that engineers has the chops to get it done, by and large he or she gets the go-ahead. This isn’t 20% time to work on pet projects, this means if you don’t like the solutions that the market has provided for a given problem (and, in a world of Struts, XSLT and javascript, who actually likes the available solutions) you get a shot at providing your own.

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.

The Problem

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?

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.



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s