in reply to Re^2: Perl oddities
in thread Perl oddities

I'll disagree. I think that this list of oddities is a perfect place to vent, to reflect on where we are, how we got here, and, just as importantly, if not moreso, where we are going. Many of these oddities seem to have been made into RFCs for perl 6 - which is why perl 6 seems to solve so many of them. But, don't worry, a year or two after perl 6 comes out, we can have this thread all over again with perl 6's own oddities, as brian_d_foy points out ;-}

(I'm not disagreeing with it "getting irritating" - that's your feelings, and you're entitled to them. Just disagreeing with the implication that this is not a nice discussion providing insights into how people think, which I think it has done, and more: whether those oddities will be addressed or not in future versions of perl.)

Replies are listed 'Best First'.
Re^4: Perl oddities
by Anonymous Monk on Mar 07, 2005 at 10:25 UTC
    Do you think that all oddities need to be fixed? A language without oddities would be extremely boring. Besides, my oddity doesn't have to be your oddity.

      To the extent that oddities get in the way of getting our collective jobs done, yes. And very few of us actually have jobs where golf or obfu is part of the requirement, which is where some of these oddities get (ab)used.

      When I'm coding, I'm not looking for a "fun" language. I'm looking for a practical language. One that does not get in the way of me finishing my current task to get on to the next task. That doesn't mean I can't enjoy the task of coding, it just means that fighting oddities is not the enjoyable part of the task: completing the task faster and more reliably than any of my teammates is the enjoyable part of the task (for me). Having the flexibility to think in the problem space rather than the solution space is enjoyable (for me). Being able to do things the way that I think they need to be done, not necessarily the way the language designer(s) thought they should be done, is enjoyable (for me). Fighting oddities is not.

      It's not even as if Perl is the only language with oddities. C has a bunch, too, many (if not most) of which Writing Solid Code tell you to avoid.

        Having the flexibility to think in the problem space rather than the solution space is enjoyable

        Yes, and this is why some oddities may even help. The fact that ' ' as first argument to split is slightly different than / / is certainly an oddity. But useful. The fact that // has a specific meaning, but not if it's used as a first argument to split, is also an oddity. But useful.

        Not every oddity is evil.