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

Re: [extremeperl] Book: Higher Order Perl

Expand Messages
  • Adam Turoff
    ... Um, I think you re confusing strong typing with the type system commonly found in C, C++, Java and friends. That s *not* strong typing in any sense of the
    Message 1 of 58 , Mar 29 6:43 PM
    • 0 Attachment
      On Mar 29, 2005, at 7:20 PM, Rob Nagler wrote:
      > I don't value strong-typing. I value close relationships with other
      > programmers so that we can communicate effectively about programming.
      > Stong-typing and compiled interfaces are designed for organizations
      > with programmers who don't have close relationships and who are poor
      > communicators.

      Um, I think you're confusing strong typing with the type system commonly
      found in C, C++, Java and friends. That's *not* strong typing in any
      sense of the term if it were, this nonsense wouldn't be possible:

      double d = 3.14159;
      int i;
      i = *(int*)&d; /* ick. I need to wash my hands now... */


      Terrence brought one particularly surprising example of a benefit
      of strong typing earlier today -- an infinite loop found in the
      compiler, not at runtime:

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

      Sure you can find those bugs by running the program (and watching
      it overflow the stack), or through pair programming. But the paper
      that Shae pointed to

      http://research.microsoft.com/Users/simonpj/Papers/financial-
      contracts/contracts-icfp.htm

      describes a system to define financial contracts that are *also*
      checked for validity. Also by the compiler, without running code.
      Coincidentally, that system can also evaluate those contracts, instead
      of just modelling them.

      No, you can't do that with C's type system. No, that type system isn't
      designed for organizations dealing with programmers who don't know how
      to communicate with one another.


      Absent a strong type system that can be pushed in these directions,
      I agree with you -- the next best thing is a dynamic type system
      (like Perl's, or Smalltalk's, or ...) aided by agile development
      practices. A strong type system allows you to turn the knobs
      from 11 all the way to 20 or 30. ;-)

      >> HOP can only get you so far. There are other concepts that don't
      >> map easily to Perl, or at least seem trivial and useless until you
      >> see them used in their original context.
      >
      > Please elaborate.

      See above.

      > The last chapter of my book talks about
      > Subject Matter Oriented Programming (SMOP), which basically is the
      > theory that refactoring is the best teacher. If you truly want to
      > eliminate redundancy in imperative code, you will have to invent or to
      > learn about another paradigm.

      I haven't read your book, but this sounds like what is commonly
      known as a domain specific language (DSL). At least, that's what the
      lispers have been calling it for the last 25+ years. ;-)

      Refactoring your way into a DSL is certainly one way to do it. I'd
      argue that designing a DSL is a better way to do it.

      > It's very interesting to me that Java is getting all the stuff Perl
      > had (like closures) many years ago. Before long, it'll have eval.

      Yep. And those came from Lisp. And Perl6 is getting macros, also
      from Lisp.

      Paul Graham talks about this in _The Hundred Year Language_

      http://www.paulgraham.com/hundred.html

      In _Beating the Averages_, he talks about "The Blub Paradox", where you
      don't know what features you need from more powerful languages if you're
      stuck using a less powerful language:

      http://www.paulgraham.com/avg.html

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