http://www.perlmonks.org?node_id=995547


in reply to Re^2: Get me excited about perl
in thread Get me excited about perl

tobyink,

Okay, what's the joke?

You brought 'php' to a thread on 'Get me excited about perl'!

I can always use a good laugh...Ed

"Well done is better than well said." - Benjamin Franklin

Replies are listed 'Best First'.
Re^4: Get me excited about perl
by tobyink (Canon) on Sep 25, 2012 at 15:04 UTC

    You brought 'php' to a thread on 'Get me excited about perl'!

    Only as a reply to a post which included C, C++, Java, Python and Haskell source code.

    My point is that Perl is not unique in its ability to provide concise solutions to text processing problems. The PHP solution is a little longer, sure, but is arguably more readable than the Perl one (to somebody who knows both languages) due to not needing to rely on idioms like the Eskimo kiss operator.

    perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'
      as a reply to a post which included C, C++, Java, Python and Haskell source code.

      A belated post to the thread caused me to look back at it, I found this which I missed before, and would like to respond.

      I didn't offer PHP because I've never used it. I have used all of the languages I posted samples of. (Albeit that my "use" of Haskell has been quite limited.)

      Whilst I might have found equivalent examples on-line; I would not have been able to judge a good example from a bad.

      My point is that Perl is not unique in its ability to provide concise solutions to text processing problems.

      I don't think I claimed it was "unique".

      The PHP solution is a little longer,

      Actually, quite a lot longer.

      but is arguably more readable

      One-liners aren't meant to be readable. (No one is going to be code reviewing my console history:)

      Just as a carpenter doesn't use a dovetail joints for shuttering; I don't waste time and effort for one-off tasks.

      not needing to rely on idioms

      I don't "need to rely" on idioms; I choose to make use of idioms.

      Have you ever watched a professional cook peel & slice or dice an onion? The skin is removed in one or two seconds; the slice and dice is done with a stupifyingly fast knife action. Contrast that to a beginner performing the same task.

      In the isolation of a TV cookery program or demo, the professional's actions may be seen as a 'neat trick'; or 'a bit of flash'. But in the context of the professional kitchen where onions are prepared in quantities measured in 10 kilo sacks; the speed is a necessity.

      Likewise, it behooves the professional programmer to learn and use the idioms of his chosen language.

      And the more of the idioms you master, the more often you'll see the one-line solution to what might otherwise be a week long programming task.


      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

      RIP Neil Armstrong

      tobyink,

        Only as a reply to a post which included C, C++, Java, Python and Haskell source code.

      Now I get it :-)

      "Well done is better than well said." - Benjamin Franklin