January 20, 2005
Special Cases

Very interesting London Java Meetup last night. It was nice to see Darren and Steve along for the first time, and I had a very interesting chat with James about Sun's new interest in dynamic languages, and Groovy, his baby. (Jez is also working hard on Groovy at the moment.)

It's interesting to see the differences and similarities between the philosophies of Groovy and Python. One thing that James and (channelling) Guido agree on is that simplicity is good. They disagree on what constitutes simplicity, though.

Take functions for a moment. In both Python and Groovy, functions and methods are 'first class', which means that they are objects in their own right, and can be passed around like any other object. They differ in how that's done, though.

In Python, a function is called by putting parenthesises after its name:

>>> def spam():
...  print "spam's been called!"
... 
>>> spam()
spam's been called!

If you want to refer the function object, you just leave the parenthesises off:

>>> spam
<function spam at 0x0117CDB0>

This makes it easy to pass the function around:

>>> eggs = spam
>>> eggs()
spam's been called!
>>> def chips(a_function):
...  a_function()
... 
>>> chips(spam)
spam's been called!

To me, that's nice and simple. No special cases. As Tim put it, "special cases aren't special enough to break the rules". A function is an object, names are bound to objects, using the base name refers to the bound object.

"Ah!", says James, "but 99% of the time when a newbie leaves the parenthesises off, it's a mistake. That want to call the function." This is probably true. So in Groovy, if the function takes no arguments, you can call it without parenthesises. If you want to refer to the function object, there's a special syntax for that. (Perhaps James or Jez would care to give an example here?) The 'normal' case gets the normal syntax, and the unusual case gets the special syntax. So, is this simpler?

Another example - self. Python requires all methods to take an explicit self argument. After all, a method is just a function belonging to an instance really, and it's simpler to pass that instance explicitly. No black magic, and it makes injecting new methods into classes and instances at runtime simpler. But you always need a reference to the instance, though, so in Groovy it's is available implicitly. It's not like you need to dynamically add methods that often, is it?

To me, having all this implicit stuff is more complex than doing everything explicitly. But to James, keeping the common case simple to write is simpler. Who's right? Who knows. I like Python's approach myself, but it's not obvious to me that James is wrong.

I'm also sad to say that James is starting to understand what it must be like to be Guido, attacked every time you propose a change. Bloody nice chaps, both of them, so this is a real shame.

Oh and where were you, Sam?

Posted to Python by Simon Brunning at January 20, 2005 01:52 PM
Comments

Last night was fun, sorry I had to split so early.
This avoiding beer lark is so much harder when I'm surrounded by it (didn't see that one coming).
Next time I will stick around for a tad longer and ask some more questions about all these funky new projects I keep hearing about.

A quieter venue would be good too! :-)

Posted by: Darren on January 20, 2005 03:24 PM

Sounds like good reasoning to me. I like the changes that groovy is doing. Having to put "self" as the first parameter for instance methods in python has always been stupid. Boo is another language that doesn't require "self" either.

Posted by: groovy on January 20, 2005 05:58 PM

Any comments on;

http://www.pyrasun.com/mike/mt/archives/2005/01/09/20.57.06/

I had a look around the wiki and to that extent have to agree with Mr Spille, the specification section in particular is just absent;

http://docs.codehaus.org/display/GroovyJSR/Specification

Which tends to support the assertion that the language as such just exists in James' head. Not that that's a bad thing, but it is always better to write these things down.

Anyway, as Bruce Eckel says you'll have to wrench Python out of my cold, dead hands ;-)

Posted by: Andy Todd on January 20, 2005 10:05 PM

Some people have unrealistic expectations about where Groovy could and should be in terms of maturity, and perhaps some Groovy advocates are to blame for putting out hype.

Never-the-less, things are rocking along on the jsr mailing list and Groovy looks set to be a serious choice for enterprise development within a couple of years.

Once it gets included as a standard part of a major IDE, there will be no turning back; even Andy will have to learn Groovy ;)

Posted by: Alan Green on January 20, 2005 10:24 PM

Claiming that the need to use 'self' is "stupid" is just preposterous. It may or may not be the *best* solution, but it works. It makes some jobs easier, and it's *conceptually* simpler. This last is very important to my mind.

Still, that's the kind of brainless response that one should expect from someone who conceals their name.

And if I hear about bloody Boo one more time, I'll *scream*. I've had enough of it from that bloody tosser on c.l.spy.

Moving on to responding to the quality part of the audience. ;-)

Groovy exists in implementation as well as in Jameses head, Andy. Implementation is the best documentation there is. ;-)

Hopefully, you should never be forced into any one of the JVM scripting languages, Alan. If the scripted application uses the BSF[1], as it should, one can choose Jython, Groovy, BeanShell, Rhino, JRuby, any several others - any one of the BSF supported languages.

[1] http://jakarta.apache.org/bsf/

Posted by: Simon Brunning on January 21, 2005 09:15 AM

True Simon, but if you read the article he says that the Groovy that exists in implementation is about to be superceded by the Groovy that exists in James' head. And that the two are not compatible.

I had a look around and couldn't find any documentation of the great strides of progress that were made at the two day Groovy meeting last year. Nor does the mailing list appear to discuss anything other than where (or where not) semi-colons should appear.

But then I'm just a natural cynic.

Posted by: Andy Todd on January 21, 2005 12:55 PM

I was briefly on the Groovy JSR committee while at HP, but bailed because I felt that it was trying to out-Perl Perl. I posted my thoughts at the time in http://pyre.third-bit.com/blog/archives/000096.html ; has anyone seen any signs since then of the situation improving?

Posted by: Greg Wilson on January 21, 2005 01:47 PM

Better leave it to James, Jez or one of the Groovy boys to answer *that* one, Greg...

Posted by: Simon Brunning on January 21, 2005 03:21 PM

Horses for courses; what one person finds simple, another finds complex.

However in particular, this discussion...

"Ah!", says James, "but 99% of the time when a newbie leaves the parenthesises off, it's a mistake. That want to call the function." This is probably true. So in Groovy, if the function takes no arguments, you can call it without parenthesises. If you want to refer to the function object, there's a special syntax for that. (Perhaps James or Jez would care to give an example here?) The 'normal' case gets the normal syntax, and the unusual case gets the special syntax. So, is this simpler?


Was specifically about people missing off parethesis from method calls, confusing properties with methods - and getting terribly confused as they were returned a pointer to a function, when they wanted the value of a property. So its this one thing were were discussing - and in Groovy its actually pretty rare to want a reference to the function itself - its very very common for people to lookup the property 'size' when there's only a method called size() and no property - so to avoid very common typos and confusion, we're probably gonna add some helper method to lookup methods, rather than sliently behave as Python does.

Maybe Pythonistas don't use Java Bean properties that much & use much more reflection?

Posted by: James Strachan on January 24, 2005 01:07 PM

I can't be the only person that thinks "the Groovy boys" sounds like a series of novels for children.

Perhaps, like the high profile Java bloggers, they arrive at the scene of the action/crime (dynamic languages) way too late and then tell everyone how they've just discovered the wonders of forensics (and how much more they know about it than anyone else there).

Posted by: Paul Boddie on January 24, 2005 03:42 PM

In Groovy the team has added in a number of special cases to help the user. The problem is that the team has made it easier for the very simple cases but has made slightly more complex code a complete nightmare. What James has left out in his explanation on parenthesis is that by leaving these off, he's created ambiguity hell and Groovy often gets confused at what the user means.

This is the overall theme of Groovy - beautiful for simple cases, utterly confusing when you look at real code that's not full of one-liners and single-expression statements. So much energy has gone into special cases that bare-bones basics have been ignored. So there's no mechanism for including one script from another one. If a variable name anywhere in a script is the same as the script name, you get a bizarre error message (because script Foo.groovy becomes the Foo class). Exceptions are handled completely wrong. I could go on, but there's little point. James has special cased Groovy into oblivion.

Posted by: Mike Spille on February 3, 2005 11:01 PM

Never mind, Mike - there's always Python/Jython, a thing of elegant simplicity with next to no special cases.

Posted by: Simon Brunning on February 4, 2005 10:50 AM
Post a comment
Name:


Email Address:


URL:



Comments:


Remember info?