|
|
Re: Groovy Creator James Strachan on Scala
|
Posted: Jul 16, 2009 5:33 PM
|
|
> 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.
|
|
Previous Topic
