Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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.

If you're reading from a file, and writing from a file, and maybe doing something else as well, that's really, really hard. And very few developers are capable of writing the correct try-catch to work with two resources maybe even three. It took me lots of goes just to read a goddamn file properly. Even just the little subtle differences that... you want to throw a close exception if you finish processing, without throwing an exception at that point, but if you finish processing and you've got an error halfway through you want to throw that exception and catch the close. So even just handling close properly on a file is hard.

Closures is a nice little trick from many languages, lisp, smalltalk, squeak and ruby that basically allows you to delegate the processing of collections or resources to a container object, and it calls you back for doing the trivial thing, like processing an object. It makes a massive difference especially in J2EE world, working with databases and closures is a dream. It is interesting the spring project has basically handwritten inner classes to mimic closures, which kind of works, but you end up with millions of these little interfaces which just have one method in, and you just think its... I mean it's a good solution for Java, but we could do a lot better. So closures are huge. To be honest it would be quite easy to add closures to Java, C# has done it with C#2, they've called them delegates. They're a little bit noisier than closures should be...

Operator overloading, anybody from a C++ background tends to get worried when that phrase is mentioned in mixed public. Just because it was the cause of so much issue and tension and bugs. If done correctly and safely, there is no reason why operator overloading can't work nicely, even if that just means arrays and Collections kind of feel the same in the language. Why should an array get a subscript operator, but a Map and a collection doesn't, it's kind of not fair. It's just about being a bit more fair, with the language.

Static and dynamic typing, this is a good pub debate, have a few beers and talk about doing static this and doing that in typing. If you like there are scripty people and anal static typer people.

"So which side are you on?"

I play both sides, I play for both teams. Static typing is great for systems programming languages, it's great for refactoring, it's great for IDE support and so on and so forth. However, just as you'll know with VisualAge and stuff, IDEs can, the first refactoring browser was smalltalk. There's that python refactoring... we met the guy in the pub the other day. You can do refactoring browsers and IDEs totally in dynamic languages, but modern java IDEs are just so good, that even if you just use static typing as extra metadata to make the IDE do great things for you. Due to the IDE kick it gives you I do quite like static typing quite frankly. But then there are sometimes when you just want to hack up a little script, and you just want the typing to get out of your face, and you just want to do something. Dynamic typing is great for verbose concise scripts.

There are also times when you're doing very dynamic things, with more and more networked and message oriented and web service oriented and all this kind of stuff, static typing doesn't really make any sense in those kind of dynamic worlds. For example if I'm processing a SOAP BLOB casting these things to specific types and walking a big object tree is pointless, because everything's getting increasingly dynamic and message oriented. So static typing has lots of value in infrastructure but increasingly in duct tape code there's little value.

I think both have got pros and cons, and it kind of depends what you're writing. If you're writing a library or a framework, static typing is good for refactoring. If you just want a little script to do something, you probably don't really care about static typing. I think there is a middle ground as well, where the language should be clever enough detecting static typing, under the covers, so it looks dynamically typed, but it kind of figures stuff out for you. If you say x = "foo" it should always know that x is always a goddamn String, unless you assign it to something else.

The idea behind Groovy was always to do both, to have static typing and dynamic typing. From an implementation perspective it was really easy to do everything dynamic to start with and actually never get around to doing anything static. But the idea was always that you could put type metadata there, that's mainly so an IDE can do something cool or whatever. One of the first reasons to put any static typing in was... The world's not going to all of a sudden one day turn Groovy and throw all the Java code away, so it's always going to be a partner in the Java platform. And so anything you write in Groovy you want to be able to give it as bytecode to a Java guy, and in Java land things have types, if everything is an Object, it's pretty hard to use.