geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <>
Subject Re: Groovy questions
Date Fri, 28 Nov 2003 15:38:34 GMT
Hi Olivier

On 28 Nov 2003, at 15:29, Olivier Lefevre wrote:

> So, here we go again, after a false start ;-)


Incidentally I've CC'd the groovy-dev mail list in case anyone else 
fancies a syntax rant too :)

> First, I think this is a very interesting project: I agree 100% that 
> the
> problem with jython is that it comes with too much unneeded python 
> baggage.
> I like the Groovy semantics but I have some issues with the syntax.
> First, I really HATE this bracket stuff.
> <flame>
> In languages with brackets and using the "standard" (i.e., brain-
> dead) formatting style, one always ends up with insanities like:
> foo = swing.frame(title:’Cheese’) {
>  panel {
>     borderLayout {
>       center {
>         table(model:new MySpecialTableModel(someParam))
>       }
>       south {
>         panel {
>           button(text:”Eat", actionListener:{ bar.eatCheese() })
>           button(text:"Cancel", actionListener:{ bar.close() })
>         }
>       }
>     }
>   }
> }
> Looking at this code what do you see? Nothing but brackets. Even
> though they are totally superfluous!! Why do even seemingly
> intelligent people go for this? This is so offensive. On the one
> hand you pass yourself as a hacker who breathes code and whose
> idea of fun is to design new languages; on the other you write
> the above, which basically says: hey, I don't care if my coding
> style emphasizes what is least important, is just plain ugly and,
> in short, is dumb shit: it's just code, folks! That may be the
> right attitude for a code monkey but not for a language designer!
> Getting rid of brackets would have the great advantage of making
> this discussion pointless.
> </flame>

Care to give an alternative suggestion? The above is way cleaner than 
XML (which has close tags as well as open tags and all those pointy 
brackets). Nested markup typically needs some way to mention inner & 
outer blocks.  Take any XML markup & try do it without some kind of 
token to tell the parser what the tree looks like; its quite hard 
without a token. We're using {} for consistency with closures & Java 
blocks etc.

FWIW any good IDE should be able to auto-format & highlight missing { 
or } so it should be real easy to edit.

Though I suspect you maybe are thinking about python style indentation? 
Typically that just saves typing 1 char. I'm not yet convinced by 
python indentation... Saving 1 char press per block seems a small price 
to pay to avoid tabs / spaces bugs.

> OTOH, your use of semi-colons seems inconsistent. Why
>    collection.each { i | print(i); };
> but
>    [1, 2, 3].map { x | return x * x }
> in which _both_ semicolons are absent?

Because semicolons are optional. And some of the documentation / sample 
code is old & was written when they were mandatory :)

> As with brackets, I think
> semicolons would be best dispensed with, although they are not
> nearly as obnoxious.

Agreed - they've gone. (Or at least are optional).

So you can use them if you need to.

[1, 2, 3].each { x = it * 10; y = it * 100;, y) }

> And while we are on this topic (but this is probably due to my lack
> of familiarity with continuations, although I use CPS-style code in
> Java a lot), how can print(i) in
>    list.each{ i | print(i); };
> be said to "maintain state across invocations"?

I'm not sure what that means :)

FWIW how do you do CPS-style coding in Java?  Just wondered what 
approach / tool you use for this? (CPS == Continuation Passing Style 


View raw message