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 6: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 | » ]
Bill Venners

Posts: 2251
Nickname: bv
Registered: Jan, 2002

Re: Groovy Creator James Strachan on Scala Posted: Jul 16, 2009 7:34 PM
Reply to this message Reply
Advertisement
Hi James,

> I don't even see why I have to make this argument. How
> would you feel if airplane mechanics worked this way? I
> wouldn't want to fly anywhere if the appearance of
> possibly being correct was all that was required on a
> given repair. We expect competence in most skilled
> trades. Why shouldn't we expect it from developers? How
> this ties back to Scala is that Bill (Venners) made the
> following [paraphrased] argument: 'yes Scala is complex,
> but that's OK because you can write code in it without
> understanding it.' I just don't buy that argument.
>
I'd paraphrase myself differently. I'd change "understand it" to "understand it at the level of depth that Martin Odersky understands it." Let's try putting it that way.

I keep giving you examples of how people can write something in Scala and not understand completely how it works at the level someone who has several years of experience with Scala might understand it, but understand sufficiently what the code means at some higher level of abstraction. And for those specific cases you I think have agreed with me. (Or maybe I just gave one case, the -> in Map literals one.)

Oddly enough I can give you an example that happened to me within the last hour. I have been reviewing the O'Reilly Scala book, and just finished reviewing the chapter on the type system. In that chapter the authors (Dean Wampler and Alex Payne) said that the this reference is really a shorthand for the path dependent type T.this, where T is the type your in. So in class Bob, this is really Bob.this, which is a path-dependent type in Scala. Well I have felt I had a pretty good understanding of path dependent types for quite some time, I was aware of things like Bob.this and understood what it means, and I have certainly felt I understood this. This in Scala seems to work just like this did in Java. But until an hour ago, I had never thought of this as being a path dependent type, Bob.this. I just hadn't yet put all those clues together. It is a new way of understanding this that adds to my depth of understanding of Scala.

So up until an hour ago, I've been using this with reckless abandon in my Scala code without understanding fully what it means at the level of depth that Martin Odersky (and Dean Wampler, who I think penned this chapter) has understood it. And it has been fine. There has been no danger. Because I understood perfectly well what this means at a slightly higher level of abstraction.

That's what I'm talking about. My experience with Scala is that you don't need to understand all the ins and outs to use it effectively, just like you don't need to understand with complete detail how your engine works to drive your car effectively.

Raoul Duke

Posts: 127
Nickname: raoulduke
Registered: Apr, 2006

Re: Groovy Creator James Strachan on Scala Posted: Jul 16, 2009 7:37 PM
Reply to this message Reply
could the GScript people hurry up and release it to the public? :-)

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Groovy Creator James Strachan on Scala Posted: Jul 16, 2009 8:16 PM
Reply to this message Reply
> So up until an hour ago, I've been using this with
> reckless abandon in my Scala code without understanding
> fully what it means at the level of depth that Martin
> Odersky (and Dean Wampler, who I think penned this
> chapter) has understood it. And it has been fine. There
> has been no danger. Because I understood perfectly well
> what this means at a slightly higher level of
> abstraction.

The question I have is whether the artificial abstraction would hold up under the ways you used it. If so, then it's a good enough abstraction. If there are instances where your way of thinking of it would not be correct, then you are just lucky that it never caught you. The reasoning you are using is no different than that of the person who says "I never wear a seat-belt and I'm still alive therefore I don't nee one."

The other thing I can point out is that you didn't know that what you were doing was safe until you understood more fully. Ignorance is bliss, as they say. This is all anecdotal, it doesn't demonstrate that ignorance of the details of Scala can't burn you.

> That's what I'm talking about. My experience with Scala is
> that you don't need to understand all the ins and outs to
> use it effectively,

So far.

> just like you don't need to understand
> with complete detail how your engine works to drive your
> car effectively.

Again, you need to understand the controls of the car to drive effectively. There's a big difference between understanding the language and the way it's compiled to bytecodes.

Bill Venners

Posts: 2251
Nickname: bv
Registered: Jan, 2002

Re: Groovy Creator James Strachan on Scala Posted: Jul 16, 2009 8:33 PM
Reply to this message Reply
> The question I have is whether the artificial abstraction
> would hold up under the ways you used it. If so, then
> it's a good enough abstraction. If there are instances
> where your way of thinking of it would not be correct,
> then you are just lucky that it never caught you. The
> reasoning you are using is no different than that of the
> person who says "I never wear a seat-belt and I'm still
> alive therefore I don't nee one."
>
My guess is that such problems will happen from time to time in any language. I can say that the teams who have used Scala that I have spoken with have not complained about this problem you are concerned about. These may be self-selecting teams, so it doesn't mean the potential for trouble doesn't exist. And I haven't talked to very many, but I have talked to a few. They all have complaints, but this is not come up except from people who haven't used Scala much as far as I can tell.

I do know of one or two examples where Scala code has compiled and people thought it would do one thing but it did something different. These are rare corner cases, puzzlers if you prefer that term. And Scala has puzzlers just like Java and other languages. But implicit conversions in general, which you seem to be afraid of, aren't a big puzzler. They usually seem to make code clearer.

The one example that pops to mind was caused by Scala's semicolon inference mechanism. It inferred a semicolon where the programmer didn't intend it, but with a semicolon in there, it actually still compiled, but of course meant something different. This programmer figured it out through testing the app, and learned something about semicolon inference through the experience. I would not be surprise if every Scala programmer hits a few semicolon inference problems as they are learning, but you quickly learn what you need to do to avoid those problems.

> The other thing I can point out is that you didn't know
> that what you were doing was safe until you understood
> more fully. Ignorance is bliss, as they say. This is all
> anecdotal, it doesn't demonstrate that ignorance of the
> details of Scala can't burn you.
>
> > That's what I'm talking about. My experience with Scala
> is
> > that you don't need to understand all the ins and outs
> to
> > use it effectively,
>
> So far.
>
> > just like you don't need to understand
> > with complete detail how your engine works to drive
> your
> > car effectively.
>
> Again, you need to understand the controls of the car to
> drive effectively. There's a big difference between
> understanding the language and the way it's compiled to
> bytecodes.
>
Well I think we're going in circles. Naturally I agree with you that you need to understand the controls of the car to drive effectively, but I'd add: "at a certain appropriate level of abstraction." I don't need to know exactly at great detail what happens when I push the brakes. I don't need to understand how anti-lock brakes work, for example. It is perfectly fine if i just understand that the harder I push the brakes, the quicker it tries to stop, and that I can slam on the brakes and it will somehow magically protect me from skidding and losing control. What it sounds to me that you are basically saying about Scala is that we need to be very afraid of drivers who don't understand the ins and outs of anti-lock brakes, because when they push on the brake, they aren't really understanding how brakes work. Scala really is like that. You don't need to fully understand all the detailed ins and outs of variance, to pick one thing, to do a whole bunch of useful stuff in Scala.

Bill Venners

Posts: 2251
Nickname: bv
Registered: Jan, 2002

Re: Groovy Creator James Strachan on Scala Posted: Jul 16, 2009 8:46 PM
Reply to this message Reply
Hi James,

> The question I have is whether the artificial abstraction
> would hold up under the ways you used it. If so, then
> it's a good enough abstraction. If there are instances
> where your way of thinking of it would not be correct,
> then you are just lucky that it never caught you. The
> reasoning you are using is no different than that of the
> person who says "I never wear a seat-belt and I'm still
> alive therefore I don't nee one."
>
> The other thing I can point out is that you didn't know
> that what you were doing was safe until you understood
> more fully. Ignorance is bliss, as they say. This is all
> anecdotal, it doesn't demonstrate that ignorance of the
> details of Scala can't burn you.
>
Actually in further thinking I realized I got the wrong impression from the O'Reilly book. C.this isn't a path dependent type, because it is a value not a type. I reread the section and he doesn't actually call it a path-dependent type, so the book wasn't wrong either, but it was misleading me because it was in a section on path-dependent types. So I actually didn't really learn anything new about this today.

But in general you are right. If you don't fully understand something you won't know how good your more abstract mental model really is. There's a book called "The Design of Everyday Things" by Donald Norman that talks about mental models and how people can make mistakes by adopting an inaccurate mental model. I had that in mind when writing writing and editing the Programming in Scala book, to try and never mislead readers into forming a simpler abstraction that wasn't really an accurate abstraction. That little footnote in chapter 3's intro of the Map literal syntax pointing to implicit conversions was part of that. It being a footnote means they don't really need to worry about it now, but I also didn't want them to imagine the -> syntax was achieved by some other mechanism that was not accurate.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Groovy Creator James Strachan on Scala Posted: Jul 16, 2009 9:50 PM
Reply to this message Reply
> What it sounds to me that you are basically
> saying about Scala is that we need to be very afraid of
> drivers who don't understand the ins and outs of anti-lock
> brakes, because when they push on the brake, they aren't
> really understanding how brakes work. Scala really is like
> that. You don't need to fully understand all the detailed
> ins and outs of variance, to pick one thing, to do a whole
> bunch of useful stuff in Scala.

I wrote this in a response above but I'll explain it again. I'm not saying this about Scala. I'm saying it about programming in general.

It's very difficult to know that you know everything there is to know. There will always be a risk that there is something you don't know. So, I would disagree with your statement that I am afraid of the drivers who don't understand how anti-lock brakes work. I'm afraid of the drivers who don't know exactly what the pedals on the floor are for but they know that driving requires pushing them.

This car example is so simplistic it comes off as being ridiculous. Let's change it to a plane. I have a vague idea about how to fly a plane. Pull back to nose up, push forward to nose down, etc. There's a throttle, an altimeter and some other dials and controls that may or may not be crucial to flying. I've played with a triplane simulator. You would probably be a pretty scared if you found me flying a 747 that you were a passenger on and quite rightly. The thing is that I see many professional developers that know as much about the programming tools they are using as I do about flying a plane. You are going to have a hard time convincing me that this is OK.

In most highly skilled fields, there is some point where someone who is known to know a lot about the given field determines whether someone who's knowledge level is generally unknown has enough knowledge. Lawyers pass the bar, engineers are licensed and/or certified. I'm not saying that has to change or will anytime soon but I think that it's disingenuous to pretend that there's no risk in not knowing where you stand with regard to your skill level with a given tool.

Bill Venners

Posts: 2251
Nickname: bv
Registered: Jan, 2002

Re: Groovy Creator James Strachan on Scala Posted: Jul 16, 2009 10:27 PM
Reply to this message Reply
Hi James,

> It's very difficult to know that you know everything there
> is to know. There will always be a risk that there is
> something you don't know. So, I would disagree with your
> statement that I am afraid of the drivers who don't
> understand how anti-lock brakes work. I'm afraid of the
> drivers who don't know exactly what the pedals on the
> floor are for but they know that driving requires pushing
> them.
>
Well I think we've been talking about two different things then. No wonder we keep arguing!

> This car example is so simplistic it comes off as being
> ridiculous. Let's change it to a plane. I have a vague
> idea about how to fly a plane. Pull back to nose up, push
> forward to nose down, etc. There's a throttle, an
> altimeter and some other dials and controls that may or
> may not be crucial to flying. I've played with a triplane
> simulator. You would probably be a pretty scared if you
> found me flying a 747 that you were a passenger on and
> quite rightly. The thing is that I see many professional
> developers that know as much about the programming tools
> they are using as I do about flying a plane. You are
> going to have a hard time convincing me that this is OK.
>
That's a better analogy. And yes I'd be very nervous flying in a 747 with a pilot that doesn't understand how to fly that plane. But I was certainly never trying to say that people who don't know how to program, who aren't competent programmers, can program in Scala because they don't need to understand Scala to program in Scala. All I was trying to say is that competent programmers can indeed program in Scala and do so effectively even if they don't know all the ins and outs of the type system, implicits, and other advanced aspects of it. This allows people to become productive relatively quickly, and become more efficient and capable over time as they learn more and more about the language. But also that I think there is plenty of room for people who never get as good at the language as the top Scala language gurus, just as is true for Java and other languages. Those people are on that same learning path, but they may just not go all the way to the guru level. These are competent programmers I'm talking about still, just programmers who don't care to become completely deeply immersed in all things Scala, and maybe wouldn't really even be capable of it if they tried.

> In most highly skilled fields, there is some point where
> someone who is known to know a lot about the given field
> determines whether someone who's knowledge level is
> generally unknown has enough knowledge. Lawyers pass the
> bar, engineers are licensed and/or certified. I'm not
> saying that has to change or will anytime soon but I think
> that it's disingenuous to pretend that there's no risk in
> not knowing where you stand with regard to your skill
> level with a given tool.
>
OK. Fair enough. I have tried to think of how programmers could be certified. It is very difficult. Certifications exist, like Sun has certifications for Java. But being certified in that way means you have passed a test that demonstrates your knowledge of a technology in the answering questions sense, I think. Which is a long way from proving you to be a good, competent programmer.

Martin Odersky

Posts: 84
Nickname: modersky
Registered: Sep, 2003

Re: Groovy Creator James Strachan on Scala Posted: Jul 17, 2009 6:20 AM
Reply to this message Reply
> As a side note, I'd love to be proven wrong on Scala. If
> it's shown to be well suited for team development and all
> my hand-wringing is for naught, that's great.

Have a look at the recent interview with Alex McGuire how EDF uses Scala, then. I think that qualifies exactly as the example you look for: A team (I think they were 7 as of last February) that works on highly domain-specific software (energy contract modeling) in Scala.

http://www.scala-lang.org/node/2202

Cheers

-- Martin

Bill Pyne

Posts: 165
Nickname: billpyne
Registered: Jan, 2007

Re: Groovy Creator James Strachan on Scala Posted: Jul 17, 2009 8:58 AM
Reply to this message Reply
IEEE Computer Society has several certifications. I don't know if this is closer to what you're thinking of.

http://www2.computer.org/portal/web/getcertified

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Groovy Creator James Strachan on Scala Posted: Jul 17, 2009 9:30 AM
Reply to this message Reply
> IEEE Computer Society has several certifications. I don't
> know if this is closer to what you're thinking of.
>
> http://www2.computer.org/portal/web/getcertified

I think the real problem is that certifications are given little weight. Of course some IT shops want you to be certified in Oracle or whatever but these (in my experience) show almost nothing about the skill level of developers. For a while I was interviewing a lot of Java developers and it amazed me how every single Sun Certified Java Developer that came through was totally unqualified for a junior to mid-level developer role.

I'll look into that. I'm curious to see how they evaluate developers.

Bill Pyne

Posts: 165
Nickname: billpyne
Registered: Jan, 2007

Re: Groovy Creator James Strachan on Scala Posted: Jul 17, 2009 9:54 AM
Reply to this message Reply
> I think the real problem is that certifications are given
> little weight.

Not to drag this thread away from its topic, but you're totally on with the certification problem. One developer I read about, possibly in an IEEE periodical, decided to become a certified software engineer. (I believe he is a consultant in upper state New York.) After 2 years, he gave up the certification for several reasons.

1) Having the certification gave him no advantage in finding work.
2) No additional pay was given him over non-certified developers.
3) Keeping his certification was a continuous process that cut into his billable hours and time spent finding new clients.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Groovy Creator James Strachan on Scala Posted: Jul 17, 2009 12:30 PM
Reply to this message Reply
> OK. Fair enough. I have tried to think of how programmers
> could be certified. It is very difficult. Certifications
> exist, like Sun has certifications for Java. But being
> certified in that way means you have passed a test that
> demonstrates your knowledge of a technology in the
> answering questions sense, I think. Which is a long way
> from proving you to be a good, competent programmer.

I agree. However, this kind of thing is done for engineers, architects and a lot of other fields that are also complex. Please don't think I believe this guarantees absolute competence. It's more about try to measure the minimum competence level. And, of course, if the certification process is not done well, then it's not going to solve anything.

Raoul Duke

Posts: 127
Nickname: raoulduke
Registered: Apr, 2006

Re: Groovy Creator James Strachan on Scala Posted: Jul 17, 2009 5:28 PM
Reply to this message Reply
> All I
> was trying to say is that competent programmers can indeed
> program in Scala and do so effectively even if they don't
> know all the ins and outs of the type system, implicits,
> and other advanced aspects of it.

http://tinyurl.com/kn8b74

i think Scala has overly tweaky syntax which can more easily trip people up that i'd like.

Raoul Duke

Posts: 127
Nickname: raoulduke
Registered: Apr, 2006

Re: Groovy Creator James Strachan on Scala Posted: Jul 17, 2009 5:28 PM
Reply to this message Reply
^that^than

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Groovy Creator James Strachan on Scala Posted: Jul 17, 2009 8:16 PM
Reply to this message Reply
> > As a side note, I'd love to be proven wrong on Scala.
> If
> > it's shown to be well suited for team development and
> all
> > my hand-wringing is for naught, that's great.
>
> Have a look at the recent interview with Alex McGuire how
> EDF uses Scala, then. I think that qualifies exactly as
> the example you look for: A team (I think they were 7 as
> of last February) that works on highly domain-specific
> software (energy contract modeling) in Scala.
>
> http://www.scala-lang.org/node/2202
>
> Cheers
>
> -- Martin

I had read that and it's a start for sure. 7 people is a small-medium sized team. What I really worry about is what happens in iteration 2,3,4,5,...15. The first version is always a breeze. The trick is developing something that is maintainable in the long run. This is where the vast majority of software projects fail to deliver.

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-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us