How fast can you write functional programs?
Frank Buss
fast I can type is the limiting factor, for example if I write a nested
loop. Programs in functional languages are much shorter for the same task
(for example at http://tinyurl.com/aric I shrink a 30 line Java program to
a 2 line Haskell program), but I have to think longer about a problem to
find a good solution which can be expressed in a functional language. Is
this the normal case for functional languages, or do I need more experience
only?
--
Frank Buß, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Kirsten Chevalier
> If I write a program in an imperative language, sometimes only the way how
> fast I can type is the limiting factor, for example if I write a nested
> loop. Programs in functional languages are much shorter for the same task
> (for example at http://tinyurl.com/aric I shrink a 30 line Java program to
> a 2 line Haskell program), but I have to think longer about a problem to
> find a good solution which can be expressed in a functional language. Is
> this the normal case for functional languages, or do I need more experience
> only?
As a Haskell programmer, I can often write programs as fast as I type, as
well. But when I occasionally try to program in C or Java, I find that the lack
of higher-order functions makes it much more difficult for me to express a
solution. It's a matter of what you're used to.
Anyway, the important questions are (a) can someone equally experienced in a given
functional language and a given imperative language write programs more quickly
in one language than the other (I'd be inclined to believe that given equal
experience, programming in a functional language would be faster), and (b) how
long does it take to write, test, *and* debug a program in a given language?
I can write a program very quickly in any of the languages I know, but that
doesn't mean it works!
--
Kirsten Chevalier * Often in error, never in doubt
"I'm getting further from the things I thought I knew, but I'm getting closer
to the truth."--Trout Fishing in America
http://www.cs.berkeley.edu/~krc/
Oleg Trott
> As a Haskell programmer, I can often write programs as fast as I type, as
> well.
Are you a millionaire or a very slow typist? :)
Sebastian Sylvan
> a 2 line Haskell program), but I have to think longer about a problem to
> find a good solution which can be expressed in a functional language. Is
> this the normal case for functional languages, or do I need more experience
> only?
Well I guess a very large part of this is inexperience. I am slowly
becoming more functional and less imperative in my thinking, but it takes
quite some time to unlearn the imperative ways.
Another point is that one line in Haskell can express 10 times as much as
one line in Java, so it's not unreasonable if you have to think 10 times
as much (if that is the case). So for beginners, you might not gain as
much from the pure typing aspect (although the correctness issue may gain
you tons of time), but with increasing experience I think you'll find that
the problem disappears completely.
--
----------------------------------------
| Sebastian Sylvan |
| ICQ: 44640862 |
| Tel: 073-6818655 / 031-812 817 |
| |
| |
| Hard Work Often Pays Off After Time |
| But Laziness Always Pays Off Now! |
----------------------------------------
Roger Larsson
> If I write a program in an imperative language, sometimes only the way how
> fast I can type is the limiting factor, for example if I write a nested
> loop. Programs in functional languages are much shorter for the same task
> (for example at http://tinyurl.com/aric I shrink a 30 line Java program to
> a 2 line Haskell program), but I have to think longer about a problem to
> find a good solution which can be expressed in a functional language. Is
> this the normal case for functional languages, or do I need more
> experience only?
>
A program is read more times than it is written.
So the real question to ask is how fast can a program be read
(and understood).
The sad part is that functional (languages and) programs are often written
in a terse mathematical style (short variable names, APL like language
syntax - preferres special characters to introducing new keywords).
/RogerL
--
Roger Larsson
Skellefteå
Sweden
Frank Buss
> (b) how long does it
> take to write, test, *and* debug a program in a given language? I can
> write a program very quickly in any of the languages I know, but that
> doesn't mean it works!
For Java and C++ I always try the test-first concept:
http://www.xprogramming.com/xpmag/test_first_intro.htm
This is used for Smalltalk from the "XP Gurus", too, so it should be
possible to use it for functional languages, too.
And I think writing a program in Haskell is less error prone, because the
compiler does very good type checking and the expressions are much clearer,
because they are more compact and you don't have to read lines of lines of
code.
Frank Buss
> A program is read more times than it is written.
> So the real question to ask is how fast can a program be read
> (and understood).
Reading a functional program is easier for me (beeing a functional
programmer beginner) than writing it.
> The sad part is that functional (languages and) programs are often
> written in a terse mathematical style (short variable names, APL like
> language syntax - preferres special characters to introducing new
> keywords).
I like the special characters like "`", "|", "<-" etc., because it gives
your program a better structure. But you are right, everyone should avoid
short variable names (important for functions) and uncommented code.
George Russell
> If I write a program in an imperative language, sometimes only the way how
> fast I can type is the limiting factor, for example if I write a nested
> loop. Programs in functional languages are much shorter for the same task
> (for example at http://tinyurl.com/aric I shrink a 30 line Java program to
> a 2 line Haskell program), but I have to think longer about a problem to
> find a good solution which can be expressed in a functional language. Is
> this the normal case for functional languages, or do I need more experience
> only?
To answer the last question first: I think you need more experience. Most
functional languages (like Glasgow Haskell) provide enough get-out clauses
that in practice you can write imperative code in them, just as you would
in C or Java. However as you continue to use the language you will or at
least should develop (a) experience of better functional solutions, when
they exist; (b) a small library of imperative solutions for things like
circular lists and hash tables, which really are difficult, tiresome or
inefficient to code in a functional language, so that you don't have to
write them again.
As for "How fast can you write functional programs" I think this is
meaningless. Some programs take about the same length of time
whatever reasonable language you wrote them in, because the problems
they solve are extremely tricky. If you need to develop and research
a new algorithm, it might take several months or years to write
30 lines of code. On the other hand, when you implement some clearly
defined specification and know exactly what the program is going to do
and how it is going to do it, you can code very fast, and I think you
can code much faster in a functional language, because a lot of the
errors that come from carelessness will be picked up for you by the type
system.
Marco Lange
> If I write a program in an imperative language, sometimes only the way how
> fast I can type is the limiting factor, for example if I write a nested
> loop. Programs in functional languages are much shorter for the same task
> (for example at http://tinyurl.com/aric I shrink a 30 line Java program to
> a 2 line Haskell program), but I have to think longer about a problem to
> find a good solution which can be expressed in a functional language. Is
> this the normal case for functional languages, or do I need more experience
> only?
As you already said, typing speed is usually not the limiting factor in
functional programming. It often takes some time to formulate a good
functional solution, as far as I am concerned, but - again as you said -
on line of Haskell code can add up to 10 lines of Java or C code. It is
simply a matter of experience, I guess, when I started programming in
imperative languages, I often had to think about the solutions a long
time, too. But, as one gains more and more experience with functional
programming, and especially with the really good standard library
provides with haskell, the solutions seem to become easier. Like in
Java or C or whatever, reading code is often the clue to find elegant
and good solutions. When I read a Haskell program I wrote one year ago,
I see what can be improved at once, e.g. converting programmed
recursions into fold{l,r} constructions etc.
So simply give it a bit time, I am also still a Haskell newbie, but
my skills get better every day :)
Best regards,
Marco
Ketil Malde
> I like the special characters like "`", "|", "<-" etc., because it gives
> your program a better structure. But you are right, everyone should avoid
> short variable names (important for functions) and uncommented code.
I don't agree. Short variable names are often fine.
If you have a function working on lists in a general fashion, naming
that list xs or (x:xs) is perfectly fine, IMHO. You could name it,
Descriptive names are good, but short descriptive names are better.
And with good conventions, short names can be as descriptive.
If you write a function that is somehow similar to multiplication,
naming it ** or *' or *. might be a good choice.
On the other hand, long names are often quite tedious and
distracting, in particular if they are used a lot. If you really need
long names to keep variables apart, it's a sign that you have too many
variables in a context, and the solution is to redesign, not to invent
longer names.
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
Ulf Wiger
> If I write a program in an imperative language, sometimes
> only the way how fast I can type is the limiting factor,
> for example if I write a nested loop. Programs in functional
> languages are much shorter for the same task (for example at
> http://tinyurl.com/aric I shrink a 30 line Java program to
> a 2 line Haskell program), but I have to think longer about
> a problem to find a good solution which can be expressed in
> a functional language. Is this the normal case for functional
> languages, or do I need more experience only?
Our experience from design of large systems in both imperative
and functional languages is that line-per-hour productivity
is roughly the same regardless of language. This is a fairly
strong argument in favour of functional languages, since you
can express the same high-level functionality in fewer lines
of code than in languages like C, Java, etc.
A refined observation is that line-per-hour productivity
metrics tend to become more and more useless as a product
matures, and possibly more so when functional languages are
used. Referential transparency pays off when maintaining
software, partly because the risk of introducing unwanted
side effects with bug fixes is much lower, and partly because
(for roughly the same reason) it is much easier to re-write
your software without breaking stuff.
<aside>Measuring productivity in rewriting software is
usually not popular in large organizations, since having
to rewrite your code probably means that you didn't do
the job right to begin with. Personally, I think writing
a first working program in 10,000 lines of code, and then
rewriting it into a better 3,000 LOC program is a good
way to develop software, even if it gives you a lousy
score on the lines-per-hour productivity chart.</aside>
How fast a program can be written depends greatly on the
problem to be solved, of course. I've written programs
(in Erlang) where my typing speed was the main limiting
factor (and I'm a pretty good typist.) On the other hand,
with the problem I'm currently working on, I have been
writing perhaps 2 lines of code per day on average --
not just because I've been distracted by other things,
but because the big problem lies in getting the structure
right. Once I'm happy with the structure, I expect to
make much better progress. Even here, working with a
functional language is a bliss because the structure
is so much more visible than it would be in e.g. C.
/Uffe
--
Ulf Wiger, Senior Specialist,
/ / / Architecture & Design of Carrier-Class Software
/ / / Strategic Product & System Management
/ / / Ericsson AB, Connectivity and Control Nodes
Jerzy Karczmarczuk
> A program is read more times than it is written.
Unless you write some programs for your students. Then it happens that
some programs are written one more times than read.
> So the real question to ask is how fast can a program be read
> (and understood).
The personal differences in speed of reading *anything* , and technical
information in particular, vary so enormously, that I would be very
reluctant in producing any speculations on this subject. Ulf Wigner
from the perspective of his milieu is able to speak about lines-per-hour
productivity, etc., but I wonder how to measure the variance, not only
the average...
Perhaps in an enterprise the staff becomes quickly homogeneous (too good
go elsewhere, too bad are fired...), but "out there" the fluctuations
are really huge. At least at the University they are enormous.
Mind you, programming languages are also a part of human culture, with all
its redundancy, "false" trails, misunderstanding, modes, gossips and
huge publicity involved.
Functional programming is more "artistic" than the imperative one, in
my eyes of course. This means that sometimes you must wait for a concept,
for your 'Eureca!'.
Moreover, -- this is addressed to people who claim that the language XXX
is good, because compiler does all the checking:
Do you really think that 100% of programs which are written, are really
tested? An amazingly large percentage of programs included in journals or
conference proceedings are buggy, because of some redaction issues,
miscopy/paste disease, name changing "for the sake of clarity", etc. Some
years ago I kept a list of particularly tasty errors of those programs
which are *explicitly meant* to be read. I threw it away, because I was
getting depressive...
Jerzy Karczmarczuk
Frank Buss
> I don't agree. Short variable names are often fine.
>
> If you have a function working on lists in a general fashion, naming
> that list xs or (x:xs) is perfectly fine, IMHO. You could name it,
> Descriptive names are good, but short descriptive names are better.
> And with good conventions, short names can be as descriptive.
I agree. With "short" I mean a single character or unreadable abbreviations
(like in some COBOL programs), which is in general bad for functions (only
useful for mathematical functions, like * for your own matrix
multiplication). But for function arguments perhaps it is a good idea, if
there are conventions for it, because then you can read and write it
faster. But if there are more than one or two arguments, they should be
named with words, like "readInt radix isDig digToInt s = ..." in the
Haskell prelude.
Ketil Malde
> <aside>Measuring productivity in rewriting software is
> usually not popular in large organizations, since having
> to rewrite your code probably means that you didn't do
> the job right to begin with.
Apparently, P.G. Woodehouse used to write his books one page at a
time. When a page was finished, he stuck it on the wall, at a height
he felt was relative to the quality of the page. Then he rewrote the
lowest pages, until all pages were at least half-way up.
I'm planning to implement the same technique for my programs, and see
how it goes.
(You can tell I'm not in a commercial company, can't you :-)
Ulf Wiger
> The personal differences in speed of reading *anything* ,
> and technical information in particular, vary so enormously,
> that I would be very reluctant in producing any speculations
> on this subject. Ulf Wigner from the perspective of his milieu
> is able to speak about lines-per-hour productivity, etc., but
> I wonder how to measure the variance, not only the average...
Yes, I should of course have clarified that our observations
were from comparing roughly similar systems, and that the
line-per-hour productivity estimates were rough averages
based on total project man-hours (including administrative
overhead and testing) and the total line count in the final
system. A very rough metric indeed.
I might add that the volumes we're talking about here are
millions of lines of code and hundreds of thousand man-hours.
Also, these types of system usually have testing period of
a few months before they're released. I will refrain from
any conclusions other than that this is pretty different from
comparing the speed of which one can write a small program
in different languages.
Christian Szegedy
> If I write a program in an imperative language, sometimes only the way how
> fast I can type is the limiting factor, for example if I write a nested
> loop. Programs in functional languages are much shorter for the same task
> (for example at http://tinyurl.com/aric I shrink a 30 line Java program to
> a 2 line Haskell program), but I have to think longer about a problem to
> find a good solution which can be expressed in a functional language. Is
> this the normal case for functional languages, or do I need more experience
> only?
>
There is another interesting effect in functional
languages:
In an imperative language, mainly the lookup time for
existing functions decreases as you get more
and more experienced.
In functional languages, the number of lines
you need to solve an problem decreases drastically
also because of the higher degree of abstraction
and the increasing usage of higher level combinators
etc.
So you are not only get faster, but you tend to
have to type less as you become more experienced e.g.
in Haskell.
Siegfried Gonzi
> If I write a program in an imperative language, sometimes only the way how
> fast I can type is the limiting factor, for example if I write a nested
> loop. Programs in functional languages are much shorter for the same task
> (for example at http://tinyurl.com/aric I shrink a 30 line Java program to
> a 2 line Haskell program), but I have to think longer about a problem to
> find a good solution which can be expressed in a functional language. Is
> this the normal case for functional languages, or do I need more experience
> only?
Hawidiehre:
One more thing which I would recommend: the Clean book. There is the old
saying that Kernighan/Ritchie is all what you want to know when you are
programming in C.
I feel a bit the same about the Clean book. Surely, it would need a bit
of an overhaul (especially i/o) but it was invaluable for me while
learning functional programming. Honestly speaking it is my one and only
book which covers functional programming.
By the way: are there any Haskell books out there where you would say it
is everything (as with K/R) what you have to know when programming in
Haskell?
I think a more interesting question ist the following: whether
functional programs are readable a year later. A 30 line Java program is
not that much of a problem, because it depends on quite some repetetive
tasks which can quickly become hacked in; but as programs tend to become
longer and longer in size and lines does it pay off to have a similar
program which is a fraction of the lines when you want to read it later
a year?
S. Gonzi
Darius
I don't have statistics to back this up (not that they don't exist,
they may, I just don't have them), or even extensive experience
maintaining large functional programs so this is just a logical
argument.
The repetitive code may be repetitive but there are several minor (or
not so minor) variations on say going over a collection and doing
something to each argument. So, you need to repeatedly parse the code
to see what it does. This isn't much of a problem with some
experience, any C/C++/Java programmer can immediately recognize
certian idioms, e.g.
for(int i=0; i<len; ++i) foo(a[i]);
An experienced C/C++/Java programmer can likely grok the whole pattern
at a glance, however internally they won't think 'for ...', they'll
think 'apply foo to all elements of a'. Functional programs are
shorter, in part, because when repetitive code like the above is
found, it's abstracted into a new control structure, e.g. map.
Further, with polymorphism the same idea can be generalized so the
pattern will be immediately evident even in new circumstances. In C
the code to apply foo to each element of a tree will look totally
different than the code for an array, in Haskell you could use fmap
for both.
Another problem is it -is- necessary to parse the code, some idioms
look very similar:
int acc=0;
for(int i=0; i<len; ++i) acc+=a[i];
This isn't an 'apply foo to each element' idiom, it's an 'iterate and
accumulate' one, and in Haskell this has it's own name, foldl.
So the ultimate point here is not only should the code be shorter, it
should be more regular for similar things, while more discriminating
for diffent things. Or as a catch-phrase, they are more precise and
more concise.
Albert Lai
> If I write a program in an imperative language, sometimes only the way how
> fast I can type is the limiting factor, for example if I write a nested
> loop.
That is not a good sign. It means your brain is idling. Think of a
2.4GHz Pentium IV processor running on AT-class 8MHz system bus. We
don't call it impressive performance.
> Programs in functional languages are much shorter for the same task
> (for example at http://tinyurl.com/aric I shrink a 30 line Java program to
> a 2 line Haskell program), but I have to think longer about a problem to
> find a good solution which can be expressed in a functional language. Is
> this the normal case for functional languages, or do I need more experience
> only?
Of course this does not necessarily mean you would be more productive
with a functional language either. If your brain is busy, it may be
because it is doing useful work, or it may be because it is bogged
down. If you are not used to functional programming, you get bogged
down. This can be cured by getting used to it.
The meaningful measure is not pages of code per second, but number of
problems solved per day.
Even if you are paid by pages of code, it does not mean you have to
write in a bloated language. Be more cunning! Build a translator
going from your favourite language to the bloated language, then use
it to churn out pages after pages!
Garry Hodgson
>
> > If I write a program in an imperative language, sometimes
> > only the way how fast I can type is the limiting factor,
> > for example if I write a nested loop.
well, you don't specify which imperative language, but
i suspect one factor may be the amount of boilerplate code
one often needs to write in many of the common imperative
languages. once you've typed:
for ( int i=0; i < len( list ); i++ )
doSomething( list[i] );
a few thousand times, your fingers get pretty good at it,
and can type it unattended while you're figuring out what
doSomething() should do.
----
Garry Hodgson, Senior Hacker, AT&T Labs
No act is more patriotic than speaking out when your government
is doing the wrong thing in your name. This is not your right
but your sacred duty. And none are more treasonous than those
who would silence these voices.
Garry Hodgson
> Frank Buss <f...@frank-buss.de> writes:
>
> > I like the special characters like "`", "|", "<-" etc., because it gives
> > your program a better structure. But you are right, everyone should avoid
> > short variable names (important for functions) and uncommented code.
>
> I don't agree. Short variable names are often fine.
>
> If you have a function working on lists in a general fashion, naming
> that list xs or (x:xs) is perfectly fine, IMHO. You could name it,
> Descriptive names are good, but short descriptive names are better.
> And with good conventions, short names can be as descriptive.
indeed, a lot depends on usage, and on the idioms of the language.
anyone seeing x:xs knows what it means; using firstItem:restOfItems
is a tedious distraction. likewise, using single letter variables in C
is not generally good, yet using "i" as you loop counter:
for ( int i=0; i<n; i++ )
is preferred to:
for ( loopCounter=0; loopCount<numberOfElements; loopCounter++ )
because it has idiomatic meaning.