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

Re: [extremeperl] Book: Higher Order Perl

Expand Messages
  • Adam Turoff
    ... And the authors of the paper leave the impression that extrapolation from any one data point is worse than meaningless in this analysis. ... I would argue
    Message 1 of 58 , Mar 29, 2005
    • 0 Attachment
      On Tue, 29 Mar 2005 12:47:28 -0700, Rob Nagler <nagler@...> wrote:
      > Adam Turoff writes:
      > > http://www.cs.pdx.edu/~apt/cs457_2003/hudak-jones.pdf
      > >
      > > There are similar anecdotal results from programming competitions over
      > > the last few years. But again, no direct comparisons to Perl.
      >
      > But the Relational Lisp took 3 hours to write, and Haskell took 8.

      And the authors of the paper leave the impression that extrapolation
      from any one data point is worse than meaningless in this analysis.

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

      Doesn't sound much like Perl to me. Saying that this language
      is "more like Perl than Haskell" is essentially saying that iguanas
      are more like Camels than snakes because they iguanas have legs.
      (Let's forget that iguanas and snakes are both reptiles, and a camel
      is a horse designed by committee...)

      > > > I haven't found the
      > > > lack of type safety in Perl to be hindrance in performance or quality
      > > > so I'd like to see some evidence that programming in a type safe
      > > > language is any better for the customer. Are there any studies out
      > > > there that compare programming Perl vs Haskell to do the same job?
      > >
      > > Um, that's quite a non-sequitur.
      >
      > Not imo. The purpose of programming is to produce code for people to
      > use. Well, at least that's my conclusion. The goal of learning a new
      > programming language is to teach you something to help the customer.

      That's one goal. Not necessarily the only goal.

      Here are some other goals for learning a new language:
      - adopt new tools and new ways of thinking
      - stay fresh
      - become a better programmer
      - learn how to say more with less code
      - become more productive

      ...all of which indirectly helps your customers over time. (Which is
      why the Pragmatic Programmers recommend learning a new language
      every year.)

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

      > Here's a bold statement: you don't really need to learn a new
      > programming language, if you know Perl. Perl allows you to think like
      > you would in Haskell, C, Java, Lisp, etc.

      Here's a bolder statement:

      A programmer who hasn't been exposed to all four of the
      imperative, functional, objective, and logical programming
      styles has one or more conceptual blindspots. It's like knowing
      how to boil but not fry. Programming is not a skill one develops
      in five easy lessons.

      Tom Christiansen, by way of http://use.perl.org/~ziggy/journal/23101

      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.

      > You do need to learn all
      > that Perl offers, and that's where HOP fits in.

      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.

      > At the same time, I contend that the natural consequence of extreme
      > programming is higher-order programming. That is, if you truly buy
      > into XP, you'll find that your code is more compact and therefore
      > higher-order. You'll learn to program functionally, imperatively,
      > declaratively, object-orientedly :-), etc. when the paradigm fits the
      > problem.

      XP + compact code != "higher order programming". 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.

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