Re: [extremeperl] Book: Higher Order Perl

Rob Nagler <nagler <at> bivio.biz> writes:

> Adam Turoff writes:
>> The net effect of being a purely functional language is that Haskell
>> forces you to decompose problems differently.
>
> I always thought that was the customer's job.   Seriously, is there
> any evidence that forcing programs to decompose problems the Haskell
> way is any better than the Perl way?

"A Spectacular Example" - Slide 27 in Mark-Jason Dominus' talk Strong
Typing With Perl:

       http://perl.plover.com/yak/typing/samples/slide027.html

> >
>> The Haskell approach isolates those portions of your program (into
>> Monads), that fold into its functional worldview.
>
> Since any real projects I do nowadays involves a database, I was
> curious how Haskell handled SQL, and it turns out that it "unwraps"
> it:
>
> http://www.haskell.org/hawiki/HaskellDbTutorial

The main evangelist for Haskell is about to join this list and address
this question.

> >
> Do you have experience with this?  Is it better to program this way
> than with good old SQL?

you can do that sort of programming in Haskell too.

> >
>> about your source code, the net result is that when you say "y = m * x + b"
>> the compiler has a pretty good idea of what you mean, without cluttering
>> up your code with type declarations and casting back and forth.
>
> Compiling, how quaint.   I've got a friend who programs Eiffel for
> a living.  He waits 20 mins for the compiler to work things out before
> he can run an acceptance test.  At bivio, we say (more or less):
>
>     httpd -X
>
> and even in the most complex systems, it takes just a few seconds on a
> 2.4ghz processor before I can validate the end-user semantics of my
> change.  If there is a defect, my test tells me. 

With Haskell, you can reason about the correctness of your code. With
Perl you must test. 

By testing, what you are doing is selecting certain values from a
set. But: a set of values is a Haskell type!

In a strongly typed functional language, reasoning by proof gives you
100% _certainty_ that a certain function works for all input. There is
no need to test.

When you create a test, you are basically saying that the input is
poorly specified and you hope that Perl will be able to handle the
type-checking on the fly for you, either by object-oriented delegation
or type-casting.

> Are there any studies out there that compare programming Perl vs
> Haskell to do the same job?

Here are the Perl cookbook examples done in 10 other languages
including Haskell:

          http://pleac.sourceforge.net/

--

-- 
	Carter's Compass: I know I'm on the right track when,
	   by deleting something, I'm adding functionality.