Loading ...
Sorry, an error occurred while loading the content.

156Re: [extremeperl] Book: Higher Order Perl

Expand Messages
  • Terrence Brannon
    Mar 29, 2005
    • 0 Attachment
      Rob Nagler <nagler@...> 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.
    • Show all 58 messages in this topic