Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

James Strachan's keynote speech
Groovy Conference November 2004 (London)
(transcribed by jez)

So welcome everybody, it's good to see you all here. I've just
hacked together
a little presentation just to kind of give the state of play of
groovy, what it's
all about, what we're trying to do, what are the sucky bits we really need
to fix really soon, and some of the things we might do in the future.

First off, why even bother with groovy, why not just use smalltalk, python,
ruby and stuff? To me the big thing is platforms, platform is far more
important than language syntax. The JVM, the Java platform, the VM rocks, the
libraries rock, the platform, the community, the tools, the
developers. There is no reason why we can't build whatever languages
we want that play nice with the platform.

One of the whole reasons why Groovy came into being was, when you
start writing
things like porting python and ruby and smalltalk to java, you kind of end up
with a leaky abstraction. To support smalltalk semantics, they're
quite different
to java, or to support python semantics it's really quite different and you end
up with... kinda like two worlds, python objects over here, java
objects over here,
kind of bridges...

The whole aim of Groovy was to try to do something that felt like Ruby and
Python and Smalltalk, but where everything was pretty much mapped onto the VM
and Java objects, there is no impedence mismatch, there is no abstraction layer,
everything works on real Java objects and is built on the Java platform.

It's worth looking back at where Java came from, and what the world was like
when Java was invented. I think Sun's done a great job with Java,
Java the language I'm talking about, well the platforms great
anyways. Java the language, when it
was created, one of the main reasons it got adopted was probably Applets, which
is kind of funny. But the reason people, geeks like me jumped all over it, is
because we wanted a better C++.

C++ was the systems programming language of the day, well there was smalltalk,
pretty much people jumped on it as a better C++. It was cross platform, easy
to use, modular so on and so forth. And it was much less 'sucky' than C++

In the Java days, we tended to write everything, there was hardly any reuse,
the only thing we reused, was maybe you could rewrite like x, you might have
a stream library STL, but pretty much people used to write everything themselves
on every project. The world's changed quite a lot now, we are
integrating software
components more than actually writing them. So the requirement for a systems
programming language is kind of decreasing slightly and the need for more of a
glue, duct tape kind of thing is increasing with time. Most projects I work on
now, we're reusing 80-90% of all the codebases is just reuse, be it spring,
hibernate, tapestry, plus the JDK as well.

The main requirements that was set for Groovy, which were never particularly
articulated terribly well, or documented, which is the way on lots of
open source
projects. Was really that, it's an attempt to make something that's pretty
much like a high level language, or scripting language, like Ruby or Python
or Dylan. Dylan is probably one of the closest. A lisp guy would probably just
say we're reinventing lisp again, which is fine as well. The main idea is it's
got to map cleanly to Java bytecode. It needs to work with Java APIs and Java
Objects. The root of all the object trees is java.lang.Object.

We want it to be a Java friendly syntax, now we can divert from Java, we
don't have to be backwards compatible, in fact, we can't be really. There
are a few smelly parts in Java, like equals, the == sign means different
things depending on whether your using a primitive type or an Object
type. So as soon as you go into dynamic typed world, and you've no
idea whether it is an
int or an Integer, it's pretty hard in a dynamic language to know the difference
between the two. So == means comparisons for primitive types, it means identity
for Object types. One of the first bugs I hit, and I hit it all the
time, is writing x == 3, which we just naturally do without thinking
in Java, and expect
that to be a comparison. Hardly anybody puts == with Object types, because you
hardly ever want to do identity based comparison. I think once in the last
ten years, I've done an identity based comparison, it's not something
that people really do, it's very rare.

So because we made that change, we pretty much can't be backwards compatible
with Java, because we made that little, subtle change. == always
means equality,
which is what people always really mean anyway. So we can't be completely 100%
backwards compatible, but the idea is to be fairly looky likey. The ultimate
vision would be to be able to cut and paste Java code in your IDE straight to
Groovy script. It can hopefully take out most of the crap you type,
be a little bit
more concise, but we're trying to be Java like, but not necessarily 100%
compatible. And basically just sit on top of J2SE.

So a quick glance, if you wanted to in a very brief way, say what is
Groovy. One
of the first things, I remember I was going on holiday for a weekend,
and the plane
was late, so I thought, what shall I do, my wife went shopping,
because she loves
shopping, so I thought "Oh there's an internet cafe, let me go to
browse.' And I
couldn't think of much to read, so I thought "hey, I'll learn python". Bit of a
geek and it's quite sad, but hey I'll learn python. So I sat there for a couple
of hours and thought "you know what, this is kind of nice, I can
create, in a tiny
amount of text, a collection, a dictionary, I can add stuff to it,
sort it, search
it, do all that stuff". We work with collections and beans and whatever all the
time, and it was kind of embarrassing that Java is so verbose for
doing something
so trivial as making a List of Objects. The whole difference between arrays and
Lists, it makes you feel a bit dirty when you see what it should be
like. So that
was the first thing to get right, working nicely with beans and collections.

Closures are one of those things that take you a little time to realize why
they're good, but once you've seen them you just love them. For me the best
bit of closures is working with resources, whether that's files,
databases, message
brokers. I only really realized this when we started implementing
closures, with
IO. Doing something as trivial as loading a file, and processing it
line by line
and making sure you close the file properly if an exception occurs is
surprisingly
hard to do with one resource.

  • No labels