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

173Re: [extremeperl] Book: Higher Order Perl

Expand Messages
  • Adam Turoff
    Mar 29, 2005
      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:


      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


      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_


      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:


      -- Adam
    • Show all 58 messages in this topic