On Dec 17, 3:14 am, Reinier Zwitserloot <[email protected]> wrote:
> I don't think it's up to me to -prove- scala's problems here, as
> proving it would take a few man-weeks- of work. Call it personal
No, but it would be enlightening to the rest of us to see a sample bit
of code and the error message that you think are incomprehensible.
My personal experience with Scala over the last 1 1/2 years or so is
that I've never gotten a syntax error that I couldn't figure out in a
matter of seconds. I have gotten type related errors that have left
me scratching my head, but that's only when I've done advanced type
level hacking. But the same thing happens to me in Haskell.
> Note that haskell, for example, SPECIFICALLY chose to have absolutely
> ZERO inferred casting,
Haskell has defaulting for the Num type class. Not exactly the same
thing, but certainly a source of magic. The first time I saw an error
message related to that I was lost.
> so where's the paper to prove haskell is
> wrong?
The problem isn't that Haskell is "wrong." But it certainly isn't
perfect. For instance, Haskell's module system barely deserves the
name. It's a namespace mechanism and not much else. SML programmers
will tell you what modules are good for. In particular, a complaint
I have with Haskell is that type classes are a pretty global affair.
Scala's approach with implicits is to try to unify type classes and
modules. I'm not saying it's perfect, but it is at least an effort to
explore the space. And for the here and now I find them incredibly
useful. What's great is that I can use the implicit mechanism as is,
or I can specify the function as an explicit argument when needed.
> Such a compiler would need a hefty amount of A.I. and would need to
> have the ability to provide a cascade of error interpretations, where
That's true in Haskell as well. Global type inference often leads to
error messages pointing to code far away from the real source. You
could easily imagine a compiler that, upon finding a type mismatch
could walk through all the possible fix up spots and determine the
most likely fix(es) based on some heuristic. That's just not the way
it is right now.
Now, since this is a Java related group let me add one real world Java
error message that left me scratching my head for quite awhile. I
understood what it was saying, but it took me forever to figure out
why it was a problem.
"A generic array of Pair<Integer,String> is created for a varargs
parameter "
I do understand it now, and I'm convinced that Java is putting the
warning in the wrong place. But be that as it may, it's a complicated
interaction between generics, varargs, and Java's covariant arrays.
The equivalent code just isn't a problem in Scala because Scala's
arrays aren't covariant so this particular complex corner case doesn't
exist.
People who think Java is simple are suffering from "boiled frog
syndrom" - like frogs who've been sitting in a pot that was very
slowly heated up, they don't realize how hot things have gotten.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
