It’s a little thing, but . . .

I just found myself writing the following tiny snippet of GScript:

print("Evaluating group with forms " + \ f -> f.Code ).join( ", " ))

It’s a minor thing, but in Java the map plus the join would look something like this:

String result = ""
for (int i = 0; i < group.size(); i++) {
  if (i > 0) {
    result += ", "
  result += group.get(i).getCode();

. . . or some variant thereof using StringBuilders, or possibly some function with an anonymous inner class followed by ListUtils.join() or something; either way it’s ugly and involves a lot of typing.  So ugly that I probably wouldn’t bother just for the sake of a debug message that I’ll delete in a day or two anyway. Being able to write it in one compact line of code is a tiny thing, but it’s a tiny thing that makes my life as a developer a tiny bit better.

This is really my first time writing an entire, complicated subsystem in GScript; it’s weird to say given that we’ve put so much work into the language, but the reality is that our system is largely structured as Java on the bottom and GScript on the top where we need configurability; most of us bounce back and forth between the two languages and most infrastructure is done in Java (and I mainly do infrastructure work here), but this time around I’ve managed to push an entire, complicated subsystem out into GScript both because we can make it more configurable that way and because I think GScript is a better language to develop in.

One thing I’m finding is another obvious advantage to having less code; when I’m developing something new a given line of code has a lifespan of about 48 hours before I refactor or rewrite it, so being able to do things in as little code as possible lets me iterate much, much faster since there’s less to delete when I change my mind and building up the new version goes faster as well.

Just another example of how all those little things really add up.

5 Comments on “It’s a little thing, but . . .”

  1. William says:

    “some are configured using Tomcat or WebLogic”

    Tomcat is a web server, but WebLogic is an application server, right?

  2. Alan Keefer says:

    I’m not sure which post you’re replying to there, but I was curious what the answer was, so I looked it up anyway.

    Apparently, according to this article, you’re correct:

    (It’s a terrifying article, by the way: Java EE as such seems committed to making applications as hard as possible to build, with as many moving parts as possible).

    I’ve always thought of Tomcat as an application server, but apparently it doesn’t technically implement all of the parts of Java EE that are required to actually count as an app server.

    Four our purposes Tomcat is fine, since we don’t actually use any of that extra stuff. But more accurately I should probably say “servlet container” instead of “application server” since that’s all we actually use it for in our application.

  3. Carson Gross says:

    I would also point out that the java version requires mixing the two fundamental operations together, so you can’t extract any logical building blocks out for later reuse. The whole program is tied to whatever the type of the thing in the collection is, right down in the nitty-gritty part of the algorithm. The GScript version composes functions together to achieve the desired output, with a clean, type-safe barrier between them. With this sort of composition, you get an exponential increase in functionality as you add additional useful methods.

    You do pay a performance price for this separation, since you end up iterating the list twice and materializing the mapped list in GScript. My take is that the expressiveness is usually worth the cost.


  4. Raoul Duke says:

    Re: little things adding up.

    such a hard thing to get across to people who haven’t experienced it. (i still can’t see what i’m typing off the right of this text entry field btw.)

  5. Carson Gross says:

    One other small point: the GScript is something you could conceivably type into a debug eval window. It makes exploring the runtime state of the system a lot easier when you have a good data structure toolkit to work with.


Leave a Reply

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

You are commenting using your 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