Re: [tlug] recomendations for a functional language

[Attila Kinali <attila@example.com>]

Moin,

On Tue, 3 Nov 2009 00:06:47 +0900
Curt Sampson <cjs@example.com> wrote:

> On 2009-11-02 18:12 +0900 (Mon), Alan Busby wrote:
> 
> > On Mon, Nov 2, 2009 at 5:28 PM, Curt Sampson <cjs@example.com>wrote:
> > >
> > > Note, however, that Clojure, being a Common Lisp variant, is not really so
> > > functional as even Scheme, not to mention missing very interesting features
> > > such as pattern matching and a Hindley-Milner system.
> > 
> > Although it uses duck typing, and not Hindley-Milner....
> 
> Don't underestimate this difference. Moving from duck typing to a
> good H-M type system is a larger jump than moving from something like
> Java's "static" type system to Ruby's "dynamic" type system. Duck
> typing is undoubtedly cool, but proving that your program cannot
> ever fail in certain ways (bar compiler bugs or hardware failure) is
> mind-blowing, and will change the way you look at everything. (It gave
> me some interesting new insights into relational [database] theory, for
> example.)

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. Respectively, what insights did it give you on
relational theory?

> And that, in fact, is the key to STM in Haskell as well. Haskell's STM
> is nothing special in terms of STM itself; it's just doing what's been
> available in C and other languages for a longer period of time. It's
> the type system and its ability to contain and control side effects
> and state that makes GHC's rather primitive implementation of STM work
> better than much more sophisticated implementations that have been
> written for C compilers.

Hmm.. didn't we had a discussion on STM just a few months ago?
 
> > I'd argue that learning to use macros well, offers more educationally than
> > the Hindley-Milner type system. Not that static typing isn't useful, but it
> > doesn't open up new ways of thinking like the way code generation does.
> 
> Nope. Quite the other way around. But IMHO. I'll admit I don't have a
> lot of experience writing Lisp macros. (Now, M4 macros, that's another
> story. :-))

M4 is one of the weirdest languages i know. Not because it's a markov
language, but because it has only three construcs: definitions, quotes
and comments, and yet it can express horribly complex stuff.
But every time i have to do something in M4, i have to learn from
scratch how to think in substitutions ^^;

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


> On 2009-11-02 11:23 +0100 (Mon), Attila Kinali wrote:
> 
> > You graded Common Lisp, Scheme and Haskell, without giving much
> > information how you compared them. May i ask what you think the
> > major differences of these languages are?
> 
> I think my comments above are applicable to most languages versus
> Haskell. The big exception would be the ML family (of which Haskell
> is more or less a member, really, albeit a rather odd cousin), and,
> somewhat further away, Scala and Erlang.
> 
> For Common Lisp versus Scheme, I'd summarize the differences as:
> 
>   * 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?
 
>   * that Lisp tends heavily towards iteration and Scheme towards
>   recursion,

Now, that's interesting. I thought that functional languages hardly
support iteration but "force" you to do it recusively?


>   * (previously) Lisp has macros, and Scheme doesn't, (now) Lisp has
>   macros but Scheme has hygienic macros, but again, this distinction
>   turns out to have tons of, er, "interesting" ramifications once you
>   get into it, and makes you really think even more about whether you
>   wanted macros or not;

.o0(yet more expressions i've to look up before i can understand what's written there)

>   * 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?

> I can't really say you can go wrong learning either Common Lisp or
> Scheme, quite frankly. They're a lot more different from each other than
> Python or Ruby, but the greater differences all seem to be in areas
> that are very troublesome and bear a lot of thinking about. Looking at
> Clojure, actually, it seems as if it might be one of the best of the
> Lispy languages to learn, if you're going to go that way.

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.

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

> On 2009-11-02 18:12 +0900 (Mon), Alan Busby wrote:
> 
> > Irregardless of quality, or old/bad design in many cases, it's very useful
> > not to have to write an entire library by hand simply to deal with paypal,
> > amazon, or any number of other systems.
> > Not to mention the additional ease of deployment, like running code on
> > Hadoop clusters on Amazon EC2.
> 
> Well, "writing an entire library by hand" is quite often not nearly
> as hard as you'd think, if you're a half-way competent programmer. (I
> have proof: I've done this, and I'd say I'm about half-way competent.
> Hmm. Come to think of it, I may well be better at writing papers than
> programming. I really should move to academia. :-))
> 
> And ease of deployment, well, this is one of the reasons I tend not to
> use other people's libraries, frameworks, and so on.

>From my PoV, being able to quickly write a library by hand is a very
good argument for a programming language. And it's actually my biggest
complaint about Java: Providing a huge library of classes that can
be used for 1001 task is nice, but help you <insert celestial being here>
if you choose the wrong class, you'll end up typing 1002 lines just to
support it. The C and Perl way is a lot more to my liking: you can use
one of the many libraries around, but you don't have to. You can equally
well write your own functions/classes and it wont that much more time.


			Attila Kinali

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