in reply to Re: Lisp vs. Perl Round 3: Operator Associativity and Manipulation
in thread Lisp vs. Perl Round 3: Operator Associativity and Manipulation

Thank you for taking the bait. First of all, your example does not support unification. I assume you know what this is and why your example does not support it. If not, read Norvig for details.

Most people do not consider the Lisp method of using Reverse Polish notation for conditionals and mathmatics particularly simple.
But would you agree that it is consistent and that one does not have to refer to a manual to know whether an operator associates to the left, to the right or not at all?

But your arguement here just shows that either you didn't bother to learn the tool (Perl) well enough to do the job right, or you intentionally misrepresented things to serve your point.
How does your example "do the job right?" Please read the title of the post. You created a telegraphed example which only supports binary infix operators. It won't work for unary ops and it will fail on more complex ops where you must know Perl prcedences rules.

And finally, the use of strings is very slow.

  • Comment on Re: Re: Lisp vs. Perl Round 3: Operator Associativity and Manipulation

Replies are listed 'Best First'.
Re: Re: Re: Lisp vs. Perl Round 3: Operator Associativity and Manipulation
by Sifmole (Chaplain) on Jun 08, 2001 at 23:54 UTC
    But would you agree that it is consistent and that one does not have to refer to a manual to know whether an operator associates to the left, to the right or not at all?

    Consistency is not the be-all end-all goal. I personally am very comfortable sacrificing some consistency for greater flexibility to write easier to read and maintain code. You however, as evident from several posts, have a bit of a fetish for it. However, as before, your claim of inconsistency wrong.
    Perl is consistent, just on a more granular level; There is an order of precedence, and it is always followed. I extremely rarely find myself refering to a manual to figure out how to put together an expression ( I say rarely, because I never say never. ).

    How does your example "do the job right?" Please read the title of the post. You created a telegraphed example which only supports binary infix operators. It won't work for unary ops and it will fail on more complex ops where you must know Perl prcedences rules.

    You example only used '+' and 'eql' so I followed suit. I only invested 5 minutes in putting it together. You show me yours and I will show you mine.

    And finally, the use of strings is very slow

    And when did Lisp become blindingly fast?

[reply]
      And when did Lisp become blindingly fast?

      Well, I'd say that Lisp, being merely a language, and thus somewhat of an abstract thing, is neither slow nor fast. For individual implementations of Lisp, one might give the rather tautalogical but nonetheless true answer that they became fast when implementers figured out how to make them fast (which incidentally doesn't relieve the programmer of his responsibility to help out, but that's another story entirely). Modern Lisp implementers have done a pretty good job of holding up their end of the bargain; good examples are CMUCL and ACL. (I myself am a user of Lispworks which isn't too shabby either.)

[reply]

In Section Meditations