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

Re: [extremeperl] Book: Higher Order Perl

Expand Messages
  • Rob Nagler
    ... The relational word is a distraction. Here are what I think the important commonalities between Lisp and Perl: eval, closures, hashes, lists,
    Message 1 of 58 , Mar 29, 2005
    View Source
    • 0 Attachment
      Adam Turoff writes:
      > > I would argue that Perl is a lot more like Relational Lisp than
      > > Haskell.
      >
      > I would argue that you don't know what you're talking about. Here's
      > the description of Relational Lisp from the paper:
      >
      > Relational Lisp, a language developed at ISI, is essentially Lisp
      > enhanced with notions "relational abstraction:" a database-like
      > facility having a logic-programming feel.

      The "relational" word is a distraction. Here are what I think the
      important commonalities between Lisp and Perl: eval, closures, hashes,
      lists, dynamically typed, first-class functions, dynamic and lexical
      scoping, AGC, and complete introspection. One important feature that
      Lisp has that Perl doesn't is defmacro.

      > - adopt new tools and new ways of thinking

      I do agree that a language "teaches you what not to want". However,
      my claim is that that since invention of Lisp and (possibly) Simula,
      there has been no major advancements in programming. What do I have
      to learn from Haskell that I can't learn by refactoring Perl code and
      reading Perl resources?

      > - stay fresh

      Fresh is defined by popular sentiment, and has little to do with
      programming skills. I thought I was staying fresh when I was
      programming Modula-2 instead of C. Hah!

      > - become a better programmer

      Is it the language or the culture that surrounds the language? I
      claim it is the culture. We all program Perl at my office, but we
      have different backgrounds. To my right is a native Smalltalker, to
      me left is a native Autolisp-Python-Java-etc, programmer. We talk
      (and they laugh at me for spending so much time on this thread :), and
      that's how I learn.

      > - learn how to say more with less code

      That's refactoring. Show me some Perl code, and I'll let you know how
      I'd refactor it. Show someone else the same Perl code, and they'd
      give you a different refactoring. That's experience with Perl, not
      with Haskell.

      > - become more productive

      There's a huge cost to learning another language. I just added an
      interesting Perl refactoring to our Emacs Lisp, and I can tell you
      that it took me way longer to code than if Emacs had been written in
      Perl. (Stallman has a heart attack at this point. ;-) I've been
      programming Emacs Lisp on and off for over 10 years. It's a great
      tool, and it has taught me a few things. It would have been much more
      productive for me to have learned those lessons in my primary
      programming language.

      > Value judgements about strong typing, on the other hand,
      > have precisely none of those benefits.

      Value judgements about people's knowledge has no benefit either. :-) 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. The idea behind strong typing is that you let the
      compiler resolve the conflicts so people don't have to. The
      fundamental approach is flawed imo. The most productive programmers
      know how to communicate through code, to resolve conflicts by pair
      programming, and to get the most feedback from their tests.

      > Learning how to program in different paradigms by approaching
      > them with Perl-colored glasses isn't the same as learning those
      > lessons directly. Sure, you're better off than if you stick to all Java,
      > all the time, but you'll certainly have some blindspots.

      I didn't say you shouldn't read. And, I certainly never said to stick
      to Java. I said Perl was sufficient to learn all programming
      paradigms. You may have to read to learn new paradigms, but reading
      is not learning how to program a new language. Any programming book
      worth its salt will contain examples. And those examples will be
      written in a language. Knuth chose MIXL. Wirth chose Pascal.
      Plauger chose C. etc. I don't need to program MIXL to understand
      and to absorb the many lessons Knuth's books provide.

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

      > XP + compact code != "higher order programming".

      That's a hypothesis I have. Sorry for not making that clear. I
      believe that programmers reinvent HOP all the time, and that if they
      follow the XP practices, will reinvent them as a natural consequence
      more quickly than with other software methodologies.

      > This term
      > already has a very specific meaning. Please see
      >
      > http://c2.com/cgi/wiki?HigherOrderFunction
      > http://en.wikipedia.org/wiki/Higher_order_function
      >
      > These concepts map directly into Perl (since we have closures),
      > and have nothing to do with XP, and little to do with OOP.

      Again, that's my pet theory. 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.

      This may not happen on the first iteration, the second, or third, but
      somewhere down the line, you'll realize that "Three strikes and you're
      out", and it's time you figured out you need to pass a closure or
      create a little language that maps to your problem better. If you
      don't know what a closure is, well, you might ask a Perl Monk or your
      neighbor how you might eliminate said duplication.

      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.
      The reason is that Java programs are very redundant and the folks who
      wrote Jython knew that Python was a better way to express stuff. This
      put some pressure (from customers!) on the Java language designers to
      make it easier to do Pythonesque stuff in Java. Otherwise, they'd
      lose their user base to Java, just like all those awk/C/sh programmers
      who left to use Perl. Egads!

      Rob
    • Tom Vilot
      ... Wait. That sounds like Rob .... ;c) (kidding) ... Wait. That *also* sounds like Rob ... ... (not kidding!)
      Message 58 of 58 , Apr 8 9:37 AM
      View Source
      • 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.