[Haskell-cafe] Re: Why functional programming matters

[Thomas Schilling]

On Wed, 2008-01-23 at 15:42 -0800, Don Stewart wrote:
> catamorphism:
> > On 1/23/08, Peter Hercek <phercek at gmail.com> wrote:
> > > Other things did not seem that great for me from the beginning. For
> > > example: referential transparency - just enforces what you can take care
> > > not to do yourself
> > 
> > ...if you never make mistakes, that is.
> > 
> > > (e.g. in C# you just cannot be sure some function is
> > > referentially transparent even when comment claims so - which of course
> > > sucks because programmers are not disciplined).
> > 
> > But if that's the point you're trying to make, I agree that a lot of
> > programmers seem to think they don't make mistakes, and thus might not
> > be receptive to the siren song of referential transparency :-)
> > 
> 
> Yes, we have to talk more about it making the job "faster and easier",
> than "safer". It's a particular kind of programmer that likes things to
> be safer (i.e. people on this list :), but all kinds want their job
> to be faster and easier :)

Be careful, though, this is only convincing against Java and C.  Python,
Ruby, Perl have the same argument.  Compared to those, using Haskell
might in fact be slower and harder--at least in the beginning.  This is
where Haskell's static typing enters the game and automates many of the
boring and error prone tasks, like finding all the use sites of a type
(just change it and let the compiler tell you).  If you use 'newtype'
and maybe some more advanced type checker features (MPTCs, Existentials)
you can let the type-checker work for you (cf. "Lightweight Static
Capabilities").  This is where Haskell could actually beat all those
"dynamic" languages, which otherwise seem to be much easier to pick up
for imperative programmers. 

Then there is concurrency of course ...