jastrachan | 7 Jul 16:18 2004
Picon

Re: feedback from students


On 7 Jul 2004, at 14:06, Wilson, Greg wrote:
> I had two students at the University of Toronto build a Scrabble
> program in Groovy, and then asked them what they thought of the
> language.  Their impressions are below.  Both are strong students,
> with lots of Java; in addition, David is a sys admin, and knows
> his way around both Perl and Python.
>
> I'll have a fresh set of students in September, and would be happy
> to experiment on them (insert mad-scientist laugh here).

:)

Thanks for the feedback, this is most useful - more inline

> At the outset I had claimed that Groovy would be useful for writing
> our Scrabble program; I figured that being an offshoot of Java would
> enable me to program in a familiar style, as well as make it possible
> to perform list, string /regex operations etc. in a convenient manner
> (as is possible in most scripting langs).
>
> However, it turned out that everything I wanted to take for granted, I
> couldn't.  I expected easy-to-use Arrays/Strings etc. and instead got
> ambiguity in type definitions that made their operation unclear.
>
> (i.e. Why can't I define 2d arrays using [][] syntax?

We've not implemented that yet :)

> Is a List of
> chars a String?

No. We can't really change java.lang.String to implement List, we're 
constrained by the Java platform to some degree.

>  Why are Strings immutable if they're supposed to be
> Lists of elements?

Ditto

> My mental model of Groovy is based on Java.

Someone who knows Java should know that Strings are immutable and that 
String does not implement List

> Yet the introduction of
> the ubiquitous List syntax [a,b,c] only confounds me when I try to
> perform operations as mentioned above, as it is no longer clear where
> it fits in. If Groovy is to take advantage of typelessness then it
> should at least afford me the convenience of allowing/disallowing the
> same operations on supposedly similar types such as Lists and Strings.

What operations are disallowed on Lists v Strings? I'm not aware of 
any. If anyone finds any we can quickly fix it.

>
> One bright spot I liked about Groovy is the ability to use closures.
> They offer benefits not unlike function pointers, yet are easy to
> handle and pass around.  The syntax leaves something to be desired
> though; coming straight from a Java background I can't wrap my head
> around it so easily, which is a shame since this is built on the JVM.
>
> The regular expression syntax had me totally confused but I'm sure
> Dave can tell you all more about that.  Let it suffice to say that the
> Java syntax is cleaner than Python =~ and whatnot (from my POV), which
> is not something to write home about.  Groovy shouldn't be touting its
> better use of regex's if this is indeed the case.
>
> Greg, I believe you mentioned a rough metric for success might be
> something like "most Java programmers should be able to pick up Groovy
> after a quick tutorial and write 'wc' in 1/2 an hour".  I doubt this
> is possible given all the roadblocks that throw off Java programmers
> at the outset (and the *total* lack of documentation).

Documentation is weak but will improve (e.g. there are various books in 
the making).  Apart from the above, were there any other roadblocks?

> Furthermore, I would venture to say that Groovy at this point doesn't
> know what it wants to be; it seems to be catering to too many
> different masters at once.  While Greg has convinced me that making
> Groovy comprehensive in nature at the outset is a good thing, it
> should adhere to whatever model is most comfortable for its intended
> user base (*hint* Java *hint*) and develop from there.

Thats pretty much what we've done; we've only added a few things to 
Java (dynamic typing, native collection/map syntax, closures, operator 
overloading, autoboxing etc).

> While I applaud the fact that the conventions Groovy steals from
> Python/Smalltalk etc. aren't the *only* ways of doing things, I wish
> there were but a single way to accomplish that goal that was *usable*
> enough that I wouldn't have to resort to Java-style antics (and fail
> unexpectedly when those features aren't supported).

I'm not sure I follow this bit.

>> Why are Strings immutable if they're supposed to be Lists of
>> elements?  Is there some implicit conversion going on here?... and
>> so on, and so forth).
>
> Strings are immutable in Java, so I suppose it's not a huge surprise
> that they're immutable in Groovy. What bothered me was that there's a
> distinction between Lists and arrays that isn't immediately
> apparent. If you try printing an array you'll get a [a,b,c] value, and
> this creates a false feeling that lists and strings are
> interchangeable: they aren't.

Agreed. Maybe we should use a different format for arrays being output? 
FWIW it'd be good if Groovy auto-coerced from one to the other so they 
feel the same

> I was disappointed that the "if element in list" context of the "in"
> keyword wasn't carried over; "in" is only used in "for" loop
> declarations and such.

Thats a neat idea - we should do it - have added it to the JSR wiki

http://tinyurl.com/3fael

>> The regular expression syntax had me totally confused but I'm sure
>> Dave can tell you all more about that.
>
> I got so fed up with thinking about the ambiguities (I'd have looked
> it up in the docs if there were any).

http://groovy.codehaus.org/Regular+Expressions

>  I didn't want to bother testing
> out various cases of "what does this mean in this context" so I just
> used the Pattern and Matcher classes from Java.

Thats fine - folks don't have to use every bit of syntax sugar if they 
don't want to

>> Let it suffice to say that the Java syntax is cleaner than Python =~
>> and whatnot (from my POV), which is not something to write home
>> about.
>
> That's actually a Perl thing, I don't think it's in Python (somebody
> correct me if I'm wrong). I don't like it, and if I remember
> correctly, Greg mentioned not liking it either. I really do prefer the
> somewhat clumsy way Java does it, instantiating Patterns and Matchers
> and whatnot.

Each to their own; stick with the good old Java approach then

>> While Greg has convinced me that making Groovy comprehensive in
>> nature at the outset is a good thing, it should adhere to whatever
>> model is most comfortable for its intended user base (*hint* Java
>> *hint*) and develop from there.
>
> While Greg made an example of C++ and Perl as having functionality
> "grafted" on (objects) with the seams still showing, I somehow feel
> that Groovy suffers from much the same folly. It's like Java, but
> different, but the same, but different. It _is_ supposed to be a
> scripting language for the JVM and so the interaction with Java
> objects is necessary, but I felt like I was writing Java code that was
> enhanced in some ways and crippled in other very crucial ways (the
> ambiguity of arrays vs. lists, for example;

There's no ambiguity; lists and arrays are quite different - they are 
the underlying JVM types of Object[] or java.util.List - we've just 
made them polymorphic so you can use them in the same way without 
worrying too much about the difference. But since the idea is to work 
with existing Java code - which uses both arrays and lists extensively, 
the Groovy language has to support both.

>  Python got away with just
> lists, so I'd think that Groovy could too - just automatically
> type-convert arrays and any other common sequences to lists instead of
> requiring your users to fiddle around).

We started out just using Lists. But then folks wanted to make custom 
array types so that they could pass them into Java methods - so we 
added it.

> Finally, one big complaint: the error messages are atrocious! One of
> the best examples (which I bothered Greg about last night) is that
> when you use a closure incorrectly (incorrect parameters) you're told
> so, but you're not told where, or which closure. Closures can be
> called different things in different scopes, I realize. The error
> message should refer to the closure by the name it has in the scope
> where it is used incorrectly.

Agreed. We really need to fix this issue - its called by incorrectly 
wrapping/unwrapping exceptions in nested closure calls...

http://jira.codehaus.org/browse/GROOVY-255

> Also, parsing errors (curly brace
> mismatches, to be specific) are reported as being at line -1 in your
> code -- extremely frustrating. Also, to make matters worse, all Groovy
> error messages are suffixed by 3 pages of Java stack trace. While
> probably invaluable to those developing Groovy, they're irrelevant to
> those of us writing code IN Groovy.

If you're using the interactive shell, it tries to hide most of the 
stack trace and just print the main error. Depends how you're using 
Groovy though,.

> All in all, it was fun to use something new and crazy but Groovy in
> anything resembling its current state will prove more hassle than its
> worth.

Shame! :)

James
-------
http://radio.weblogs.com/0112098/


Gmane