The Artima Developer Community
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

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 69 replies on 5 pages [ « | 1 2 3 4 5 | » ]
robert young

Posts: 361
Nickname: funbunny
Registered: Sep, 2003

Re: Groovy Creator James Strachan on Scala Posted: Jul 8, 2009 8:15 AM
Reply to this message Reply
Advertisement
Have you sent Spille a fiver?

Thomas Mueller

Posts: 18
Nickname: thomasm
Registered: Jan, 2009

Re: Groovy Creator James Strachan on Scala Posted: Jul 8, 2009 10:31 PM
Reply to this message Reply
> Fred Garvin
> Why would we switch to Scala?
> Java evolve in the direction of C#

I believe Scala is going in this direction, maybe a bit too far I admin. I think some features should be removed from Scala (not sure which ones, maybe Symbols?) so it is easier to learn and harder to make mistakes.

> monoglot

Standardization would improve productivity. I can never be completely monoglot, but Scala could reach 80% or so. It could replace languages such as Java, C#, Groovy, Ruby, Python. But probably not C. You could say Scala alone is already polyglot. You could create multiple flavors (subsets) of Scala for specific problems.

> there's essential complexity to any given problem

True, but for what problem Scala could not be the right solution?

Martin Odersky

Posts: 84
Nickname: modersky
Registered: Sep, 2003

Re: Groovy Creator James Strachan on Scala Posted: Jul 9, 2009 1:01 AM
Reply to this message Reply
> > James,
> >
> > The more one studies Scala, the more nits one may find.
>
> There are many things about Scala that I would change but
> I think people are getting the idea that I am hostile
> towards Scala (which is not the case) so I'm holding back.
> In the past my pleas that certain features be
> e reconsidered have been summarily dismissed so I'm slowly
> coming to the conclusion that Scala just isn't for me.

I am not sure about the past. But TupleNN could certainly be auto-generated or otherwise better hidden, I agree with that.

Cheers

-- Martin

James Strachan

Posts: 1
Nickname: jstrachan
Registered: Jul, 2009

Re: Groovy Creator James Strachan on Scala Posted: Jul 9, 2009 3:24 AM
Reply to this message Reply
> Scala has its place, but a *replacement* for Java? I don't
> know...
>
> Aside from platform neutrality, the primary reasons Java
> became mainstream were familiarity and simplicity. Java's
> imperative OO foundation provided the necessary welcome
> mat to attract the leagues of existing C++ and VB
> programmers. It was relatively painless for most
> programmers to switch to Java.
>
> In contrast Scala is a *functional* OO language. If the
> past 30+ years have anything to say about programming
> languages, it's that the vast majority of programmers
> prefer imperative ones over functional ones. Functional
> langauges had many opportunities to win us over, but they
> never did. They remain the sideshow. Why is that?
>
> I can't speak for anyone else, but I think more in terms
> of the imperative OO model. I appreciate functional
> languages, but the best language for me is one in which I
> can easily express my mental model of the world. I don't
> think I'm alone.

Agreed. But Scala is a better OO language than Java. So why couldn't you express your OO mental model in Scala better than Java?


> In my college days I recall students
> having significant difficulty grasping functional
> concepts. For instance, everyone had a rougher time with
> LISP than with Pascal (this was in the 80s). I don't
> recall anyone *choosing* LISP for projects. I don't think
> LISP is a bad language; it's relatively powerful and
> expressive. It's just not as natural to us as Pascal or
> Java.
>
> The reason we switched to Java in the late 90s wasn't
> because it was like C++. We switched to take advantage of
> what Java had to offer above and beyond C++: plaform
> independence, it ran in browsers, servlets, garbage
> collection, etc. Big major huge features that we could not
> get from C++. Why would we switch to Scala? Why would a
> bottom line oriented business switch?
>
> Eventually, I'd like to see Java evolve in the direction
> of C#. Feature-wise C# passed Java years ago. It's not
> perfect, but C# to me has the right balance: imperative OO
> with closures where they make sense. If Java gets there,
> fine. If not, well, some other language just might replace
> Java, but Scala? Nah.

Here's where you seem to be contradicting yourself. C# and VB have lots of functional features (closures, lambdas, list comprehensions)...

http://stackoverflow.com/questions/130898/introduction-to-c-list-comprehensions
http://msdn.microsoft.com/en-us/magazine/cc163362.aspx

i.e. to get Java closer to C#/VB it needs functional language features.

Despite these being functional language features folks who see them are happy to use them. They might not say outright "hey I love functional programming", they might still think of themselves as OO developers, but the functional concepts (pattern matching, closures, first class functions, for/list comprehensions, immutable state) are easy to grasp and typically popular features when introduced to languages - not only in VB, C# but also python/ruby/groovy too (not all of them have all these features but they have most of them).

Maybe the difference with Scala is it very clearly states its trying to unify all the functional language concepts cleanly into an OO language (rather than just tacking on features like closures into an OO language). But the effect is the same; most modern languages (excluding Java) have an increasing amount of functional language features. As Scala proves; you can marry a clean statically typed OO language with full functional language features quite elegantly.

Fred Garvin

Posts: 52
Nickname: fredgarvin
Registered: Jan, 2008

Re: Groovy Creator James Strachan on Scala Posted: Jul 9, 2009 10:41 AM
Reply to this message Reply
You're more or less making my point for me, which is that Scala's main fault is that it *is* a functional OO language. Programs written in Scala tend to be implemented *functionally* within objects; closures are used liberally. And my claim is that most programmers don't think that way; it's harder to grasp. I believe the failure of functional languages to gain a wider user base is a testament to that.

Like Java, C# is an imperative (or procedural) OO language. Programs written in C# tend to be implemented procedurally within objects. Closures in C# are used judiciously e.g., collection processing. As a result C# programs are easier to digest.

You can argue for the power that function programmer provides and you'd be right; function programming can be quite powerful. But at what cost? The density of code is usually how we measure a language's power. Ultimately, power in terms of programming languages is less a function of density and more a function of readability, discoverability, and maintainability.

Imho, used judiciously, closures can be a wonderful tool, but they are less useful as the foundation of a programming language.

Trond Olsen

Posts: 14
Nickname: tolsen
Registered: Mar, 2007

Re: Groovy Creator James Strachan on Scala Posted: Jul 9, 2009 1:10 PM
Reply to this message Reply
Hehe, I almost suspect trolling but if there's one language that has established the power of closures it's Javascript.

Kay Schluehr

Posts: 302
Nickname: schluehk
Registered: Jan, 2005

Re: Groovy Creator James Strachan on Scala Posted: Jul 9, 2009 2:52 PM
Reply to this message Reply
> Hehe, I almost suspect trolling but if there's one
> language that has established the power of closures it's
> Javascript.

No, no. It's true and only trolling in the way of Erik Meijer ( the guy behind LINQ ) who once marketed VB.NET as the first mainstream functional programming language.

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: Groovy Creator James Strachan on Scala Posted: Jul 10, 2009 9:47 AM
Reply to this message Reply
> > James,
> >
> > The more one studies Scala, the more nits one may find.
>
> There are many things about Scala that I would change but
> I think people are getting the idea that I am hostile
> towards Scala (which is not the case) so I'm holding back.
> In the past my pleas that certain features be
> e reconsidered have been summarily dismissed so I'm slowly
> coming to the conclusion that Scala just isn't for me.

If I could change one thing about Scala, it wouldn't be the language. It would be to stop claims that Scala is somehow simple. It's not. It's complexity is reasonably well managed and consistently purposeful, but that doesn't change the fact that it is incredibly complex. The idea that someone can become a proficient Scala developer without acknowledging and embracing that complexity is ludicrous.

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: Groovy Creator James Strachan on Scala Posted: Jul 10, 2009 11:35 AM
Reply to this message Reply
> > > James,
> > >
> > > The more one studies Scala, the more nits one may
> find.
> >
> > There are many things about Scala that I would change
> but
> > I think people are getting the idea that I am hostile
> > towards Scala (which is not the case) so I'm holding
> back.
> > In the past my pleas that certain features be
> > e reconsidered have been summarily dismissed so I'm
> slowly
> > coming to the conclusion that Scala just isn't for me.
>
> If I could change one thing about Scala, it wouldn't be
> the language. It would be to stop claims that Scala is
> somehow simple. It's not. It's complexity is reasonably
> well managed and consistently purposeful, but that doesn't
> change the fact that it is incredibly complex. The idea
> that someone can become a proficient Scala developer
> without acknowledging and embracing that complexity is
> ludicrous.
>
I've never heard anyone claim that "Scala is somehow simple," but I have heard several people claiming that Scala is "incredibly complex." For example, you just said that. I think both claims that "Scala is simple" and "Scala is complex" are misleading. Those claims, both of them, are too simplistic.

What I've been trying to get across is that Scala is complex like your car is complex. Car these days are indeed very complex, but does that mean no one but PhDs will be ever able to figure out how to drive cars? Are cars doomed to be a niche idea because they are so complex? Of course not. The trend I have seen is that as the mechanisms that make up a car have become more sophisticated, and yes more complicated, over the decades, the user experience has become easier. You don't need to understand everything about how a car works to drive it and get benefit out of it. And part of the reason is that these days, because of the complexity of starters, when you turn the key, the car starts. Easier for you. Because of the complexity of anti-lock brakes, when you slam on the brakes, you don't skid. Easier for you. Because of some extra complexity in the door locks, in most cars these days if you try to lock the car with the keys in the ignition, it automatically unlocks. Easier for you to avoid accidentally locking your keys in your car. And so on.

Certainly in any of these mechanisms, Scala or cars, sometimes the complexity bubbles up into your face. But it happens when you're actually programming in Scala about as often as it happens in modern cars, which is to say relatively rarely. It happens more often in library design than library usage, but even in library design the occasional puzzles aren't that difficult to solve. What's really hard about Scala given its sophistication, is writing a Scala compiler, just like what's hard about cars these days is actually building one.

And that's why saying Scala is simple is also a misleading statement. Writing client code in Scala is usually pretty simple, but I would not say that without the "usually pretty" in there. Because sometimes things will bubble up. But it isn't hardly what I'd call complicated either. It is generally quite straightforward.

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: Groovy Creator James Strachan on Scala Posted: Jul 10, 2009 12:46 PM
Reply to this message Reply
> I've never heard anyone claim that "Scala is somehow
> simple,"
It's somewhat subject to interpretation. I think that James Strachan's post gave the impression.

> but I have heard several people claiming that
> Scala is "incredibly complex." For example, you just said
> that. I think both claims that "Scala is simple" and
> "Scala is complex" are misleading. Those claims, both of
> them, are too simplistic.

True. It's hard to properly qualify it.

> What I've been trying to get across is that Scala is
> complex like your car is complex. Car these days are
> indeed very complex, but does that mean no one but PhDs
> will be ever able to figure out how to drive cars? Are
> cars doomed to be a niche idea because they are so
> complex? Of course not.

Did I say anything about Scala being doomed?

> The trend I have seen is that as
> the mechanisms that make up a car have become more
> sophisticated, and yes more complicated, over the decades,
> the user experience has become easier.

Easier is subjective. To continue with your car analogy, there are some people who find driving a manual transmission easier than an automatic, because it gives them more control, and thus enables them to do things that they couldn't do with an automatic transmission.

> You don't need to
> understand everything about how a car works to drive it
> and get benefit out of it.

Yes, but occasionally not understanding certain parts will bite you very hard.

> Certainly in any of these mechanisms, Scala or cars,
> sometimes the complexity bubbles up into your face.

Exactly.

> But it
> happens when you're actually programming in Scala about as
> often as it happens in modern cars, which is to say
> relatively rarely.

Cars, yes, Scala, not so much...

> It happens more often in library design
> than library usage, but even in library design the
> occasional puzzles aren't that difficult to solve.

The perceived complexity of the puzzles is usually proportionate to how far you push the language, and how much experience you have pushing it in that particular direction.

I think we're disagreeing on two points:
1. The extent to which complexity in libraries bleeds into application code
2. The dichotomy between library and application developers

In many circumstances #1 is the library developer's fault, not Scala's. In my experience, most of the accidental complexity in these cases has to do with type inference failing, especially when this failure causes an implicit to not be triggered. This is a pretty easy situation to create, especially in there implicits on commonly used types.

#2 is probably where most of our real disagreement is. With Java, much of the really advanced stuff is accomplished through means that are very cumbersome, like reflection, or extrinsic to the Java language, like runtime bytecode manipulation. Not many people are going to dive into those waters and play sorcerer's apprentice.

But Scala is different. Scala provides a lot of powerful features directly within the language. There is no great barrier to scale in order to use them. Thus people will, and quite rightly I might add. It doesn't make much sense to me to pitch a language based on its powerful expressivity, and then in the next breath tell the masses that these features are only the province of library developers. Especially when it's so easy to make those libraries fall by failing to import something, importing too much, or defining something yourself that leads to ambiguous implicits.

I also think application developers should always keep the idea that they are writing a library in mind. That doesn't mean they should always try to make library-like code, it just means they should always be on the lookout for patterns that could be abstracted away. Also, if someone else if calling into your code, then your code is essentially a library to them.

> What's
> really hard about Scala given its sophistication, is
> writing a Scala compiler, just like what's hard about cars
> these days is actually building one.

No one will argue with you there.

> And that's why saying Scala is simple is also a misleading
> statement.

Agreed.

> Writing client code in Scala is usually pretty
> simple, but I would not say that without the "usually
> pretty" in there. Because sometimes things will bubble up.
> But it isn't hardly what I'd call complicated either. It
> is generally quite straightforward.

I think that the bubbling up occurs frequently enough that a good Scala developer needs to know the more advanced features of Scala. Either that or start memorizing patterns to avoid the pitfalls without actually understanding what causes the pitfalls. While I'm sure I do this myself occasionally, I this approach makes significant contributions to the sorry state of software engineering. And, as I said before, I don't think people should be chased away from language features.

It's worth pointing out that I don't consider may statements about Scala's complexity to be a criticism of Scala. Scala merges two very different paradigms (OO and Functional) while maintaining an astounding degree of backwards compatibility with Java. This is no small feat. But the power Scala gives you isn't free, and I don't think the price can be paid entirely by library designers. Even if it could, I think it would be a terrible shame for application developers to use such a powerful tool in such a rudimentary way.

I suppose I should say that I think there is very little accidental complexity in Scala. It's almost all there for good reasons to accomplish goals that justify the complexity.

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: Groovy Creator James Strachan on Scala Posted: Jul 10, 2009 2:24 PM
Reply to this message Reply
Hi Erik,

All very reasonable. I'll insert a few comments below:

> > I've never heard anyone claim that "Scala is somehow
> > simple,"
> It's somewhat subject to interpretation. I think that
> James Strachan's post gave the impression.
>
> > but I have heard several people claiming that
> > Scala is "incredibly complex." For example, you just
> said
> > that. I think both claims that "Scala is simple" and
> > "Scala is complex" are misleading. Those claims, both
> of
> > them, are too simplistic.
>
> True. It's hard to properly qualify it.
>
> > What I've been trying to get across is that Scala is
> > complex like your car is complex. Car these days are
> > indeed very complex, but does that mean no one but PhDs
> > will be ever able to figure out how to drive cars? Are
> > cars doomed to be a niche idea because they are so
> > complex? Of course not.
>
> Did I say anything about Scala being doomed?
>
No, sorry. I didn't mean to imply you said that. Several other people have said things like they think Scala is too complicated or esoteric for "mainstream" developers.

> > The trend I have seen is that as
> > the mechanisms that make up a car have become more
> > sophisticated, and yes more complicated, over the
> decades,
> > the user experience has become easier.
>
> Easier is subjective. To continue with your car analogy,
> there are some people who find driving a manual
> transmission easier than an automatic, because it gives
> them more control, and thus enables them to do things that
> they couldn't do with an automatic transmission.
>
True.

> > You don't need to
> > understand everything about how a car works to drive it
> > and get benefit out of it.
>
> Yes, but occasionally not understanding certain parts will
> bite you very hard.
>
> > Certainly in any of these mechanisms, Scala or cars,
> > sometimes the complexity bubbles up into your face.
>
> Exactly.
>
> > But it
> > happens when you're actually programming in Scala about
> as
> > often as it happens in modern cars, which is to say
> > relatively rarely.
>
> Cars, yes, Scala, not so much...
>
This is also subjective. Nowadays I can make Scala do whatever I want. I can imagine some DSL-like syntax and know first if it can be done in Scala, and also immediately how to do implement it. But at one point I was a beginner and somehow I made it through. I remember not knowing how to do the simplest things in Scala, and it taking a while to figure out. That was before there were good books to learn from and look things up in. But even then my main experience did not feel like I was fighting complexity so much as simply fighting unfamiliarity.

> > It happens more often in library design
> > than library usage, but even in library design the
> > occasional puzzles aren't that difficult to solve.
>
> The perceived complexity of the puzzles is usually
> proportionate to how far you push the language, and how
> much experience you have pushing it in that particular
> direction.
>
> I think we're disagreeing on two points:
> 1. The extent to which complexity in libraries bleeds into
> application code
> 2. The dichotomy between library and application
> developers
>
> In many circumstances #1 is the library developer's fault,
> not Scala's. In my experience, most of the accidental
> complexity in these cases has to do with type inference
> failing, especially when this failure causes an implicit
> to not be triggered. This is a pretty easy situation to
> create, especially in there implicits on commonly used
> types.
>
Can you think of some specific examples? This doesn't ring a bell. My main complaint about libraries I've seen is that they just aren't designed tastefully. They may overuse operators, according to my subjective design sense, for example.

> #2 is probably where most of our real disagreement is.
> With Java, much of the really advanced stuff is
> s accomplished through means that are very cumbersome,
> like reflection, or extrinsic to the Java language, like
> runtime bytecode manipulation. Not many people are going
> to dive into those waters and play sorcerer's apprentice.
>
> But Scala is different. Scala provides a lot of powerful
> features directly within the language. There is no great
> barrier to scale in order to use them. Thus people will,
> and quite rightly I might add. It doesn't make much sense
> to me to pitch a language based on its powerful
> expressivity, and then in the next breath tell the masses
> that these features are only the province of library
> developers. Especially when it's so easy to make those
> libraries fall by failing to import something, importing
> too much, or defining something yourself that leads to
> ambiguous implicits.
>
> I also think application developers should always keep the
> idea that they are writing a library in mind. That
> doesn't mean they should always try to make library-like
> code, it just means they should always be on the lookout
> for patterns that could be abstracted away. Also, if
> someone else if calling into your code, then your code is
> essentially a library to them.
>
Well I wouldn't tell people "these features are only the in the province of library designers." I do suggest people be very conservative about operators and implicit conversions, but that's in general. It goes for library design too.

What I have tried to explain is that in my experience, it was only during library design that I've felt I was fighting what I'd call complexity, and even then not that often. When using libraries I've had compiler errors, but they didn't seem complicated to figure out. Mostly I have mistyped a method name or have an overload problem or what not. But twice in designing ScalaTest I had to think hard about a problem.

One occasion was when I needed to figure out what the variance of Matcher's type parameter should be. That required me to go jogging up a hill and visualize an inheritance hierarchy, and think about how it would be used. I decided on that jog that Matcher seemed to be contravariant in its type parameter. When I got back to my laptop I put in a minus sign to declare the type parameter contravariant. I did a compile. It worked, and neither I nor any ScalaTest user has had to worry about it since. That's what I mean by users of the library don't need to face the complexity that was faced and solved by the library designer.

The other head scratcher was getting this syntax to look like I wanted:


Map("one" -> 1, "two" -> 2) should (not contain value (5) and not contain value (3))


This syntax gave me a complicated problem to figure out. The trouble was that for the line to compile, the expression on the right (not contain value (5) and not contain value (3)) needed to have an inferred type of Map[String, Int]. But if you look, you'll see there's no way the compiler can figure out the key type of String, because there's no information about that in (not contain value (5) and not contain value (3)). All that's talked about there is the value type, Int. So the Scala compiler infers Map[Nothing, Int].

Nothing is a bottom type, which is a subtype of every other type, but because Map's key type parameter is nonvariant, that means Map[Nothing, Int] is not a subtype of Map[String, Int]. Which in turn meant I got a compiler error. This one really was a head scratcher for me, but at one point I said to myself, self, all I know about the key type in the right hand expression is that it has some type, but I just don't know what the type is yet. That sounded to me like an existential type. That's what an existential type says, so I decided to try and put one in there, and voila, it all worked. (And I haven't had to think about it since, and neither have my users.)

Both of these two examples are what I'd call fighting complexity, but in all of the work I've done on ScalaTest, these were really the only two puzzles like this. And users of ScalaTest probably have no idea what the variance of Matcher is, or that there's an existential type hidden in there in one place to get the Scala compiler to delay inference until it has enough information to do it. They just type in the syntax and it works.

> > What's
> > really hard about Scala given its sophistication, is
> > writing a Scala compiler, just like what's hard about
> cars
> > these days is actually building one.
>
> No one will argue with you there.
>
> > And that's why saying Scala is simple is also a
> misleading
> > statement.
>
> Agreed.
>
> > Writing client code in Scala is usually pretty
> > simple, but I would not say that without the "usually
> > pretty" in there. Because sometimes things will bubble
> up.
> > But it isn't hardly what I'd call complicated either.
> It
> > is generally quite straightforward.
>
> I think that the bubbling up occurs frequently enough that
> a good Scala developer needs to know the more advanced
> features of Scala. Either that or start memorizing
> patterns to avoid the pitfalls without actually
> understanding what causes the pitfalls. While I'm sure I
> do this myself occasionally, I this approach makes
> significant contributions to the sorry state of software
> engineering. And, as I said before, I don't think people
> should be chased away from language features.
>
> It's worth pointing out that I don't consider may
> statements about Scala's complexity to be a criticism of
> Scala. Scala merges two very different paradigms (OO and
> Functional) while maintaining an astounding degree of
> backwards compatibility with Java. This is no small feat.
> But the power Scala gives you isn't free, and I don't
> t think the price can be paid entirely by library
> designers. Even if it could, I think it would be a
> terrible shame for application developers to use such a
> powerful tool in such a rudimentary way.
>
> I suppose I should say that I think there is very little
> accidental complexity in Scala. It's almost all there for
> good reasons to accomplish goals that justify the
> complexity.
>
I agree that there's not much accidental complexity in Scala. The complexity I see comes mostly from a few areas. One is that there's some extra complexity in Scala due to its goal of being compatible with Java. There are a number things you could toss out if you were to toss out that design goal, and that would make the language simpler. But for me the Java compatibility is very much worth the extra complexity it adds.

Another bit of complexity comes from the union of OO and functional. A more exclusively OO language, or a more exclusively functional language, would probably be simpler. But the union in Scala is pretty elegant and consistent, and frankly I prefer the choices it gives me as a programmer. Even though the language may be a bit more complex, I think having more choices at my fingertips makes my life as a programmer simpler. I've seen this over and over again when designing ScalaTest.

But of course the 800 pound complexity gorilla would have to be the type system, which if it dropped some of its features would be simpler. But with every feature dropped, something would become harder and more complex when using Scala as a tradeoff for a simpler language to learn. There's a good reason for each piece of the type system, and while it represents an impressive bundle of stuff you have to learn to be a highly proficient Scala programmer, it is learnable. And once you learn it, it really makes your programming life simpler.

What I'm not sure about is what the newbie experience really is. My newbie experience was skewed because I got to talk to Martin Odersky and Lex Spoon on the phone each week for two years as we wrote the book, and I could get good answers to my questions. We worked really hard to make the book carefully lead the reader one step at a time. So that each new concept built on the old ones. And reader comments seem to indicate that has worked OK. So I think with good educational materials it is an approachable language by the mainstream, but there will almost certainly be times as people are learning that the compiler forces them to face something they don't quite understand yet. But I think most people will be able to figure it out, and then they'll learn a lesson about Scala that will make it quicker for them to figure out next time. I think to really get good at Scala, people will have to write code in it and face down a few of those obscure-for-them compiler errors along the way.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Groovy Creator James Strachan on Scala Posted: Jul 13, 2009 7:17 AM
Reply to this message Reply
> What I've been trying to get across is that Scala is
> complex like your car is complex. Car these days are
> indeed very complex, but does that mean no one but PhDs
> will be ever able to figure out how to drive cars? Are
> cars doomed to be a niche idea because they are so
> complex? Of course not. The trend I have seen is that as
> the mechanisms that make up a car have become more
> sophisticated, and yes more complicated, over the decades,
> the user experience has become easier. You don't need to
> understand everything about how a car works to drive it
> and get benefit out of it. And part of the reason is that
> these days, because of the complexity of starters, when
> you turn the key, the car starts. Easier for you. Because
> of the complexity of anti-lock brakes, when you slam on
> the brakes, you don't skid. Easier for you. Because of
> some extra complexity in the door locks, in most cars
> these days if you try to lock the car with the keys in the
> ignition, it automatically unlocks. Easier for you to
> avoid accidentally locking your keys in your car. And so
> on.

The car analogy is a valid (if a bit weak) analogy for programming language complexity but I really don't think it applies to Scala. A language like works like a modern car would require no understanding of the complexity underlying the language and that's not the case with Scala. You just can't use Scala effectively without understanding all the features.

If I have to think of a better fit for this analogy, I would pick something like VB. It will get you were you need to go and you can get there even if you don't really understand programming or computers very well but if you get into trouble you are going to need some help.

Scala is a language that is well suited for professional, expert developers. It's not a language for casual developers or people who are mostly concerned with solving a business or domain problem. Of course, neither is Java. DSLs seem to me to be the right approach for that but without standardization of these DSLs within different fields, I doubt that we'll see much there either. The DSL approach would be the most like the modern car. The controls are focused on the desired results and the complexity of how that gets done is hidden from the user.

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: Groovy Creator James Strachan on Scala Posted: Jul 13, 2009 10:54 PM
Reply to this message Reply
> The car analogy is a valid (if a bit weak) analogy for
> programming language complexity but I really don't think
> it applies to Scala. A language like works like a modern
> car would require no understanding of the complexity
> underlying the language and that's not the case with
> Scala. You just can't use Scala effectively without
> understanding all the features.
>
I guess it depends on what you mean by "use Scala effectively." If it means designing libraries and frameworks, then yes, to do a good job at that you need to understand most of the language. But you don't need to understand all of it. I think ScalaTest 0.9.5 was a pretty decent library. I released that 4 or 5 months ago, and only last week learned that I didn't need the curly braces around multiple statements in a function literal in Scala if the whole literal itself is inside curly braces. That's why the ScalaTest 0.9.5 documentation shows things like:


withFixture {
(builder, lbuf) => {
builder.append("easy!")
assert(builder.toString === "ScalaTest is easy!")
assert(lbuf.isEmpty)
lbuf += "sweet"
}
}


In 0.9.6 I've changed that documentation to:


withFixture { (builder, lbuf) =>

builder.append("easy!")
assert(builder.toString === "ScalaTest is easy!")
assert(lbuf.isEmpty)
lbuf += "sweet"
}


With the inner pair of curly braces gone. So I didn't understand all the features of the language until at least last week, and there's a chance that little corners lurk that I'm not yet aware of. But I find I'm still highly effective at Scala.

I'm hoping that people can get up to speed quickly in Scala by writing client code. They can start by writing scripts, tests, etc. And that's I think a fairly quick way to get going. I started by just writing scripts in Scala for a while. You don't need to understand variance of type parameters, for example, to get started doing that kind of thing (and be effective at it).

> If I have to think of a better fit for this analogy, I
> would pick something like VB. It will get you were you
> need to go and you can get there even if you don't really
> understand programming or computers very well but if you
> get into trouble you are going to need some help.
>
> Scala is a language that is well suited for professional,
> expert developers. It's not a language for casual
> developers or people who are mostly concerned with solving
> a business or domain problem. Of course, neither is Java.
> DSLs seem to me to be the right approach for that but
> t without standardization of these DSLs within different
> fields, I doubt that we'll see much there either. The DSL
> approach would be the most like the modern car. The
> controls are focused on the desired results and the
> complexity of how that gets done is hidden from the user.
>
I agree Scala is a language better suited for professional developers than casual ones, which is perhaps where the car analogy breaks down. The main point I was trying to make with the car analogy is that complex machines don't necessarily make your life more complex. They can make your life simpler. For example, Cedric Beust said this in his comment on James Strachan's blog last week:

In many ways, I have this impression that Scala is to Java what C++ is to C: very feature rich and using the excuse that "you don't have to use all the bells and whistles", while in practice, these bells and whistles contribute greatly to code complexity.

But when actually programming in Scala I've found that the opposite is true. Sure, type inference is a complex mechanism in the Scala language, but it makes my code much simpler. Not more complex. The way the compiler figures out whether a variance annotation should be allowed is extremely complex, but again, it makes my life and my code much simpler. The fact that Scala has both generic type parameters and abstract type members adds complexity compared to just having one or the other, but they each have strengths the other doesn't have. So when you need one, if you only had the other, your code would be more complex. So here again, the language is more complex (because it has two features instead of one), but my code can be simpler. That's the main point I'm trying to make with the car analogy. The complexity of the various mechanisms that make up today's cars are indeed complex, but by and large that complexity makes our lives simpler when we use cars.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Groovy Creator James Strachan on Scala Posted: Jul 14, 2009 6:57 AM
Reply to this message Reply
> I guess it depends on what you mean by "use Scala
> effectively."[snip]

I'll attempt to clarify.

> With the inner pair of curly braces gone. So I didn't
> understand all the features of the language until at least
> last week, and there's a chance that little corners lurk
> that I'm not yet aware of. But I find I'm still highly
> effective at Scala.

You don't need to know the entire language in and out to be effective but you need to understand the features you are using. Not how they are implemented but what they do. Going back to your car analogy, I don't need to know how an automatic transmission works to drive effectively, but I need to know what putting the car in drive, reverse, neutral and park all mean.

> I'm hoping that people can get up to speed quickly in
> Scala by writing client code. They can start by writing
> scripts, tests, etc. And that's I think a fairly quick way
> to get going. I started by just writing scripts in Scala
> for a while. You don't need to understand variance of type
> parameters, for example, to get started doing that kind of
> thing (and be effective at it).

That's a way to get started but it's not effective programming. If you don't know what those crazy variance declarations mean and use a cargo-cult approach to coding, there is a huge amount of danger. It's like when a small child attempts to mimic what their parents do when operating an automobile.

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: Groovy Creator James Strachan on Scala Posted: Jul 14, 2009 10:31 AM
Reply to this message Reply
> You don't need to know the entire language in and out to
> be effective but you need to understand the features you
> are using. Not how they are implemented but what they do.
> Going back to your car analogy, I don't need to know how
> w an automatic transmission works to drive effectively,
> but I need to know what putting the car in drive, reverse,
> neutral and park all mean.
>
Agreed.

> > I'm hoping that people can get up to speed quickly in
> > Scala by writing client code. They can start by writing
> > scripts, tests, etc. And that's I think a fairly quick
> way
> > to get going. I started by just writing scripts in
> Scala
> > for a while. You don't need to understand variance of
> type
> > parameters, for example, to get started doing that kind
> of
> > thing (and be effective at it).
>
> That's a way to get started but it's not effective
> programming. If you don't know what those crazy variance
> declarations mean and use a cargo-cult approach to coding,
> there is a huge amount of danger. It's like when a small
> child attempts to mimic what their parents do when
> operating an automobile.
>
Well again I think it depends on what you mean by "effective." I would define that just to mean you can get the job done. If that's the definition, then I think you could get by knowing just about nothing about Scala's type parameter variance for quite a while writing scripts and tests, i.e., client code. The most recent Scala script I wrote is this:


import scala.io.Source

val scrubbedList = Source.fromFile("scrubbedJuly.txt").getLines.toList
val currentList = Source.fromFile("mem.txt").getLines.toList

val scrubbedMembers = scrubbedList.map(_.trim)
val currentMembers = currentList.map(_.trim)

for (member <- scrubbedMembers)
if (!currentMembers.contains(member))
println(member)


I had two lists of email addresses and I wanted to make sure that all the addresses in the scrubbed list were definitely in the current list. I'm using Scala's List type in this script, and Lists have a type parameter for the element type contained in the List. That type parameter has a variance annotation of +, which means it is covariant. But I think someone could write a script like this, understanding exactly what each line of code is doing, without having any idea what covariance even means.

In Java, because of its use-site variance (wildcards), the story is different. There you'll end up needing to learn what this "? extends" and "? super" syntax means a lot earlier in the learning process. And in fact, that may be where people encounter the complexities of variance first in Scala. Because when Scala calls into Java libraries that use wildcards, you will sometimes need to supply an existential type that maps to the Java wildcard type. I found those mappings confusing at first, in part because I wasn't simply very familiar Java wildcards at that point. (I had never used them in our web app. Always wanted to generify it, but hadn't done that yet.)

So with the exception of Scala existential types that show up sometimes in client code when calling Java code that has wildcard types, I really don't think people will need face down the complexities of variance until they are doing library design. If they design a *new* collection class in Scala, for example, then they will need to understand and Scala's declaration-site variance to be most effective. But I'd add that if you get the variance wrong in a library design, your program won't compile. So the complexity of that variance checking mechanism in the Scala compiler makes the library designer's life simpler.

The one way I think variance will occasionally show up in the client programmer's face is if they try to pass say a Set[Apple] to a method that takes a Set[Fruit]. Because Set is nonvariant in its element type, this won't compile, and the'll get a type error. Here's an example:


scala> abstract class Fruit
defined class Fruit

scala> case class Apple extends Fruit
defined class Apple

scala> def printFruits(set: Set[Fruit]) { println(set) }
printFruits: (Set[Fruit])Unit


The printFruits method takes a Set[Fruit]. If someone tries to pass a Set[Apple] to it, they'll get a compiler error:


scala> val set = Set(new Apple)
set: scala.collection.immutable.Set[Apple] = Set(Apple())

scala> printFruits(set)
<console>:10: error: type mismatch;
found : scala.collection.immutable.Set[Apple]
required: Set[Fruit]
printFruits(set)
^


This is a variance problem, but note the compiler doesn't talk about variance. It just says you gave it a Set[Apple] when it needed a Set[Fruit]. Now this programmer may puzzle over why the compiler won't let them pass a Set[Apple] to a method that expects a Set[Fruit]. This may cause them to track down and learn something about Scala's declaration site variance. But it may not. They may instead just try something like this:


scala> val apple: Fruit = new Apple
apple: Fruit = Apple()

scala> val set = Set(apple)
set: scala.collection.immutable.Set[Fruit] = Set(Apple())

scala> printFruits(set)
Set(Apple())


The compiler wanted a Set[Fruit]. So don't ask questions. Just give it one. And move on. The programmer may decide to try this route, especially if they are under deadline pressure. The result is not dangerous code. It works fine, even if the programmer didn't fully understand all the intricacies of variance that caused the compiler error in the first place.

One other scenario, though, is that the library designer can "get it wrong" by making a type parameter nonvariant when it is really covariant or contravariant by nature. There is also no danger to client code if you do this. The only downside is some expressions that clients would want to compile won't until the library designer "improves" the variance. An example is the variance of the Matcher type in Specs. For maybe a year that was nonvariant, which meant that certain expressions involving and and or would not compile. After I figured out the variance of ScalaTest matchers, I noticed Specs matchers were nonvariant, which was puzzling. So I tried a few expressions and sure enough they wouldn't compile. I checked out the Specs code and made it contravariant and that allowed those expressions to compile. So I submitted a patch, and that showed up in the next Specs release. Now more expressions compile with Specs matchers. But the users of Specs got a lot of benefit out of it even while the variance was more restrictive, and there was never any "danger."

I think variance is probably an inherent complexity if you decide you're going to have static typing including generic types in a language with subtyping. And it is complex. But I can't imagine how a language could make it simpler for the users than Scala does. Client programmers really don't need to worry about it much. And library designers get a great deal of help from the compiler.

Flat View: This topic has 69 replies on 5 pages [ « | 1  2  3  4  5 | » ]
Topic: Fit or Future? Which is More Important When Hiring? Previous Topic   Next Topic Topic: ScalaTest 1.6.1 for Scala 2.9.0 released

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use