Re: Some exciting new trends in concurrency and software design

[Phil Clayton <phil.clayton@lineone.net>]

On Jun 21, 10:36 am, steveh44 <steve_...@yahoo.com> wrote:
>
> FP seems to be good for short programs.

I find most languages are good for small programs.  (Maybe that was
your point! :)

The fundamental property of pure functional programming - no
destructive assignment, i.e. all value-based - is good for large
programs.  You know that the value of data is determined only by
certain points in your program.  You could could achieve a similar
effect in Ada by "programming with expressions" though Ada wasn't
designed for that and would be more limited.  This is particularly
suitable for data transformation algorithms.  I readily admit that
this makes FP fundamentally less suitable for certain classes of
algorithm.  However, if you do put the effort in to keep programs
purely functional, the above property means that it would be much
easier to introduce concurrency.

A big issue with FP is the complexity of the compliers/interpreters.
Predicting what happens at run-time is difficult.  Even with Ada (or C
etc.), imagine writing a program as an enormous expression by using
only functions - how deep does the stack go?


> But try to
> build a large software system with it, and things
> start falling apart quickly.

I'm not sure what you mean by "falling apart".  FP languages usually
have module systems that support large-scale software.  In my
experience there is one area where FP can quickly fall apart for large
systems: efficiency.  In practice, there are a handful of things to
know and most problems will be avoided.  Even so, timing regression
tests are important.

Phil