Re: [tlug] recomendations for a functional language

[Attila Kinali <attila@example.com>]

Moin,

On Wed, 4 Nov 2009 15:04:06 +0900
Curt Sampson <cjs@example.com> wrote:

> On 2009-11-03 14:02 +0100 (Tue), Attila Kinali wrote:
> 
> > Hmm.. didn't we had a discussion on STM just a few months ago?
> 
> Yup. That, I believe, was before I'd learned about how STM works in C,
> and so I didn't understand that the cool thing Haskell had was not STM
> itself, but Haskell's type system that makes STM practical.

I guess i have to see myself how Haskells STM looks like.
I hope it's more a concept on how to do things than what
a lot of CS-students/professors claim it to be, namely a
way to do concurent work w/o locking, which it is definitly not.

> > Now, that's interesting. I thought that functional languages hardly
> > support iteration but "force" you to do it recusively?
> 
> Pretty much anything you can express iteratively you can also express
> recursively, and vice versa. So which you think in and which you really
> use underneath depends on your language, compiler and libraries.

That's obvious for anyone who's understood what recursion means :-)

> Common lisp has various looping constructs, and the standard doesn't
> require tail call optimization (though many compilers do provide it),
> so a program that uses tail recursion over large data structures
> or whatever is not guaranteed not to blow up the stack on some CL
> implementations. (Scheme requires tail call optimization.) So that was
> why I reckoned that CL encouraged looping rather than recursion, and why
> I'm a little doubtful about Stephen's correction on that. But he would
> probably know better than me.

Hmm.. that raises a red flag here. From my background, ie number crunching
applications (video coding) and deep embedded systems w/o OS, there is
an absolute need to have a certain degree of control over how much
memory on the heap and on the stack are used. Do functional languages
allow such a control?

 
> > What would you say about first learning Scheme and then going Haskell?
> > Scheme has the very persuasive property of being compact which
> > promises that i get a quick start and do the tedious learning of
> > concepts as i walk along a nice path.
> 
> I'd say don't bother, unless you intend to do some serious research
> into programming with macros. 

I read from this, that Scheme has a different (better?) approach
to macros than Haskell?

> Haskell has marginally more syntax than
> Scheme, but for learning the basics that Haskell and Scheme have in
> common, the languages will be about equally easy to start with. Haskell
> is quite as compact as Scheme, by the way, probably more so as you get
> more sophisticated with it.

That sounds good. Shall i wait until Travis did his talk or can i right
now ask for a good introductory book on Haskell/functionall programming? :-)

BTW: how do other functional languages, (like eg Erlang, OCaml,...) fit
in here? Especially Erlangs claim to have special support for concurent
programming sounds very persuasive.

> > .o0(yet more expressions i've to look up before i can understand what's written there)
> 
> All of this is stuff where, if you want to learn about it, you need to
> sit down and study. I can't give you much more real insight into this
> stuff in an e-mail message than I have already.

That's why i didnt ask :-)
I know i'm lacking a lot of understanding in this field and that it will
take a lot of time to gain it. But then, it wouldnt be fun if i knew everything
already ;-)


				Attila Kinali
-- 
If you want to walk fast, walk alone.
If you want to walk far, walk together.
		-- African proverb