I’m having some trouble moving ahead with Groovy Science, but ironically it’s because I can do too much.
I’ve always been a fan of Lisp despite the fact that I can’t get past the syntax to actually code anything. When I first saw Groovy, one of the many reasons I liked it was that it seemed to be a great step on the learning curve from Java to Lisp. What I didn’t realize was how deep of a step it was. Now that I’ve used Groovy for a while, I’ve started using it to prototype all of my ideas, as expected, but it turns out that it’s so easy to make these prototypes that I’m not sure exactly what work I’m saving Groovy programmers by writing a library. On the contrary, I’m starting to think the extra work of studying a library API might hinder people who want to do tasks as simple as this.
Well, I can sort of answer my own question: A library like the Java Collections Framework doesn’t solve a problem that is particularly difficult to get around on a case-by-case basis. It solves the frustrating task of making the same “easy” abstractions over and over again and coercing them to work with each other. This library is similar; treating something as a symbolic expression is already easy to do in Groovy, and that’s exactly why it can become a common metaphor, come up again and again, and eventually demand its own library.
Much of what I’ve been planning to contribute by Monday has been in the form of a Groovy prototype. I’m not sure exactly where to start translating that into actual library code, and that’s why I haven’t been submitting it. Whenever I figure out where to put it, it’ll start making its way into the library, I think.