jastrachan | 18 Feb 11:06 2005
Picon

Re: Re: static versus dynamic typing policy


On 18 Feb 2005, at 03:03, Mike Spille wrote:

> At 09:17 PM 2/17/2005, you wrote:
>> Mike Spille schrieb:
>>> At 01:30 PM 2/17/2005, you wrote:
>>>
>>>> Mike Spille schrieb:
>>>>
>>>> this is because the type of the field is dynamic, if you say can 
>>>> only be a closure this can't happen.
>>> I think it is plain that I know why it does this.  My point is that 
>>> this is somewhat different from "normal" field stuff.  "x.f()" looks 
>>> like a method call, and then suddenly the user will get 
>>> "MissingMethodException" or something equally confusing - how can 
>>> f() be missing, I just called it!  Well, it can be missing because 
>>> f() isn't a method, it's a field that is sometimes a closure and 
>>> sometimes not.
>>
>> ok, let's change x.f() to x.f.call()
>>
>> your script was
>>      X x = new X()
>>      x.f = { println ("foo")}    // x.f is a closure
>>      x.f.call()            // Function
>>      x.f = "Hey there"    // Now a string
>>      x.f.call();            // Runtime error
>>
>> I would still get a RuntimeException, it would still be a 
>> MissingMethodException. Again you can say: "how can call() be 
>> missing, I just called it!"
>>
>> I don't see your point here.
>
> The missing method is on f, not on x.  That's the difference.  The 
> x.f() syntax appears to be operating on the 'x' object.  But with the 
> current rules if 'f' is a closure then x.f() is actually operating on 
> the field 'f', not the object 'x'.  Think in terms of error messages.  
> In the groovy way, it's going to say something like "missing method 
> f() on class x".  In my way, it will say "missing method on x.f".
>
> In the call() syntax the system can tell you exactly where you goofed. 
>  In the f() syntax the system will give you a misleading message.

Sure - though the MetaClass is completely aware that its invoking the 
closure f, so it could generate a neater message...

>> [...]
>>> Groovy has a reputation - well deserved - for being confusing and 
>>> often emitting confusing error messages.
>>
>> mostly because things I would call bugs.
>
> No, alot of it is how its designed, how it works deep under the 
> covers.  In my discussion of probably error messages on x.f(), such a 
> message isn't a bug - it's by design.  By extension you can say that 
> Groovy gives you misleading and hard to diagnose errors by design.

Huh? Isn't the whole point of this JSR to help specify exactly what the 
semantics are (rather than just being an implementation)?

>>> The power users love Groovy for it.
>>> The many, many people who have tried Groovy and dropped it like a 
>>> cold fish hate it for exactly this reason.  You guys have a high 
>>> tolerance for errors and confusing stuff and slugging your way 
>>> through it.  Most people don't.  And it's rules and confusing 
>>> behavior like this that keeps most people away, and is why this list 
>>> has so few people left participating on it.
>>
>> we will see what future brings.
>
> Care to take a bet on how many people have tried Groovy and dropped it?

No - got any numbers Mike?

>  And how many have tried it and stayed with it?  Before you give a 
> quick answer think about it for awhile, and take a look around at the 
> remaining community.

FWIW - as folks in Python and Ruby have found - folks who complain & 
moan about stuff always seem to be the majority. Folks who just use 
stuff don't tend to mail :)

>>>>> You can consistently define rules along these lines - disallow 
>>>>> multiple entities with the same name at the same scope, and 
>>>>> defining lookup order when parenthesis are not used.  You could 
>>>>> make that work.
>>>>> In practice I think this will end up feeling like the "no dumb 
>>>>> statement rule".  It helps the compiler, but it doesn't help the 
>>>>> compiler parse more code successfully - instead it defines more 
>>>>> error conditions.  The "feel" here to me is that Groovy is 
>>>>> becoming increasingly finicky and highly sensitive to minor 
>>>>> changes in source code.
>>>>
>>>> I don't understand you here... the compiler does not neccesarily 
>>>> have to know if f() is a method call of a closure execution, the 
>>>> runtime can do that. Many things which can be done in Java can't be 
>>>> done in Groovy, because of the dynamic typing.
>>> Yes, you're right, I was using confusing terminology there and to 
>>> some extent imparting wishful thinking on the language.  Such 
>>> decisions are deferred until runtime.
>>> The problem is that this confuses people - there's no f() method and 
>>> Groovy won't tell me until runtime - and when it does tell me it'll 
>>> give me an error message that I likely will not understand until I'm 
>>> a Groovy guru.
>>
>> the messages need improvement, but I know more than one developer how 
>> migrated to python and saying runtime errors are no problem. Just 
>> because Java can do so much things at compile time doesn't mean all 
>> languages have to do that in the same way.
>
> I have nothing against dynamic behavior and semantics in a language.  
> But let's be honest, Groovy does it in a very half-assed manner at the 
> moment - all comments about MOPs aside.  Python (and Smalltalk, and 
> many other...) people deal with dynamic runtime errors because that's 
> really the way the language is.  And they aren't really burdened by 
> passing types around.  Groovy is pretty dynamic but still has types

Yes. Groovy is statically and dynamically typed. Currently the RI 
doesn't perform many compile time errors with static types - all errors 
are dynamic, but the static types are used in the bytecode and to 
export to Java developers static-typed view.

> - but the type information is thrown away or ignored much of the way.

Huh? See above

> In some way it's the worst of both worlds in the way that Groovy 
> approaches it.

I've said many times on this list, the aim is for the RI to give 
compile time warnings for static types + typeos. Right now its all 
runtime (for ease of implementation). However our biggest issue today 
is to tie down exactly what the language semantics are, let the RI 
implement them and have a decent TCK

>>> However - there is IMHO no good reason that Groovy has to be behave 
>>> this way.
>>
>> bad error messages are no good reason, yes. Sometimes they are so bad 
>> sso you only know there is *something* bad in the source but you 
>> don't know what.
>
> Oh yeah, the bad messages are a big problem.  But an equal problem - 
> and source of many of the bad messages - is that in many ways Groovy 
> was just kind of hacked together.  This isn't a diss to James et al - 
> it was an amazing feat.  But Groovy has reached the limits of where 
> you can go with hacking.  I've seen you do checkins into the CVS tree 
> - you can see it probably even better than I can.  The proposed new 
> rules aren't going to simplify or really fix anything, it's just more 
> stuff that James and a few others will attempt to hack in.

I don't really follow your reasoning here. We've a new grammar (not 
finished yet, but getting closer all the time) which helps to define 
more clearly the syntax without any ambiguities. One of the big 
complaints of folks was 'whats the grammar look like' - so we're fixing 
that.  The JSR is slowly going through the semantics so we can nail 
those too; and we're building the TCK to accurately define what the 
language is meant to be & how it should catch failures.

What are you suggesting we do instead Mike?

>>> As a team you'd much rather be cool than have a solid language that 
>>> just works.
>>
>> a solid working language would be cool..
>
> Yeah, it would.  What makes you think that'll happen?  James hasn't 
> spent any time on that in the past month, all his effort has been 
> spent on the ANTLR pieces.

Huh? See the cvs commit log

>
>>>>> As a final note, going the MOP route pretty much dooms you to 
>>>>> finding most of your errors at runtime -
>>>>
>>>> like python?
>>> No, not at all like Python.  Groovy looks statically typed, and has 
>>> some baggage around that, but in fact isn't.  If you declare a type 
>>> "String foobar = <whatever>" anyone from any language would expect 
>>> that you're statically typing foobar to be of type String.  But this 
>>> isn't completely true in Groovy, thanks to so much work being 
>>> deferred at runtime.  The thing looks like it has optional static 
>>> typing but it's only partial.
>>
>> yes, but why? I always thought this is a bug, a very big one.
>
> This is the way James made it, on purpose.  It's not a bug, it's how 
> Groovy works.

Huh?

How many times so I have to say; the reasons for static typing in 
Groovy is to

(i) expose type information to other Java developers, work nice with 
other Java code and allow IDE fun
(ii) allow us, one day, in the RI to implement static compile time 
checking

Users will get the benefit of (ii) when we implement it; its a tooling 
issue not a fundamental issue with the design of the language.

>>> You could certainly go with an all-dynamic language - but Groovy 
>>> isn't it, not by a long shot.  If it was you wouldn't be specifying 
>>> types everywhere no would you?
>>
>> we could throw them out ;) Of course we don't do that, because we 
>> want both, dynamic typing and static typing.
>
> I haven't seen much interest in static typing from the developers.

We've had static typing from day 1 to be able to work nicely with Java 
code to...

* overload Java methods - we use the JVMs method resolution mechanism 
which is static typed
* add concrete types to methods, so Java guys can overload from Groovy 
code or use static typed APIs

> What's there is broken and gets in the way more than it helps.  Given 
> the overall state of things it may indeed be better to jettison static 
> typing altogether.

Huh?

>>>>> and given the groovy implementation history those errors will be 
>>>>> hard to read and hard to fit back into the original code intent.
>>>>
>>>> You try to think of Groovy as ready fopr production, I do not do 
>>>> that. I think it has still a long way to go.
>>> I don't think Groovy is ready for production.  I think it will die 
>>> long before it gets there - and the attitude on this JSR list is a 
>>> primary cause of that.
>>
>> I didn't say you are thinking Groovy is ready for production, but ok, 
>> with all ,y mistyping and it's no problem to find misunderstandings, 
>> too. But it seems like you want to have Groovy be ready yesterday. As 
>> I said Groovy has still a long way to go and maybe it will die before 
>> reaching it. And if so the JSR list can be a reason for it. MAybe, 
>> maybe not.
>
> I've spent a great deal of time studying Groovy, the language and the 
> code.  Groovy could easily have been 1.0 and the JSR draft out the 
> door in December.  Guillaume has said that something like that isn't 
> possible because of time constraints - but I don't believe that's 
> true.  Groovy isn't 1.0 because no one seems very interested in making 
> it so.

That's utter rubbish Mike and you know it.

>  Time spent moving towards 1.0 instead have been wasted on other 
> things, such as the months spent on the ANTLR parser.

The time spent on the Antlr parser is essential to go 1.0 of the JSR - 
its to define a concrete, non ambiguous grammar that we can then use as 
EBNF documentation.

> Look at your own experience since you've joined.  Leaving your own bug 
> fixing efforts out for just a moment, how much real work has everyone 
> else put into getting Groovy production ready?

See the large amounts of CVS commits?

>  And how much work has been spent on fancy test reports,

Oh testing's bad then?

>  the ANTLR parser (still unfinished), the ANTLR->Groovy AST translator 
> (still unfinished), and on talking about adding yet more new features 
> before the existing ones really work properly?

What new features? We're fixing Groovy here - that's our main priority 
- see the roadmap & scope of 1.0. It seems whenever we try and do 
anything on the Groovy project you think its wrong. Don't fix the 
parser! Don't generate EBNF! Don't spend time on testing! Don't discuss 
how to describe the language in terms of semantics for the spec! Don't 
fix the ambiguities - just fix the bugs you have today?

>>> but in fact you have a bunch of hacks glued together with duct tape 
>>> and wire- and, amazingly, the JSR process is actually making it 
>>> worse.
>>
>> why is the JSR process is making it worse? Do you think having one 
>> person on the top doing all the decisions one and for all time will 
>> Groovy help to be more Javalike? I little while ago I had a 
>> discussion with someone people about Groovy and they said Groovy 
>> needs to get more away from Java cause Java's syntax is a pain.
>
> The JSR is making it worse because people seem even less interested in 
> knuckling down, fixing bugs and problems, and shipping the thing.  The 
> JSR has produced megabytes of useless discussions and a broken ANTLR 
> parser.

Hmmm; we're trying to fix the smelly & ambiguous parts of the language 
as a priority; so we can tie down the language so folks have a solid 
base - personally my biggest priority is to tie down 1.0 syntax ASAP so 
we can give users a solid base. Are there still bugs today - sure. Are 
there still bugs in all software? Sure. But if we stopped the JSR and 
just fixed bugs in the current RI, we may well never get chance to fix 
the language.

So our priority lately has been to tie down the language & get plenty 
of test cases.

Is it frustrating that Groovy isn't completely finished - sure.  Could 
we have just implemented C# 2.0 and saved some time? Sure. Could we 
have scapped lots of features like dynamic typing, closures, properties 
- and just made a few trivial changes to BeanShell / Java? Sure.

However we're making progress on Groovy; some of us around here like 
Groovy & where its going & we're working hard to achieve the roadmap 
and get to 1.0.

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


Gmane