On Jul 11 2002, 6:41 pm, Jerzy Karczmarczuk <karc...@[EMAIL PROTECTED]
>
wrote:
>
> * Here and elsewhere both H and C communities are helpful, people who
> know, answer all questions without pretensions nor suggestions that
they
> are respectful gurus bothered by beginners (which happens too often on
> other "language-oriented" newgroups I visited recently...).
This used to be the case in the H community when I joined several
years ago, but recently I asked for the bibliography for a doctoral
dissertation that mentioned the Hindley-Milner type inference
algorithm to the author in e-mail, but instead of giving me the
bibliography, he just told me to go read a thick book on type theory.
A few days later, I accidentally came across the number of the chapter
mentioning the algorithm, but had I not come across it accidentally, I
may have had to read the entire book.
What bothered me even more was that the professor in charge of his
dissertation was the same professor who had taught me a course in
formal semantics at the same college, but though I mentioned this fact
in the message, he did not refer to this part at all, and instead
concluded by stating that after reading the book, I would "most likely
find [his] thesis easier to read :)." His attitude came across as
rather condescending, particularly since he was from the same school,
and under the same professor as well.
In another instance on the mailing list haskell, I started a thread on
startup options for ghci, and one of the members there later asked me
to stop cc'ing him in my messages.
Further, on the HaskellWiki, there is a page on "Homework
help" (http://haskell.org/haskellwiki/Homework_help)
that reads as
follows:
> Your lecturer/instructor may have told you that there is no such thing
as a stupid question. Inside your
> classroom, that is correct. Outside your classroom, there are smart
questions and stupid questions. If you ask a
> smart question of the Haskell community, you will probably get a helpful
answer. If you ask a stupid question,
> you will probably get an unhelpful answer or, more likely, no answer at
all.
This page is occasionally mentioned on haskell-cafe in reference to
responses to homework questions. I disagree with this opinion. In my
opinion, there is no such thing as a stupid question, period, inside
or outside the classroom. I think that it is usually fairly easy to
distinguish a homework-related question from a non-homework-related
one, and that the proper response to such a question is not to say,
"That's a stupid question," but to say ask in detail specifically
where the student has gotten stuck, and to respond in such a manner as
to guide the student out of the stuck portion and on to solving the
problem on his/her own. In my opinion, calling a question "stupid"
may potentially risk giving that student a negative impression of the
community as a whole, and may cause the student to stop studying the
language altogether.
It seems as if, as Haskell has grown more popular as a language, at
least certain members of the Haskell have become less interested in
teaching the language to beginners....
Benjamin L. Russell
On Jul 11 2002, 6:41 pm, Jerzy Karczmarczuk <karc...@[EMAIL PROTECTED]
>
wrote:
> Terra reiterates:
>
>
>
> > [omissis]
> > > > From the description on the web site, Clean seems to be close to
> > > > Haskell. What are the key differences?
> > > [Gonzi's comments]
> > But this is NOT the answer to the question: what are the key
differences
> > between Haskell and Clean?
>
> ==========
>
> I believe that we will have to CONSIDER SERIOUSLY putting this
information
> in this newgroups FAQs. Graham?
>
> My three cents, rather disordered. I invite other people here to say
> something as well, perhaps one day we will cook-up a comprehensive
FAQ...
> And please, if I wrote some rubbish below, correct it...
>
> 0. They *ARE* very similar, both being lazy, pure functional languages,
> and the possible application domains are strongly overlapping. I
> strongly suggest to everybody who wants to specialize in the FP
> that he/she learn both.
>
> 1. There is a visible difference in general philosophy.
> - Haskell started as an exploration language, undergoes frequent
(even if
> small) modifications, its "maintenance" is distributed, there are
at
> least 3 (OK, 4 if you wish) major implementations, and the
documentation
> (even if driven by one super-mind) is the result of a community
consensus.
> - Clean - in its actual instance - was thought as an
industrial-strength
> programming platform, stable, and changing only in the case of
necessity.
> (I mean - when the authors feel really unhappy about the status
quo, and
> they have nothing else to do, which is rather rare...)
>
> There is a cross-breeeding between them, but on quite different
levels.
> While the authors of Clean profit from time to time from Haskell
formal
> constructions (notably the superficial appearance of the class
system),
> some Haskell-oriented people have been fascinated by the powerful and
> coherent Clean interfacing library.
> Haskell produces/inspires from time to time some offsprings (and -
with my
> full sincere respect - some bastards): generic Haskell, Polyp,
Cayenne,
> etc., some really wonderful headache generators, strongly recommended
> for all free and ambitious minds. Clean is more application-oriented,
> and has a good reputation for being really fast.
>
> We could have read here and elsewhere some critical voices: that it
> would be better to concentrate the human effort on one language,
instead
> of producing two << faux jumeaux >>, if you know what I mean...
> I disagree violently with this, and I think that the co-existence,
and
> the competition between them is good, inspiring, and offering better
> support for those who think already on new languages.
>
> 2. Thus, there are some design differences. Haskell had since the
beginning
> the arbitrary-precision Integers, and numeric computations were for
too
> long considered as something of less importance. This resulted in
> somewhat unsatisfactory status of numerically-oriented parts of the
> standard library, but it is improving. Clean in these contexts is
more
> brutal, and seems to optimize better some programs which in Haskell
> need some attention of the user (such as avoiding to use Integers,
where
> Ints suffice; Clean has only "standard" Ints).
> Also - for the current implementations - the manipulation of arrays
is
> more efficient in Clean. (But I haven't done any benchmarking with
the
> last GHC version...)
>
> The type inference is a bit different, and in general the type
systems
> *are* different. Haskell system is easier to learn. The status, the
relation
> between classes and types is a nice, baroque construction.
>
> Clean class system is - apparently - more "plain", the relation
between
> classes and overloaded functions is more straightforward, but if you
look
> at some details, it is substantially more complicated, and sometimes
> disturbing.
> In Haskell a function which takes two arguments and produces a result
of
> type c has the type a -> b -> c. In Clean you may write it as
> a b -> c
> which *will* disturb a Haskeller, since it might be understood as a
one-
> argument function with a being some constructor. Clean shortcuts
produce
> the effect that the types of
> f x y = z x y and
> f x = \y -> z x y
> are different, while in Haskell it is the same. Some missing or
"redundant"
> parentheses in the type specification in Clean are far from being
inocuous,
> *never* try to write the above as (a b) -> c ...
>
> Clean type categoriess are quite rich. Uniqueness, strictness, type
> dependence [a=>b] etc. - all this must be studied for many hours in
order
> to be able to understand some compiler messages and/or to code in the
most
> efficient way..
>
> 3. Some people say "Haskell uses Monads", Clean - uniqueness types for
IO
> and elsewhere.
>
> Uniqueness type for a variable means that that this variable can be
> accessed only in one place within the program. So, if there a new
> object is produced from the transformation of the original, and if
> this object is also "unique", the program can update in place the
> original, yielding the new instance. This cannot be done directly
> in Haskell.
>
> In fact, there are people who use Monads in Clean as well. The
update-
> in-place-; single-thread data processing chains are simply
implemented
> in Clean at a lower level, while IO Monad in Haskell is primitive.
So,
> Clean is more universal, permitting to implement more "imperative"
> things by the user, while Haskell is "cleaner"...
> Clean programs possessing imperative flavour could be quite messy,
but
> Clean disposes of a syntactic contraption, a kind of sequential "let"
> with specific scope rules, permitting to REUSE names:
>
> # (aFile,aFileSystem) = openItInside aFileSystem
> # aFile = WriteToItOrDoSomethingElseWith aFile
> # aFile = continueToProcess aFile
> ...
>
> where you don't need to write aNewFile = process aFile, etc. A file
> is still unique, because of these sequential scoping rules.
>
> Haskell on the other hand has the "do" block, permitting to write
> monadic chains in an imperative style
> do
> var <- doSomething ...
> encore <- doSomethingElseWith var
> printSomewhere encore
> ...
> return (whatYou want et encore)
>
> 4. A general observation about the use of both languages by a beginner
who
> wants to learn on examples:
> Haskell disposes of two decent interactive interpreters: Hugs and
GHCI
> permitting to test directly small expression, to ask about their
types,
> etc. which is often useful for debugging, and for grasping the
essentials
> on small exercises.
> Clean is a compiler which processes the whole program. It has a very
decent
> interactive interface with make/project options, and plenty of
information
> produced on the screen by the compiler, but - as in my case - the
class
> usage is a bit less appropriate. (There are other views as well, I am
> not trying to depreciate Clean).
>
> It must be admitted though that neither is really an *interactive*
language
> like Scheme or Python. In a pure, strongly typed programming
framework the
> compiler performs a lot of global analysis, which makes the
incremental
> programming difficult. (In Clean: impossible; in Hugs: awkward - you
can
> input expressions, but not definitions; in GHCI: possible:
> let foo = someThing
> useThisFoo foo ...
>
> but this is a monadic construction in disguise...
>
> ===================
>
> Now, for the people who asked those questions. Choose whatever you wish,
> if your philosophy is "I have no time to learn two languages, only one,
> so tell me which one is better", then I have some VERY STRONG
statements:
>
> * Whoever says to you "H is *better* that C" (or vice-versa) is LYING.
> * If you want to learn FP, you should have a good view on the principal
> paradigms, not on particular syntactic constructs. Then, some
knowledge
> of two different languages is more than helpful.
> * Learning of languages is a big adventure and pleasure.
> * Here and elsewhere both H and C communities are helpful, people who
> know, answer all questions without pretensions nor suggestions that
they
> are respectful gurus bothered by beginners (which happens too often on
> other "language-oriented" newgroups I visited recently...).
>
> Jerzy Karczmarczuk
> Caen, France
|
