Re: Is it just a matter of taste?

flatpvt@xxxxxxxxx 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)

.

Relevant Pages

  • Re: how is Haskell not robust?
    ... Haskell has not reached critical mass. ... have a thousand packages but still poor support for mainstream package ... If anyone would make money with the language or a compiler ...
    (comp.lang.functional)
  • Re: Other languages to try?
    ... I went on a spree recently and bought several books on Erlang, Haskell, ... I'd been leaning toward Scheme because I always wanted to learn ... Since for me this is practically the ideal way to learn a language ...
    (comp.lang.ruby)
  • Re: Is it just a matter of taste?
    ... more interesting for me (Erlang, Haskell, OCaml and F#). ... Haskell is non-strict and purely functional, ... and Ocaml are quite similar ... I've been reading some papers about functional language's SMP support ...
    (comp.lang.functional)
  • Re: What do you LISPers think of Haskell?
    ... And I don't want to "get around" the language. ... Haskell was designed to be the Common Lazy Typed FPL. ... is much deeper in its support for FP than Common Lisp, ...
    (comp.lang.lisp)
  • Is it just a matter of taste?
    ... to take a closer look at functional programming languages... ... found Haskell the easiest for me to understand, ... I've been reading some papers about functional language's SMP support ... General purpose language. ...
    (comp.lang.functional)
Loading