Is it just a matter of taste?

Hi folks...

Being a C/C++ hobbyist developer for almost 6 years now (I've been
also working with some Assembly and Python too), I've become somewhat
bored at imperative languages lately, so I decided it was about time
to take a closer look at functional programming languages...
After some research, I was able to pick the ones I thought would be
more interesting for me (Erlang, Haskell, OCaml and F#). Although I
found Haskell the easiest for me to understand, there are some other
points I think I should take into consideration.

One of them is SMP. I found this topic the most confusing one... Some
say Erlang does better at parallel execution, some say Haskell
supports it and others say Haskell has no support at all.
I've been reading some papers about functional language's SMP support
and I must say this may be one of the things I'm most interested in on
FP.

Performance is always important, but as I'm not aiming to produce any
mainstream software with it I think they all do run fairly well for my
needs.

General purpose language. Before I decided to plunge deeper into any
functional programming language, I thought I should learn more about
them and get to know which one is the most widely used today, has the
most active community and has greater support for third-party
libraries (if any).

At last but not least, portability is really important.
I use both Unix (mostly FreeBSD and Linux) and Windows all the time,
so portability is something I need in any language I decide to work
with. Further system integration (as Windows API support) would be
great but it's not a requirement.

As you may have noticed, I'm only starting with FP, so if any of you
have any suggestions or appointments that might help me to choose the
right language, I'd be really grateful.

Thank you in advance.

flatpvt@gmail.com wrote:

> Being a C/C++ hobbyist developer for almost 6 years now (I've been
> also working with some Assembly and Python too), I've become somewhat
> bored at imperative languages lately, so I decided it was about time
> to take a closer look at functional programming languages...
> After some research, I was able to pick the ones I thought would be
> more interesting for me (Erlang, Haskell, OCaml and F#). Although I
> found Haskell the easiest for me to understand, there are some other
> points I think I should take into consideration.

Hello dear fellow and welcome to the world of functional programming. I
don't know F# and OCaml too well, but I can tell you a few things about
the others you mentioned, particularly Haskell, which is my main
language.


> One of them is SMP. I found this topic the most confusing one... Some
> say Erlang does better at parallel execution, some say Haskell
> supports it and others say Haskell has no support at all.
> I've been reading some papers about functional language's SMP support
> and I must say this may be one of the things I'm most interested in on
> FP.

The state of things is that both Erlang and Haskell support concurrency
and actually have it in nature. However, concurrency is not
automagically the same as parallelity, e.g. SMP. Both perform extremely
well, outperforming even C code in many cases, thanks to the excellent
run-time system and so-called 'lightweight threads'.

What is very convenient about this type of concurrency is that threads
are the natural abstraction to concurrently existing calculations. For
example, there is nothing wrong with connecting to 1000 ports by
launching 1000 threads to connect to a single port. There is nothing
wrong with launching a thread for every single client connecting, even
for high traffic services. In fact, this is the way to go.

Erlang was originally made specially focussing on network application
and thus massive scalability. It does its job very well. Since recent
versions of the Glasgow Haskell Compiler (GHC), Haskell is up with
Erlang and even better at some places. Sadly there is no general
formula as to which language to prefer for a particular case.


> Performance is always important, but as I'm not aiming to produce any
> mainstream software with it I think they all do run fairly well for my
> needs.

Considering that you save a lot of development time (functional code is
almost always much shorter than imperative code, and still easier to
understand), you may get your result much faster, even if the code is
not optimal.

Erlang: You don't have to worry about performance too much. Even the
original interpreted Erlang performs very well for calculations. If you
need native code performance, there is also a compiler available (HIPE).

Haskell: In many cases GHC produces code, which outperforms even
equivalent GCC-produced code. Generally you will get quite decent code
speed. I often implement algorithms by creating an infinite list and
folding a finite portion of it or by indexing an element somewhere in
the list. Surprisingly this is usually faster than coding the algorithm
in some iterative or recursive fashion.

My favorite Haskell example is the Lucas-Lehmer primality test for
Mersenne numbers [1], which involves checking an element of an infinite
sequence:

-- The Lucas-Lehmer sequence modulo n.
llSequence :: Integral a => a -> [a]
llSequence n = iterate (\x -> mod (x^2 - 2) n) 4

-- 'isPrime n' is True, if 2^n - 1 is prime.
isMersennePrime :: Integral a => a -> Bool
isMersennePrime e = llSequence (2^e - 1) !! (e-2) == 0

This is almost the mathematical definition. It defines an infinite list
and checks an element of it, and it runs just as fast as the equivalent
C code, which algorithmically calculates that element.


> General purpose language. Before I decided to plunge deeper into any
> functional programming language, I thought I should learn more about
> them and get to know which one is the most widely used today, has the
> most active community and has greater support for third-party
> libraries (if any).
>
> At last but not least, portability is really important.
> I use both Unix (mostly FreeBSD and Linux) and Windows all the time,
> so portability is something I need in any language I decide to work
> with. Further system integration (as Windows API support) would be
> great but it's not a requirement.

Should be no problem with both languages. Though, as always there are a
few Windows-specific details you'll have to deal with (or at least
consider). For example, in Haskell, you will need to initialize the
sockets interface using the 'withSocketsDo' function.


> As you may have noticed, I'm only starting with FP, so if any of you
> have any suggestions or appointments that might help me to choose the
> right language, I'd be really grateful.

I should add that I have talked much more about Haskell than Erlang,
because I have much less experience in Erlang than in Haskell. Every
language has its upsides and downsides. For me, the original reason for
preferring Haskell over Erlang was that Haskell is a purely functional
language, while Erlang is not, and I liked the syntax of Haskell more.

It was somewhat challenging to learn it, though, and there is a lot of
brainpaining theory out there. Luckily as a practical application
programmer you can ignore most of it, as you always get along with the
basics. You may miss a lot of interesting theory and maybe even write a
bit longer code, but the shortest possible code is not always the best
comprehensible or the fastest code.


Greets,
Ertugrul.


--
nightmare = unsafePerformIO (getWrongWife >>= sex)

On Wed, 23 Jul 2008 02:38:13 +0200, Ertugrul Soylemez <es@ertes.de>
wrote:

>flatpvt@gmail.com wrote:
>
>[...]
>
>My favorite Haskell example is the Lucas-Lehmer primality test for
>Mersenne numbers [1], which involves checking an element of an infinite
>sequence:

You messages seems to be missing the reference to [1]. If you don't
mind, could you please provide the missing reference?

-- Benjamin L. Russell

On Wed, 23 Jul 2008 02:38:13 +0200, Ertugrul Soylemez <es@ertes.de>
wrote:

>flatpvt@gmail.com wrote:
>
>[...]
>
>My favorite Haskell example is the Lucas-Lehmer primality test for
>Mersenne numbers [1], which involves checking an element of an infinite
>sequence:

Your message seems to be missing the reference to [1]. If you don't
mind, could you please provide the missing reference?

-- Benjamin L. Russell

flatpvt@gmail.com wrote:
> As you may have noticed, I'm only starting with FP, so if any of you
> have any suggestions or appointments that might help me to choose the
> right language, I'd be really grateful.

As you want to learn rather than write production-quality code, I recommend
replacing F# with Scheme and Mathematica.

F# is little more than a tiny subset of OCaml with no decent tools, few
libraries and vendor lock-in that is specifically designed to let you build
products for Windows in a language better than Java/C#.

Of course, if you ever do want to write production code in a decent language
then F# is head and shoulders above of all other functional languages
simply because it has more rich users and a commercial DLL market.

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u

Benjamin L. Russell <DekuDekuplex@Yahoo.com> wrote:

> On Wed, 23 Jul 2008 02:38:13 +0200, Ertugrul Soylemez <es@ertes.de>
> wrote:
>
> > My favorite Haskell example is the Lucas-Lehmer primality test for
> > Mersenne numbers [1], which involves checking an element of an
> > infinite sequence:
>
> Your message seems to be missing the reference to [1]. If you don't
> mind, could you please provide the missing reference?

Indeed, I've forgotten to mention it, sorry. But as you may have
guessed, it's just a reference to Wikipedia. Anyway, here it is:

[1] http://en.wikipedia.org/wiki/Lucasâ€...rsenne_numbers


Greets,
Ertugrul.


--
nightmare = unsafePerformIO (getWrongWife >>= sex)

On Sat, 26 Jul 2008 01:09:55 +0100, Jon Harrop <jon@ffconsultancy.com>
wrote:

>flatpvt@gmail.com wrote:
>> As you may have noticed, I'm only starting with FP, so if any of you
>> have any suggestions or appointments that might help me to choose the
>> right language, I'd be really grateful.
>
>As you want to learn rather than write production-quality code, I recommend
>replacing F# with Scheme and Mathematica.

Speaking of Mathematica, I am also interested in learning this
tool/language, but find it rather expensive. Because I am not a
student, educator, or government employee, I am not eligible for any
of Wolfram Research's discounts. I would prefer to learn Mathematica
with a tutorial or book by myself, rather than in a classroom setting,
in my spare time after work.

Any suggestions?

-- Benjamin L. Russell

Benjamin L. Russell wrote:
> On Sat, 26 Jul 2008 01:09:55 +0100, Jon Harrop <jon@ffconsultancy.com>
> wrote:
>>flatpvt@gmail.com wrote:
>>> As you may have noticed, I'm only starting with FP, so if any of you
>>> have any suggestions or appointments that might help me to choose the
>>> right language, I'd be really grateful.
>>
>>As you want to learn rather than write production-quality code, I
>>recommend replacing F# with Scheme and Mathematica.
>
> Speaking of Mathematica, I am also interested in learning this
> tool/language, but find it rather expensive. Because I am not a
> student, educator, or government employee, I am not eligible for any
> of Wolfram Research's discounts.

Yes, Mathematica is extremely expensive for non-students. Indeed, it is
probably cheaper to enroll yourself as a student just to buy Mathematica!

> I would prefer to learn Mathematica with a tutorial or book by myself,
> rather than in a classroom setting, in my spare time after work.
>
> Any suggestions?

You're screwed. :-)

The only feasible way to learn Mathematica on-the-cheap is to be a student
and buy the (very affordable and feature-complete) student edition.

This is a great shame because it prevents people like yourself from learning
from this incredible piece of software. However, without the revenue stream
of industrialists willing to pay a lot for legitimate copies of
Mathematica, the development of this product could not have been afforded
and it would not even exist. So I'm very glad that Wolfram Research
continue to do such pioneering work and charge what their products are
worth.

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u

flatpvt@gmail.com wrote:
> After some research, I was able to pick the ones I thought would be
> more interesting for me (Erlang, Haskell, OCaml and F#).

The most important differences: Haskell is non-strict and purely functional,
the others are strict and impure (i.e. functions can have side-effects). F#
and Ocaml are quite similar (this is hearsay, I am not an expert). Erlang
was designed for control systems, (soft) realtime stuff etc. and is the
only one that directly supports distributed programs.

> One of them is SMP. I found this topic the most confusing one... Some
> say Erlang does better at parallel execution, some say Haskell
> supports it and others say Haskell has no support at all.
> I've been reading some papers about functional language's SMP support
> and I must say this may be one of the things I'm most interested in on
> FP.

Erlang was designed mainly for concurrency, but supports SMP, too.

The quasi-standard Haskell implementation GHC offers a lot of SMP support,
including high-level combinators like 'par' that are pure and completely
abstract from things like threads etc (but you have explicit threads, too,
for concurrent programming).

Both Erlang and Haskell /threads/ are very light-weight, but
for /parallelism/ they still have to be mapped to system threads of which
the run-time system maintains a pool, the size of which can (in Haskell at
least) be configured on process startup.

I personally find Erlang code a bit harder to read, due to the Prolog-like
syntax.

I don't know much about SMP support for Ocaml and F#.

> Performance is always important, but as I'm not aiming to produce any
> mainstream software with it I think they all do run fairly well for my
> needs.
>
> General purpose language. Before I decided to plunge deeper into any
> functional programming language, I thought I should learn more about
> them and get to know which one is the most widely used today, has the
> most active community and has greater support for third-party
> libraries (if any).

Due to its integration with .Net, F# can be expected to have good library
support.

The most active community is probably Haskell, but don't ask me for hard
data. The only one I can come up with is the Google summer of code ranking,
where Haskell ranks first of all functional languages. Ocaml, however,
seems to be used more often in commercial projects.

> At last but not least, portability is really important.
> I use both Unix (mostly FreeBSD and Linux) and Windows all the time,
> so portability is something I need in any language I decide to work
> with. Further system integration (as Windows API support) would be
> great but it's not a requirement.

F# would be the obvious candidate for Windows integration. I know that
Haskell works fine on Windows, too, but library support tends to favour
Linux.

Cheers
Ben

Ben Franksen wrote:
> The quasi-standard Haskell implementation GHC offers a lot of SMP support,
> including high-level combinators like 'par' that are pure and completely
> abstract from things like threads etc (but you have explicit threads, too,
> for concurrent programming).

Apparently GHC's standard library is not parallelized at all, which
surprised me.

> I don't know much about SMP support for Ocaml and F#.

SMP support in OCaml is non-existent. SMP support in F# is awesome, far
better than any other functional language.

> Due to its integration with .Net, F# can be expected to have good library
> support.

You might expect that but prepare to be sorely disappointed. The .NET
framework provides a tiny fraction of the functionality already available
to languages like OCaml via bindings to ordinary Linux libraries.
Proprietary libraries and protocols are a notable exception, of course. For
example, if you want to do technical computing, .NET doesn't even provide
complex numbers. You can throw money at the problem but the majority of
commercial libraries available for .NET are of very low quality, much lower
than the primary open source solutions. They are also almost entirely
incompatible.

> The most active community is probably Haskell, but don't ask me for hard
> data. The only one I can come up with is the Google summer of code
> ranking, where Haskell ranks first of all functional languages. Ocaml,
> however, seems to be used more often in commercial projects.

The Haskell community generate far more blog posts, usenet posts, Reddit
posts and so on than any other functional programming community, including
OCaml.

However, the Haskell community generate almost no useful software:

http://ocamlnews.blogspot.com/2007/1...-programs.html
http://haskell-news.blogspot.com/200...-programs.html

That speaks volumes.

>> At last but not least, portability is really important.
>> I use both Unix (mostly FreeBSD and Linux) and Windows all the time,
>> so portability is something I need in any language I decide to work
>> with. Further system integration (as Windows API support) would be
>> great but it's not a requirement.
>
> F# would be the obvious candidate for Windows integration.

But F# is not reliably portable.

> I know that Haskell works fine on Windows, too, but library support tends
> to favour Linux.

Same for OCaml but working with OCaml on Windows is seriously painful
compared to F#. However, the reason is vendor lock-in: F#'s Visual Studio
mode uses a programmatic interface to the F# compiler that Microsoft are
keeping under wraps to prevent third parties from competing with them in
building F# development tools.

I think the open source world could really do with a new, practical open
source functional language implementation...

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u