interested
Justin Kaeser
a bit, since it seems quite different from what I am used to (OOP
mostly)
What would be a good language to start with and can you point me to a
tutorial?
Thanks!
Stefan Axelsson
> What would be a good language to start with and can you point me to a
> tutorial?
Well, I don't have any tutorial as such handy for starting to think in
functional terms (there are language tutorials available), other
followupers can hopefully help there.
Instead I'd recommend two books.
The first is "The structure and interpretation of computer programs",
by Abelson and Sussman (sp? on both). The language used (I hesitate to
say taught) is Scheme, which is made worthwhile by this book IMHO. But
language aside the book itself really starts you thinking in
functional terms which is good.
The other I have experience with is "Haskell the craft of
functional programming", by Simon Thompson, that is quite nice and a
bit easier going that the book above. Haskell is more in the
mainstream of current functional programming research than Scheme is
(I'm not trying to start a functional language flamewar here).
There are quite a few other books available, but these are the
introductory ones I've worked through myself, and feel worth
recommending off the top of my head.
Otherwise, the Haskell and O'Caml homepages have tutorials and whatnot
(as I assume most languages have), but depending on how firmly ones
mind is set in other ways of going about the problem that may not be
enough to achieve insight into the functional mindset. It takes many
people some time to wrap their head around it.
Stefan,
--
Stefan Axelsson (email at http://www.cs.chalmers.se/~sax)
Feuer
Stefan Axelsson wrote:
>
> The other I have experience with is "Haskell the craft of
> functional programming", by Simon Thompson, that is quite nice and a
> bit easier going that the book above. Haskell is more in the
> mainstream of current functional programming research than Scheme is
> (I'm not trying to start a functional language flamewar here).
Not to start a flamewar, but while Haskell may be more the mainstream
of programming language research, Scheme is certainly more the
mainstream in programming language application.
> Otherwise, the Haskell and O'Caml homepages have tutorials and
The trouble with Haskell and especially ML for beginners is that
those languages' type systems have some rather murky corners.
David
Friedrich Dominicus
>
> The other I have experience with is "Haskell the craft of
> functional programming", by Simon Thompson, that is quite nice and a
> bit easier going that the book above. Haskell is more in the
> mainstream of current functional programming research than Scheme is
> (I'm not trying to start a functional language flamewar here).
If you are happy with an online-book you should look after
ocaml-ora.pdf.
Regards
Friedrich
Stefan Axelsson
> I feel Hudaks book "The haskell School of Expression" is nicer.
I've heard nice things about it, but I have no first hand experience
with it, that's why I didn't mention it.
> If you are happy with an online-book you should look after
> ocaml-ora.pdf.
Yes. It's a bit of an earful IMHO, but everything's there. It's not
at the same level as "Structure and interpretation..." IMHO.
YMMV as always.
Joachim Durchholz
>
> The trouble with Haskell and especially ML for beginners is that
> those languages' type systems have some rather murky corners.
Where?
More importantly: are these corners likely to bite a beginner? (More
likely than, say, the murky corners of Scheme?)
Regards,
Jo
Joachim Durchholz
> In article <873cbce...@fbigm.here>, Friedrich Dominicus wrote:
>
>>I feel Hudaks book "The haskell School of Expression" is nicer.
>
> I've heard nice things about it, but I have no first hand experience
> with it, that's why I didn't mention it.
Hudak is quite nice, particularly as an entry-level text.
I found it a bit lacking about actual application of higher-order
functions. It says almost nothing about combinator libraries, how to go
about abstraction in larger programs (which, I think, is linked with
combinator libraries), practical fun with the various monads.
In other words: it's like an introductory text for Pascal that says
little about structuring larger Pascal programs, or about available
standard libraries. But as an introduction, it's very good.
(I can't compare with other introductory FPL texts, just with texts that
introduce into other kinds of languages.)
Regards,
Jo
Ahn Ki-yung
ML like impure language suffer from problem of strange ad hoc
polymorphism because of that impure references. Applications
cannot be polymorphic at all!
Pure languages such as Haskell are free from this problem
but when beginners encounter top level monomorhpism with complex
type class constraints, it may horrify them.
Friedrich Dominicus
> Stefan Axelsson wrote:
>
>> In article <873cbce...@fbigm.here>, Friedrich Dominicus wrote:
>>
>>> I feel Hudaks book "The haskell School of Expression" is nicer.
>> I've heard nice things about it, but I have no first hand experience
>> with it, that's why I didn't mention it.
>
> Hudak is quite nice, particularly as an entry-level text.
> I found it a bit lacking about actual application of higher-order
> functions.
Then you have not looked past the first pages. He does not talk much
about HOFs (but there's at least chapter 9) he's just using them :)
Regards
Friedrich
Feuer
The murky corners of Scheme tend not to show up unless you use either
macros or call/cc. Haskell has the monomorphism restriction and some
counterintuitive (but necessary) limitations on instance declarations.
ML has the value restriction. I have not done nearly enough with ML
to have a clue where the value restriction pops up. In Haskell,
I've had far more opportunities to run into unexpected brick walls.
Also, I cannot claim to have nearly good enough understanding of the
type system to feel entirely happy programming in it. (not that I
think the programs will be wrong, but that I am writing in a language
I do not understand).
David,
who will probably one day take a class on type systems.
Joachim Durchholz
> Then you have not looked past the first pages. He does not talk much
> about HOFs (but there's at least chapter 9) he's just using them :)
Agreed - the rest of the message was mostly to detail in what ways he
didn't talk about HOFs. The concept as such is introduced with little
ado (and actually it doesn't warrant much ado, it's more horrifying to
language implementers than to programmers I think) (well, implementers
have more problems with closures than with HOFs in themselves *g*).
Oh, and there's also another thing that Hudak misses out: explaining the
advantages of the functional style. He does a good job at explaining
what equational reasoning is, but there is very little explanation why
this is advantageous (well, maybe it's difficult to explain this in less
than a hundred pages).
Regards,
Jo
Stefan Axelsson
> ML has the value restriction. I have not done nearly enough with ML
> to have a clue where the value restriction pops up.
Well, I remember learning SML as a rank beginner in '87 from Wikströms
book, and I don't remember me or any of my class mates being confused
by the value restriction. (We were plenty confused at times, but that
wasn't one of the problems). Now the course didn't even (much) cover
the imperative side (or the module system, which was a shame IMHO), so
I'd say there's plenty of functional programming to be learned before
jumping in the deep end.
I imagine that we're talking about different kinds of 'beginners'
though. More or less programming novices like above, or well versed
programmers that haven't had much exposure to functional
programming. They'd require a different approach for sure.
Andreas Rossberg
>
> Well, I remember learning SML as a rank beginner in '87 from Wikströms
> book, and I don't remember me or any of my class mates being confused
> by the value restriction.
1987? There was no value restriction in 87. Well, there wasn't even a proper
Standard ML. :-)
The value restriction may be confusing at times, but primarily with
compilers that don't produce decent messages, IMHO.
BTW, Haskell's monomorphism restriction is nothing but a weakened form of
ML's value restriction. Since it is even more ad-hoc it is even more
confusing.
Cheers,
- Andreas
Marcin 'Qrczak' Kowalczyk
> BTW, Haskell's monomorphism restriction is nothing but a weakened form of
> ML's value restriction.
It has a different purpose. Without the SML's restriction its type system
would be unsound, allowing to "cast" any type to any other.
Without the Haskell's restriction some programs might just unexpectedly
evaluate some expressions multiple times, and the restriction can be
circumvented by an explicit type signature (and Clean just distinguishes
the syntax of binding a value computed once from binding it by name).
--
__("< Marcin Kowalczyk
\__/ qrc...@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Feuer
> Without the Haskell's restriction some programs might just unexpectedly
> evaluate some expressions multiple times, and the restriction can be
> circumvented by an explicit type signature
The type signature thing in Haskell is a mess, especially
with GHC extensions. The fact that monomorphic types exist and
there is no way to declare them is not a good sign.
David
who would like to see what Haskell would look like without
classes, with a good module system, with more carefully
designed I/O, and with a really superb system for concurrent
programming.
Marcin 'Qrczak' Kowalczyk
> The type signature thing in Haskell is a mess, especially
> with GHC extensions. The fact that monomorphic types exist and
> there is no way to declare them is not a good sign.
At the toplevel you can always declare them. Locally they might refer to
type variables introduced outside, so you can't always declare them in
Haskell 98, but you can in GHC.
> David
> who would like to see what Haskell would look like without
> classes, with a good module system, with more carefully
> designed I/O, and with a really superb system for concurrent
> programming.
Classes are a great Haskell's strength. I miss them in virtually all
statically typed languages which don't have them (of course I mean
Haskell-like classes, not OO ones).
OCaml with Haskell-like classes might be a nice language.
Stefan Axelsson
> 1987? There was no value restriction in 87.
Well that would explain it then. :-) What I probably meant to say was
that there were plenty of things to confuse us before our knowledge
was advanced enough to be confused at that relatively higher level.
> Well, there wasn't even a proper Standard ML. :-)
There wasn't even a proper compiler for (non standard) ML as far as I
recall. :-) "Looking for an int i have found an int" is not a helpful
error message to a rank beginner. The O'Caml book/manual at least
explains why you might get such an error message.
Mark Carroll
I'd probably start with something like SML, Scheme or Haskell. Each
could teach you a lot, and each can be used to write useful programs.
The user communities are probably friendly and helpful, too.
If you just want to play a bit with the simpler ideas for a bit with
an easy start, I'd also think about checking out what state Logo is in
these days - it might be fun if you have kids and if the language
didn't die altogether while I wasn't looking.
-- Mark
Aaron Denney
> David
> who would like to see what Haskell would look like without
> classes, with a good module system, with more carefully
> designed I/O, and with a really superb system for concurrent
> programming.
Hmm. I find type classes to be an elegant syntactic sugar for 90%
of what I would need something like ML's module system for, but I
agree that that last 10% could be better served.
Could you expand on what you see as the flaws in the IO and concurrency
libraries? I'm rather fond of the CSP abstraction myself.
--
Aaron Denney
-><-