Artima Developer Spotlight Forum - Groovy Creator James Strachan on Scala

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Artima Developer Spotlight Forum
Groovy Creator James Strachan on Scala

69 replies on 5 pages. Most recent reply: Jun 14, 2011 3:47 PM by Wanderson Santos

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 69 replies on 5 pages [ « | 1 ... 2 3 4 5 ]

Carson Gross

Posts: 153
Nickname: cgross
Registered: Oct, 2006

Re: Groovy Creator James Strachan on Scala

Posted: Jul 20, 2009 9:29 AM

Just hang on Raoul. We'll have Gosu nee GScript out to the public Real Soon Now(tm).

Just as soon as we finish up our Duke Nukem Forever implementation...

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: Groovy Creator James Strachan on Scala

Posted: Jul 22, 2009 5:32 AM

Bill,
I have an example of the type of issue with Scala that I think makes it unsuitable for less proficient developers:

http://lampsvn.epfl.ch/trac/scala/ticket/2180

(note: he's working with the new collections in trunk, not the released version of Scala)

I've had similar experiences before. They don't happen much anymore. Not that I don't get error messages that seem to point in the opposite direction of the solution, but that I've learned how to "work with the compiler" when they arise so that we can communicate better.

The problem is I see a significant percentage of developers who would either be unable or unwilling to overcome these issues.

Here's an interesting thought for you: Scala the first language out of over two dozen where I've had to spend significant time fixing compile-time errors. I've come to appreciate that as a substantial strength of Scala, but it's a very different feel from Java or dynamic languages. It's like working with C++ templates on steroids (but with more concise error messages).

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: Groovy Creator James Strachan on Scala

Posted: Jul 22, 2009 8:02 PM

Hi Erik,

> I have an example of the type of issue with Scala that I
> I think makes it unsuitable for less proficient
> developers:
>
> http://lampsvn.epfl.ch/trac/scala/ticket/2180
>
> (note: he's working with the new collections in trunk, not
> the released version of Scala)
>
> I've had similar experiences before. They don't happen
> much anymore. Not that I don't get error messages that
> seem to point in the opposite direction of the solution,
> but that I've learned how to "work with the compiler" when
> they arise so that we can communicate better.
>
I had those experiences too, and for the most part don't have them anymore either. I too learned what the compiler really means when it occasionally gives a more obscure error message. I always felt this was a usability issue of the compiler rather than an inherent problem with the language. For example, one common error I think is to forget the equals sign before a method body. When you do that, the compiler error message gives no hint that this may be the problem. I think time could be spent to improve the user-friendliness of compiler error messages.

Martin also mentioned that type errors in general can be puzzling sometimes even for the gurus, and I believe they have some projects going with regards to making the errors more explorable. He mentioned that in the interview we did with him that we published in May.

> The problem is I see a significant percentage of
> developers who would either be unable or unwilling to
> overcome these issues.
>
I see your point.

> Here's an interesting thought for you: Scala the first
> language out of over two dozen where I've had to spend
> significant time fixing compile-time errors. I've come to
> appreciate that as a substantial strength of Scala, but
> it's a very different feel from Java or dynamic languages.
> It's like working with C++ templates on steroids (but
> t with more concise error messages).
>
Yes, it can look like a dynamic language because of the conciseness, but working with it definitely feels like working with a compiled language.

Martin Odersky

Posts: 84
Nickname: modersky
Registered: Sep, 2003

Re: Groovy Creator James Strachan on Scala

Posted: Jul 23, 2009 2:00 AM

> Bill,
> I have an example of the type of issue with Scala that I
> I think makes it unsuitable for less proficient
> developers:
>
> http://lampsvn.epfl.ch/trac/scala/ticket/2180
>
> (note: he's working with the new collections in trunk, not
> the released version of Scala)

Trunk at the moment is really bleeding edge. I guarantee that this particular problem will be fixed before the first beta of 2.8 comes out.

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: Groovy Creator James Strachan on Scala

Posted: Jul 23, 2009 8:10 AM

> > Bill,
> > I have an example of the type of issue with Scala that
> I
> > I think makes it unsuitable for less proficient
> > developers:
> >
> > http://lampsvn.epfl.ch/trac/scala/ticket/2180
> >
> > (note: he's working with the new collections in trunk,
> not
> > the released version of Scala)
>
> Trunk at the moment is really bleeding edge. I guarantee
> that this particular problem will be fixed before the
> first beta of 2.8 comes out.
>
I didn't notice that was a 2.8 issue. When I was starting out in Scala I did have to puzzle over some compiler error messages, but over time I learned how to interpret them so now I almost always know what an error message means. But I think there is always room for improvement in user-friendliness of compiler error message. (I think this is useful in any compiled language.)

One other thing that can be done in addition to improving the error messages generated by the Scala compiler is to provide compiler plug-ins that give higher level error messages. In ScalaTest, for example, I try to make mistakes compiler errors as much as possible, but sometimes I can't because you can't always express everything you want in the type system. For those I throw dynamic runtime exceptions with nice error messages, which for a testing framework is not so bad. But with a compiler plug-in I could make all of those compiler errors. But there's one more thing I could do. In many cases when I was able to express a constraint in the type system, the compiler error message that will result when a user makes that mistake is pretty low level. It talks about types whereas what they made was a "ScalaTest syntax error" of sorts. But my compiler plugin could in that case present to the user a higher level error message that is really talking about how they did something not allowed by ScalaTest, and here's how to fix it. This can be done for any API people use, and I think that would go a long way to helping users not matter whether they land on the "mainstream" to "guru" perspective.

X Y

Posts: 1
Nickname: discreteev
Registered: Jul, 2009

Re: Groovy Creator James Strachan on Scala

Posted: Jul 24, 2009 4:44 AM

I think that Bill's arrgument is basically aboout levels of abstraction and whether they leak. Its valid. I don't think a pilot should know exactly the configuration of all the servomotors that control the rudder. As long as the control he uses for it is consistent that's good enough. But Eriks point:

"But more commonly people will flip bits until their problem goes away, without any clear knowledge of why the solution they find works. Their code fills up with cruft. Eventually even small code bases become completely unmaintainable because they flip a variable here and unflip it there and null it out in this other place (which, btw, is a much more compelling argument for immutability than parallelism). They can't explain what their code is doing. They just know that pretty much everything there was put there to solve some problem, and are afraid to delete it because then the problem might come back."

This hits the nail on the head. However it is a problem with the person not the language. Sometimes a langauge with more intricacies makes it easier to weed this kind of person out. In my experience that used to be the case with C++. It was a sufficiently complex area that in discussing it with someone you figure out what kind of developer they are (particularly if they were cargo culters). With java its much harder to do this and Erik is right: There are plenty of people around who have no natural motivation to understand how things really work yet they work as developers.

Dan Sickles

Posts: 9
Nickname: dsickles
Registered: Mar, 2007

Re: Groovy Creator James Strachan on Scala

Posted: Jul 24, 2009 10:35 AM

The more on studies X, the more nits one may find. One may also find more gems.

For me, gems/nits is high with Scala. It just works like python just worked for me for so many years.

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: Groovy Creator James Strachan on Scala

Posted: Jul 24, 2009 5:49 PM

> This hits the nail on the head. However it is a problem with the person not the language.

The language needs to fit both the problem and the team.

> Sometimes a langauge with more intricacies makes it easier to weed this kind of person out. In my experience that used to be the case with C++.

This is an interesting point. I agree.

Martin Odersky

Posts: 84
Nickname: modersky
Registered: Sep, 2003

Re: Groovy Creator James Strachan on Scala

Posted: Jul 25, 2009 4:27 AM

> > Trunk at the moment is really bleeding edge. I
> guarantee
> > that this particular problem will be fixed before the
> > first beta of 2.8 comes out.
> >
> I didn't notice that was a 2.8 issue.

It's not. But the 2.8 library design caused this problem to appear more often, and more severely. I had noticed it already myself, and put fixing this on my to-do list.

The problem is that, when typechecking a method call with a known expected type, we immediately fix the method's return type to be a subtype of the expected type and propagate. In this case this led to the instantiation of one of the type parameters of the method. Early propagation is good because it gives us more type information that can be inferred in the arguments of the method call. But in this case it was surprising. I think what needs to be done is to first check the call with the expected type as before. But if that fails, one should re-check with no expected type. If the second typecheck succeeds, one should then take the computed type of the method call and match it with the expected type. This match will almost certainly fail, but it should produce a less surprising error message.

So I think we can fix this problem, and we can apply a number of tweaks for other common problems. To solve the problem of understanding type error messages in general, I think we need to pass from simple error diagnostics to an interactive exploration of type-checking. Something like a "type-debugger". That's an exciting topic for future work.

Cheers

-- Martin

Wanderson Santos

Posts: 2
Nickname: wanswins
Registered: Jun, 2011

James Strachan ain't father of Groovy

Posted: Jun 14, 2011 3:47 PM

Guillaume LaForge is the father of Groovy with all Groovy Team are doing a wonderful job!

Father isn't those who create, but those who make you son grow!

IMO Groovy will be the long term replacement for Java because today just because it innovate! Groovy breaks the trade-off "dynamic language vs. performance".

For those who want to see: http://stackoverflow.com/questions/1404917/groovy-vs-scala-vs-jruby-vs-closure-vs-jython/6236500#6236500

Groovy is a corolary for "Premature optimization is the root of all evil" (DonaldKnuth)

Flat View: This topic has 69 replies on 5 pages [ « | 2 3 4 5 ]

Previous Topic

Next Topic