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

Re: [extremeperl] Book: Higher Order Perl

Expand Messages
  • Rob Nagler
    ... 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
    Message 1 of 58 , Mar 28, 2005
      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?

      > 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"


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

      > 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. I haven't found the
      lack of type safety in Perl to be hindrance in performance or quality
      so I'd like to see some evidence that programming in a type safe
      language is any better for the customer. Are there any studies out
      there that compare programming Perl vs Haskell to do the same job?

    • Tom Vilot
      ... Wait. That sounds like Rob .... ;c) (kidding) ... Wait. That *also* sounds like Rob ... ... (not kidding!)
      Message 58 of 58 , Apr 8, 2005
        Greg C wrote:

        > Consider: projects A and B have identical goals. In project A, you
        > have free
        > rein in your choice of software and hardware tools. However, the
        > manager sets
        > arbitrary deadlines, likes to stand behind people and criticize their
        > code as
        > they type,

        Wait. That sounds like Rob ....
        ;c) (kidding)

        > On project B, the choice of langauge and hardware are made for you and
        > there's
        > only one computer per two programmers. On the other hand, the manager
        > sees his
        > people as people, negotiates requirements and schedules on a realistic
        > basis,
        > trusts his people, follows a set of best practices (be it XP or some
        > other) and
        > chases everyone out of the office at 5:30.

        Wait. That *also* sounds like Rob ...


        (not kidding!)
      Your message has been successfully submitted and would be delivered to recipients shortly.