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

Re: [extremeperl] Book: Higher Order Perl

Expand Messages
  • chromatic
    ... Sorry, defining the word function doesn t convince me that you ll never ever accidentally mistype something and that the compiler will always reliably
    Message 1 of 58 , Mar 31, 2005
      On Thu, 2005-03-31 at 04:12 +0000, Terrence Brannon wrote:

      > > Surely you left off the disclaimer that you have defined the
      > > function correctly

      > I did but a function is a small clear statement about how input(s)
      > transform into output reliably, time after time, without fail and
      > without intermediate state.

      Sorry, defining the word "function" doesn't convince me that you'll
      never ever accidentally mistype something and that the compiler will
      always reliably and dutifully tell you about it. Don't make me quote

      > > -- or does your typechecker magically reason that a square
      > > root function that takes an integer may sometimes return an
      > > irrational number?

      > 2/ The haskell sqrt function takes a datum of typing Floating and
      > returns a datum of the same:

      No, when you implement your own square root function with Newton's
      approximations and say Int -> Int but neglect to consider the case where
      the incoming integer is negative, what does the compiler do? Does the
      magic of strong static typing in a purely-functional language extend to
      finding bugs in your misunderstanding of the expected input and bugs in
      your clear statements about how to transform input into output reliably,
      time after time?

      If so, how does it do that?

      If not, that's my point.

      Don't say "I'd never do that", because it's just an example. I could
      give you a dozen more complicated examples, but I didn't. Deal with it.

      Don't say "I don't write bugs", because I've read your code. I write
      bugs too.

      Don't say "That's why you need perfect specifications and a perfect
      understanding of the domain before you write code", because I'm a
      programmer too.

      I'm happy to talk about how compile-time type inferencing and purely
      functional programming approaches reduce the frequency of certain
      classes of bugs, but don't try to feed me a line that they prevent
      completely anything but typos without some degree of proof.

      -- c
    • 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.