> > > > What is difficult is that by using some predefined function, one can
> > > > express very much in very small code. I believe Haskell is even more
> > > > expressive than most OO languages with comparable libraries
> > > > (perhaps except Smalltalk, as that has also a very compact syntax).
> >
> > > I havn't made my mind if that is positive of negative. Sometimes it
> > > remind me of Perl and I'm not a big lover from it.
> >
> > Somehow that's not really fair towards Haskell. Perl is made up
> > of many special cases, and in some other places, you have to use
> > major hackery to achieve some goal (mind the "OO" part of Perl,
> > for just one example).
>
> Now Haskell is on the other hand not quite fair to me. It makes me look
> as if I never have seen or programmed. I'm not thinking I'm the king of
> hacking, but I'm quite able to write some pieces of code. If using
> Haskell I have the feeling to ran against a wall, if I have s.th whih is
> trivial in e.g Python I have to fight to find a solution in Haskell.
> Maybe that's unfairf but it's quite different from all the things I
> know.
I wouldn't call it "unfair". After all, no one forced you to learn Python,
and no one is forcing you to learn Haskell. (OK, maybe your professor or
someone is... :) But that is really beside the point. There are good reasons
(necessities, really) why Haskell does things like I/O differently from,
say, Python, and the contract you have entered into with the Haskell
designers is that, in the end, it will pay off if you use them. If you feel
that that contract has not been fulfilled, or will never been fulfilled,
then you should stop using Haskell.
My feeling, though, is that even if you never use Haskell "in anger," your
Weltanschauung as a programmer will be enriched by having experience with
Haskell's way of doing things. I think this is in particular the case with
Haskell's monads, because after you have mastered them to some degree you
know what an imperative language "is really doing" under the semantic hood.
> > I think exercise with the purely functional, non-I/O core (and perhaps
> > interact like someone else suggested) teaches you the mode of
> > thinking in purely functional languages. That thinking can also
> > help you understand the way I/O is implemented in a referentially
> > transparent way.
>
> I disagree, small scripts spend most of the time doing I/O if I don't
> understand how to do that I'm not able to even write the most simple
> things. This is eg. true for my cat ...
While I/O is certainly important for real-world programming, that does not
necessarily mean it is the best place to start learning a programming
language. There are exercises other than cat that better illustrate the
significant characteristics of Haskell and functional programming in
general, at least if you are coming from the imperative programming camp.
> > > sorry this looks morre terrible to me than all solutions before, IMO
way
> > > to much parameters and the names don't give me a good hint of what e.g
> > > beforeMap does.
> >
> > That's a HOF
> What's a HOF?
Higher-order function. A function that takes a function as an argument. A
first-order function is one that doesn't take any functions; a second-order
function is one that takes a first-order function, and so on...
> > that first splits something up to a list using splitFn
> > (or with the generalization I mentioned, to a monad), then maps a
> > function over that list (namely beforeMap, because it's mapped
> > *before* the filter), filters something out (using the filterPredicate),
> > then again maps a function (namely afterMap, because it's mapped
> > *after* the filter), then somehow joins the list (or monad), using
> > unSplitFn.
>
> I would like names which tell me what is done.
>
> I read in contents of a file
> I process it, I build a string ...
First, since many Haskell functions are (parametrically) polymorphic, they
are necessarily more abstract than what you may be used to, and it can be
difficult to give them an immediately recognizable name.
Second, functions like map, filter, fold, etc. may be unfamiliar to you, but
they are part of a well known paradigm variously called the Boom hierarchy,
the Bird & Wadler list combinators, and calculational programming (these
names are not really equivalent). This paradigm has a lot of internal
structure, and once you see the Big Picture, you will see how nicely and
prominently map and fold and so on fit into it, and why the choice of names
are relatively unimportant. (The reason is that these functions are actually
canonical in significant way, and consequently they are used very often.
BTW, these names are fairly widely accepted, except that map is sometimes
called map-car, and fold is sometimes called reduce.)
The same situation exists in mathematics. It may not mean much to you if
someone describes a string as a monoid, but it has a wealth of meaning to a
mathematician. Names like map and fold are idiomatic in the same way to a
functional programmer.
Third, it is actually quite common in Haskell (in my experience at least) to
use very non-descriptive names for local variables if the definition is
short. I think it helps readability because the program fragment is shorter
as a result, and it is easier to see the relationship between all the
elements. For example, compare:
map :: (a -> b) -> [a] -> [b]
map f [] = []
map f (x:xs) = (f x) : map f xs
transformListElems :: (elem -> elem') -> List elem -> List elem'
transformListElems transform Nil = Nil
transformListElems transform (Cons elem elemRest) =
Cons (transform elem) (transformListElems transform elemRest)
Of course, for more involved definitions, it is better to use descriptive
names.
--FC
