It occurs to me that Haskell would be quite a bit
easier for OO and traditional programmers to grasp if Haskell would actually use
the correct, or at least more commonly used, names for things.
For instance,
data Maybe a = Nothing | Just
a
Maybe is a type
constructor and Nothing and Just are data constructors.
So it makes me wonder why the use of the data keyword... wouldn't it make
more sense to say:
type Maybe a = Nothing | Just
a
? Either that or perhaps change the
descriptions "type constructor" and "data constructor" to something that fits
with the keywords used.
Likewise with class, type class, and instance:
class Eq a where
(==) :: a
-> a -> Bool
That actually declares a type class, not a
class. So why the use of the keyword class? Is it done merely to
confuse C++ and Java programmers? The concept of type class in Haskell
apparently roughly corresponds to the concept of "interface" in Java. So
why not call it interface?
Instance is also
confusing:
instance Eq Integer where
a == b = a `integerEq` b
a == b = a `integerEq` b
That actually declares that Integer is a type, not
an "instance" in the traditional use of the word. A C++ programmer would
probably use the word "subclass" instead of "instance".
Then consider how different a meaning "return" has
in Haskell than it does in C. ;)
Does anyone else think this is a problem? If
so, is it fixable?
I guess from reading the many tutorials and FAQ's,
that I'm in the same boat as everybody else. I consider myself a pretty
bright boy, I've learned all kinds of other programming languages, from asm to
forth to basic, pascal, C, C++, java, and C#... but this Haskell business,
has me almost stumped. I mean, I understand the basic ideas pretty easily
enough, but there seems to be such syntactical wierdness that to understand how
to program in Haskell above the level of toy programs requires one to revisit
every single design decision that went into making the language and its
libraries, and grasp everything along the way, not only its function but also
its peculiar nomenclature, and usually two different ways to say the same thing
(maybe more). Only after following this long tortuous path will one ever
be able to actually write useful programs.
If Haskell (or any language of this style) is ever
to gain a larger following, it would probably be wise to accomodate the existing
programmer knowledge base a little more. I believe that the same core
language, with cleaner design, different keywords, maybe different operators,
would probably be readily accepted.
There are many things that contribute to making
Haskell less approachable, the above is just one.
I wonder if there are any tutorials out there that
provide a 1:1 mapping of concepts and idioms from other common languages into
Haskell; small snippets of examples of pure translations would make things
easier to grasp for some people than any amount of longwinded explanation.
Probably there are easier ways to do the same things in Haskell, but it would be
useful for beginners to get a unedited translation, even if that means
heavy use of do-notation. At least people could then start writing
imperative style Haskell programs immediately, and yeah that's not good style,
but you can't learn good style if you can't accomplish anything and are stuck at
square one.
Frustratedly,
Sean
_______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
