Re: [tlug] recomendations for a functional language

[Curt Sampson <cjs@example.com>]

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.

> 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.

In Clojure, for example, anything that comes out of the compiler is
going to work iteratively, because the JVM doesn't support tail call
optimization.

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.

> 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. 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.

> And, if i understood you correctly, Haskell seems to be a superset
> of concepts of Lispy and other functional languages?

Right. Syntax differences aside, you can think of ML as being much like
a Lisp with a different syntax, no macros, and a Hindley-Milner type
system. Haskell adds purity, changes evaluation from strict to lazy, and
gives you libraries full of Monads.

> >   * Lisp does a lot, whereas Scheme is missing a lot, from certain very
> >   pragmatic points of view.
> 
> And from a not so pragmatic point of view?

>From a not-so-pragmatic point of view, they're the same. :-)

As for some of your other questions:

> On Tue, 3 Nov 2009 00:06:47 +0900
> Curt Sampson <cjs@example.com> wrote:
> 
> > Don't underestimate this difference. Moving from duck typing to a
> > good H-M type system is a larger jump than....
> 
> Can you elaborate that a little bit?
> I didn't know about H-M before and cannot immediatly see what
> makes it more powerfull than the dynamic typing i'm used from
> dynamic languages.

With dynamic typing, if you make a mistake, you have a failure at
runtime. Static typing systems offer a computer-verified proof that
certain types of failures cannot happen at runtime (baring something
like hardware failure). That means you don't need to bother to test
certain parts of your code, since you've got a proof that they cannot
fail.

The same is true of Java's type system, of course, but HM is
significantly more powerful, letting you prove a huge number of things
that are impossible to prove within Java's type system.

> Respectively, what insights did it give you on relational theory?
> ...
> > But keep in mind, a reasonably powerful type system *is* a programming
> > language in and of itself.
> 
> I dont understand this, could you give a few examples?
> ...
> >   * the Lisp-1 versus Lisp-2 distinction (which can itself be
> >   over-summarized as whether function variables and non-function
> >   variables share a namespace, but upon research it turns out to be a
> >   lot more subtle than that),
> 
> What kind of subtilities?
> ...
> .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.

cjs
-- 
Curt Sampson       <cjs@example.com>        +81 90 7737 2974
           Functional programming in all senses of the word:
                   http://www.starling-software.com