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

Re: [extremeperl] Book: Higher Order Perl

Expand Messages
  • Adam Turoff
    ... The net effect of being a purely functional language is that Haskell forces you to decompose problems differently. For example, in any other programming
    Message 1 of 58 , Mar 28, 2005
    • 0 Attachment
      On Sat, 26 Mar 2005 17:31:53 -0700, Rob Nagler <nagler@...> wrote:
      > Terrence Brannon writes:
      > > 2/ you can use a truly pure functional language
      > > 3/ you can get strong typing
      >
      > What do strong typing and purity add?

      The net effect of being a purely functional language is that Haskell
      forces you to decompose problems differently. For example, in any other
      programming language (including Lisp et. al.), you can punt and start
      writing imperative code at any point. Staying purely functional has the
      advantage that you naturally code more modularly, and in a bottom-up
      fashion.

      Of course, there are some things that must be done imperatively, like
      I/O. The Haskell approach isolates those portions of your program (into
      Monads), that fold into its functional worldview. As a result, you can
      run your original program as-is, or you can run your augmented program
      that does logging. Or, you can switch out your logging monad to, say,
      do write-ahead logging. Or incorporate both at once.

      BAM! Instant AOP. With none of the "pointcut" nonsense. ;-)

      The strong typing allows the compiler to do more advanced reasoning
      about your program. While the literature talks about proving theorems
      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. And if
      you add new types that respect the rules around "+" and "*", your new
      types can use the same functions already defined in terms of those
      operations. Ditto boolean comparisons.


      That's not to say that Haskell is the ultimate language. It does have
      its fair share of quirks and flaws. But as Paul Graham would say, it's
      closer to the trunk of the tree. If you're going to spend time learning
      a new language this year, Haskell is better than, say, FORTRAN. ;-)

      -- Adam
    • Tom Vilot
      ... Wait. That sounds like Rob .... ;c) (kidding) ... Wait. That *also* sounds like Rob ... ... (not kidding!)
      Message 58 of 58 , Apr 8, 2005
      • 0 Attachment
        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 ...

        :c)

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