Why are functional programs shorter/faster to develop?
Author Message
Why are functional programs shorter/faster to develop?

Hello,

can anyone prove this statement to me?
I wanted to see a short code example of a functional program and the
everyday/realistic stuff.
I need to see an example of why a functional program is that much
shorter and faster to develop, like lots of people claim...

Thanks....

Mon, 06 Sep 2004 06:59:41 GMT
Why are functional programs shorter/faster to develop?
quicksort [] = []
quicksort (x:xs) = quicksort [y|y<-xs, y<=x]++[x]++quicksort [y|y<-xs,
y>=x]

Ok?

Ciao,
Steffen Mazanek

Quote:

> Hello,

> can anyone prove this statement to me?
> I wanted to see a short code example of a functional program and the
> everyday/realistic stuff.
> I need to see an example of why a functional program is that much
> shorter and faster to develop, like lots of people claim...

> Thanks....

Mon, 06 Sep 2004 07:22:34 GMT
Why are functional programs shorter/faster to develop?

Quote:

> quicksort [] = []
> quicksort (x:xs) = quicksort [y|y<-xs, y<=x]++[x]++quicksort [y|y<-xs,

^

Quote:
> y>=x]
^

> Ok?

Only if you remove one of the "="s :-)

Olaf

Mon, 06 Sep 2004 10:01:48 GMT
Why are functional programs shorter/faster to develop?

Quote:

> Hello,

> can anyone prove this statement to me?
> I wanted to see a short code example of a functional program and the
> everyday/realistic stuff.
> I need to see an example of why a functional program is that much
> shorter and faster to develop, like lots of people claim...

> Thanks....

Take a look at the following URL:

http://www.*-*-*.com/ ~doug/shootout

There is example code for many programming languages solving an
illustrative range of problems.

Mon, 06 Sep 2004 12:34:53 GMT
Why are functional programs shorter/faster to develop?

Quote:

> quicksort [] = []
> quicksort (x:xs) = quicksort [y|y<-xs, y<=x]++[x]++quicksort [y|y<-xs,
> y>=x]

> Ok?

> Ciao,
> Steffen Mazanek

Good, that convinced me. This was Haskell code I suppose?

Thanks...

Mon, 06 Sep 2004 13:59:29 GMT
Why are functional programs shorter/faster to develop?

Quote:

> > quicksort [] = []
> > quicksort (x:xs) = quicksort [y|y<-xs, y<=x]++[x]++quicksort [y|y<-xs,
>                                            ^
> > y>=x]
>     ^

> > Ok?

> Only if you remove one of the "="s :-)

Well, you should remove only one "=". If you replace <= by <
and >= by >, you will remove duplicates from the list, which
is probably not what you want.

--
Martin

Tue, 07 Sep 2004 06:41:41 GMT
Why are functional programs shorter/faster to develop?

Quote:

A Erlang version would look like this (i.e. basicly the same with minor
syntax differences):

quicksort([]) -> [];
quicksort([X|Xs]) ->
quicksort([Y || Y<-Xs, Y=<X]) ++ [X] ++
quicksort([Y || Y<-Xs, Y>X]).

Quote:
>>>quicksort [] = []
>>>quicksort (x:xs) = quicksort [y|y<-xs, y<=x]++[x]++quicksort [y|y<-xs,

>>                                           ^

>>>y>=x]

>>    ^

>>>Ok?

>>Only if you remove one of the "="s :-)

> Well, you should remove only one "=". If you replace <= by <
> and >= by >, you will remove duplicates from the list, which
> is probably not what you want.

> --
> Martin

Tue, 07 Sep 2004 09:31:41 GMT
Why are functional programs shorter/faster to develop?

Quote:

> Take a look at the following URL:

>         http://www.bagley.org/~doug/shootout

> There is example code for many programming languages solving an
> illustrative range of problems.

I took a look at several source codes there. But to be honest, I
didn't notice that much difference between functional & imperative
languages. Sometimes the functional code was shorter, but I didn't see
any really significant difference. Of course you will always find some
code that can be done significantly shorter with one language. At that
page there is a one-liner in bash that makes the word frequency count.
In all the other languages the code is at least one page. One example
doesn't mean much.
And on the average the line count of FL seems to be the same or a
little shorter than for non-functional languages. So where is the
point in using them?

Not yet convinced...

Thu, 09 Sep 2004 02:29:57 GMT
Why are functional programs shorter/faster to develop?

Quote:

>> quicksort [] = []
>> quicksort (x:xs) = quicksort [y|y<-xs, y<=x]++[x]++quicksort [y|y<-xs,
>> y>=x]
> Good, that convinced me

I saw a post asking for an algorithm to find all the possible solutions of
x1+x2+...+xn=m
for some variables n and m. Order should matter, so for n=3 m=100 you'd have
100+0+0, 0+100+0, 0+0+100, 99+1+0... etc

I came up with,

f n m | n==1 = [[m]]
| n>=0 = [(m-k):s| k<-[0..m], s<-f (n-1) k]

not exactly efficiente, but nice :)
J.A.

Thu, 09 Sep 2004 02:50:29 GMT
Why are functional programs shorter/faster to develop?

Quote:

>> quicksort [] = []
>> quicksort (x:xs) = quicksort [y|y<-xs, y<=x]++[x]++quicksort [y|y<-xs,
>> y>=x]
> Good, that convinced me

Just came up with this one recently.

find all solutions of x1+x2+...+xn=m
for some n,m integer. Order matters.
Ex n=3, m=100
100+0+0, 0+100+0, 0+0+100, 99+1+0, etc

f n m | n==1 = [[m]]
| n>=0 = [(m-k):s| k<-[0..m], s<-f (n-1) k]

:)
J.A.

Thu, 09 Sep 2004 03:04:03 GMT
Why are functional programs shorter/faster to develop?

Quote:

> I took a look at several source codes there. But to be honest, I didn't
> notice that much difference between functional & imperative languages.

There are lies, damn lies - and then there are benchmarks... ;)

Quote:
> Sometimes the functional code was shorter, but I didn't see any really
> significant difference.

Hm, really? Did you also account for (lack of) library functions or
specialized builtin features?

The benchmarks were initially written with certain problem classes in
mind, mostly text processing. There are quite many imperative special
purpose languages (Perl, Python, Ruby, Pike, Lua, Awk, Icon, etc.) in this
benchmark, all of which have significant builtin and/or library features
for this. Use those languages outside of their realms, and they come down
to their knees very fast on a comparative scale. It is interesting to note
that FPLs are still highly competitive even in this specialized field!

Quote:
> Of course you will always find some code that can be done significantly
> shorter with one language.

Most often only if it has a library function or a builting operator
for this.

Quote:
> At that page there is a one-liner in bash that makes the word frequency
> count.

You obviously see what I mean.

Quote:
> In all the other languages the code is at least one page.

Quite unsurprising, since they implement the word counting explicitly
rather than cowardly calling an already existing program for this as
the bash-entry does (what do you do if there is no such program?). Or
would you feel better when I sent the following OCaml-one-liner:

Sys.command "echo `wc`"

Quote:
> One example doesn't mean much.  And on the average the line count of
> FL seems to be the same or a little shorter than for non-functional
> languages. So where is the point in using them?

I mentioned it above: they are not specialized for these kinds of tasks
and still perform very well.

Enough of this flame war topic now! The only way to find out whether a
language suits your needs better than another is to try both...

Regards,
Markus Mottl

--

Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~markus

Thu, 09 Sep 2004 05:47:22 GMT
Why are functional programs shorter/faster to develop?

Quote:

> Hm, really? Did you also account for (lack of) library functions or
> specialized builtin features?

> I mentioned it above: they are not specialized for these kinds of tasks
> and still perform very well.

Ok, you are right, some languages will perform well because they have
specialized libraries to use. But doesn't the same applie to FL? Look
at this code example that was the first reply to my posting:

quicksort [] = []
quicksort (x:xs) = quicksort [y|y<-xs, y<=x]++[x]++quicksort [y|y<-xs,
y>=x]

This is obviously very short code! BUT, that is a consequence of
Haskells built-in LPF (list processing functions/capacities). Ok, it's
not a library but it boils down to the same. So its true that some
things can be implemented very nicely using those LPFs. If you bring
examples people will be impressed. But this doesn't mean much unless
you can prove to me that LPFs play a major role in the solution of
many coding problems.
Maybe this is the answer that I really want. Someone to tell me where
the big advantage of functional programming is not just with examples
but with some deeper explanation.
I don't think it helps much if you just tell me:

Quote:
> Enough of this flame war topic now! The only way to find out whether a
> language suits your needs better than another is to try both...

Because if I learn it, I am at big risk that I will program in an
imperative style and don't get the benefits from FL.

A good starting point was that article "Why functional programming
matters". Basically it centered around using higher order functions to
provide a new kind of glue to reuse program code. Ok, that was not
bad, but I wonder if this is all? As far as I remember most examples
dealed with list processing again. The few times I use lists is
usually to just have a List of Objects in Java and then access them
sequentially. I mean I don't think that higher order functions are
that valuable in practice. At least in my coding experience it happens
only few times where I think: "here a higher order function would come
in handy." But maybe thats just the case because I have the wrong
approach in my programs...

Greetings...

Sat, 11 Sep 2004 05:56:42 GMT
Why are functional programs shorter/faster to develop?

Quote:

> > Hm, really? Did you also account for (lack of) library functions or
> > specialized builtin features?

> > I mentioned it above: they are not specialized for these kinds of tasks
> > and still perform very well.

> Ok, you are right, some languages will perform well because they have
> specialized libraries to use. But doesn't the same applie to FL? Look
> at this code example that was the first reply to my posting:

> quicksort [] = []
> quicksort (x:xs) = quicksort [y|y<-xs, y<=x]++[x]++quicksort [y|y<-xs,
> y>=x]

> This is obviously very short code! BUT, that is a consequence of
> Haskells built-in LPF (list processing functions/capacities). Ok, it's
> not a library but it boils down to the same. So its true that some
> things can be implemented very nicely using those LPFs. If you bring
> examples people will be impressed. But this doesn't mean much unless
> you can prove to me that LPFs play a major role in the solution of
> many coding problems.

You could read this very interesting paper :

it show how combinator are a very useful programing technique
(applying it to financial programing), and combinator are a very
natural thing with functional programing.

--
Rmi Vanicat

http://dept-info.labri.u-bordeaux.fr/~vanicat

Sat, 11 Sep 2004 06:19:17 GMT
Why are functional programs shorter/faster to develop?

Quote:

> Maybe this is the answer that I really want. Someone to tell me where
> the big advantage of functional programming is not just with examples
> but with some deeper explanation.

Speaking in extravagant generalizations, I'd say:

Functional programs do not explicitly manage state, memory, or
resources.   Many programs in procedural languages require code to do
this -- ie to allocate, deallocate, initialize, finalize, cache, track
ownership and responsibilities, prevent conflicting uses, etc.  This is
not always an advantage, but often it is.

Al

Sat, 11 Sep 2004 07:36:22 GMT
Why are functional programs shorter/faster to develop?

Quote:

> This is obviously very short code! BUT, that is a consequence of
> Haskells built-in LPF (list processing functions/capacities). Ok, it's
> not a library but it boils down to the same. So its true that some
> things can be implemented very nicely using those LPFs. If you bring
> examples people will be impressed. But this doesn't mean much unless
> you can prove to me that LPFs play a major role in the solution of
> many coding problems.
> Maybe this is the answer that I really want. Someone to tell me where
> the big advantage of functional programming is not just with examples
> but with some deeper explanation.
> I don't think it helps much if you just tell me:

> > Enough of this flame war topic now! The only way to find out whether a
> > language suits your needs better than another is to try both...

> Because if I learn it, I am at big risk that I will program in an
> imperative style and don't get the benefits from FL.

OK, I'll try and explain what makes functional programming
bear with me).

Most programming is carried out in an "imperative" programming
languages such as C, Java, Pascal, Basic, etc.  In these languages,
commands are actions executed specifically for their resulting
"side-effects".  For example, an imperative program may add one to the
value of a variable, thereby causing a change in its value.  Another
altered.  When an imperative program is executed the machine's "state"
is repeatedly altered, until finally it produces the desired
end-result.

A pure functional programming language like Haskell is different.

Rather than chaining together a sequence of commands that alter the
machine's state, a sequence of functions are used instead.  Each
function's output provides the inputs for other functions until we
finally reach the "main" program itself.  In effect, a functional
program can be seen as a single calculation.  The important part to
note is that the program's constituent functions do not have
side-effects.  That is, each function will always evaluate to the same
result if it is given the same inputs.  Because of this guarantee,
functions don't have to be evaluated until their result is actually
needed, and then only as far as is necessary.

This last point is related to what is known as "lazyness".  Functions
are evaluated "lazily", in that they are only used to generate output
as long as this output is needed as input for another function.  The
moment a desired result is known, no further evaluation need take
place.  This enables the creation of functions that if fully evaluated
would create an infinite amount of data.  However, because they are
only evaluated to the minimum extent necessary, this is not a problem.

There is another aspect to this as well.  Because a function with a
given set of inputs always evaluates to the same result, it can be
seen as a synonym for that result.  We have what is known as
"referential transparency".  The function call and the function result
are in effect no different (apart from the time required to perform
the calculation).  In effect, a function call can be seen as no
different to any other piece of data that is passed around, stored and
manipulated by the program.

In our increasingly wired world, program correctness is rapidly
gaining in importance.  FP languages make it substantially easier to
reason about the program and whether it is correct.  Imperative
languages on the whole do not.  In an imperative language, running the
same function twice with the same inputs can result in different
values depending on changes that may have taken place elsewhere.  We
cannot be sure that the program will run as we expect.  In contrast, a
Haskell function that works correctly for its inputs will always work
correctly for its inputs.  It can be considered in complete isolation
from what is happening outside of itself, (it is "hygienic").

Functional programs are usually shorter because they can create and
manipulate code and data at a "higher" level.  The really significant
point however is that they contain fewer errors.  Strong static typing
eliminates a whole swathe of errors during the initial development.
Reusing functions that have already proved to be correct (perhaps even
by a mathematical proof) means that a greater percentage of your
program must be correct as well.  More time is spent debugging code
than writing it in the first place.  If there are fewer bugs, then
less time need be spent, and hence the code is finished faster.