Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

Re^3: A Melancholy Monkday

by moritz (Cardinal)
on Jan 19, 2014 at 19:03 UTC ( [id://1071207]=note: print w/replies, xml ) Need Help??


in reply to Re^2: A Melancholy Monkday
in thread A Melancholy Monkday

IMO the fact that you consider context to be a flaw rather than a strength is indicative of the reason why Perl5 has seen a decline in absolute popularity(*) over the past 10 years.

I do not think that context is a flaw in Perl 5. I believe that reverse's context dependence in particular a flaw.

Perl's usual approach is to have different operators for different functionalities. + for numeric additions, . for concatenating strings. lt for string comparisons, < for numeric comparison. But reverse for list reversal and reverse for string reversal clearly breaks that pattern. Instead of coming up with a different name for one of the operations, it abuses context, even though it's perfectly reasonably to want to reverse a string and use it in list context.

Context is well and good, as long as we stick to the principles. reverse doesn't, and that surprises newbies regularly and seasoned perl programmers occasionally.

The same could be said the x operator (which does different operations based on the argument syntax, not based on name or context) or the bitwise operators.

Replies are listed 'Best First'.
Re^4: A Melancholy Monkday
by BrowserUk (Patriarch) on Jan 19, 2014 at 20:46 UTC
    ... it abuses context ...

    It uses, not abuses it.

    ... even though it's perfectly reasonably to want to reverse a string and use it in list context.

    Perfectly reasonable; and perfectly doable, and perfectly simple:

    print scalar reverse 'this and that';; taht dna siht

    It is also perfectly reasonable (and simple) to want to reverse a list;

    print reverse 'this', 'and', 'that';; that and this

    (I know you know that but ... see below.)

    In both cases, 'reverse' is the proper description of the process, so which operation would you invent some other term for? And what would that term be? (And why would you do that when it isn't necessary?)

    The problem here is simply one of education. Once you understand the concept of context, it becomes obvious and trivial. Maybe you, like me, made that mistake once or twice when you started Perl; but now it doesn't even cause me pause for thought. Why do you think that others won't 'get it' just as quickly?

    Ditto for the other things you cite. It's just a matter of education.

    For me, the rot set in with the publication of PBP. Behavioural modification through proscription has always been a slippery slope to a hiding to nothing. It is not that (some of) the justifictions for the guidelines weren't good reasons for paying close attention to the constructs proscribed. Just totally naiveté that the guidelines would not be seen as rules by some; and be used as rod with which to beat Perl by those an ax to grind or lacking the wit to understand the whys and benefits. It was all so predictable. (And predicted!)

    We could argue forever about whether backtofront() or maybe juxtapose() or some other word could have been chosen for one of (which?) those two reverse operations; but that is to try to rewrite history. Too little; too late. (And IMO, completely unjustifiable.)

    Besides, Perl6 that you promote, works hard (via both class-based namespaces and multi-methods) to permit the re-use of operation names (methods) explicitly to avoid the old-style need to invent unique names for similar operations being applied to different datatypes.

    I'm not sure exactly when reverse made it into the language, but it has been there for a very long time, and far too long to consider 'correcting it' now. Doing so now would not spark a revival in Perl(5)s fortunes, so it is a pointless discussion.

    What might help would be a good exploration and discussion on the benefits of context. Along with same of the many other widely misunderstood unique elements of Perl. Open discussion, examination and education of the merits and strengths that come from multi-paradigm programming languages rather than trying to hide those differences under a thin veneer of appeasing uniformity.

    For example. Perl's threading -- and in particular, its only-explicitly-shared data methodology -- has come, and continues to come under widespread misunderstanding and fire from those unfamiliar with iThreads (or perhaps, over-familiar with the implcitly shared everything of raw kernel threads in other languages).

    Their unfamiliarity leads to statements/questions like this from a recent threads thread here (and worse):

    I understand that Perl wants to emulate the threads as heavy processes.... I wonder what were the initial motivations to introduce a such exotic thread model at the first place.

    Widely misunderstood and characterised as "bad", the explicitly-shared-only memory model is gaining [con(sic)]currency. If you can bear it, read Concurrency in the D Programming Language; Chapter 13. In particular, 13.3 Look, Ma, No (Default) Sharing.

    If you want to revive Perl(5)'s fortunes we should be celebrating its unique features; explaining dis-orthogonality; and shouting about the benefits that accrue from them. Not hiding them away like we were ashamed of them.

    (Sorry for the rant. I know you are one of the good guys. I just happen to really like Perl. The real, whole, unadulterated Perl that is; not some watered down, easy to digest, apologetic subset of it.)


    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.
Re^4: A Melancholy Monkday
by flowdy (Scribe) on Feb 03, 2014 at 22:22 UTC
    I do not think that context is a flaw in Perl 5. I believe that reverse's context dependence in particular a flaw.
    The flaw is not, in my humble opinion, that it depends on context but that does both depend on its own context and suggest by its name that it reverses either a string or a list, whatever is passed. Another weird context thing is:
    scalar qw(this is a list); # returns 'list', but: scalar map { $_ } qw(this is a list); # returns 4 # map construct an anonymous array kind of thing # and an array returns the number of the contained items # in scalar context. But user-defined subroutines again: sub func { qw(this is a), shift } scalar func("foo"); # returns "foo" out of the list returned # by func subroutine
    The flaw is that the degree of context vs. valence dependence is rather arbitrary comparing different list operators and subroutines. It is like in German and some other indoeuropean languages, learners must memorize which word is of which gender.

      It is like in German and some other indoeuropean languages, learners must memorize which word is of which gender.

      Um, as someone who speeks some of those languages -- its nothing like that ; gender doesn't change a verb to a noun (and vice versa), or subject to object(sentence structure ), or emmentaler to fahrvergnügen

      The same is true in perl, if you don't grasp the basics, its all greek to you, even german

        You're right in that I should better say nouns when I mean nouns, not words.

        if you don't grasp the basics, its all greek to you

        Do you refer specifically to the map-vs.-subroutines thing I demonstrated? Then no, I wouldn't consider a basic must-know that map and other list operators(?) are array-like, subroutines however list-like in regard to what they return.

        But even as a native speaker of German (and hobby linguist) I find a pretty bucket of WTFs in its grammar, I presume I must have had a really hard time cramming its basics while in womb ;-). But it is not the topic. Just want to say that English is perfect, as well as German and any other natural language is. Programming languages are different here. They should evolve based on reason, much less on convention. The more they are based on convention and subtleties like what I exemplified, the more time the programmer must invest not in thinking and understanding the language and the machine at last logically, but in hacking by try and error. Of the former the return of investment would be a bit larger since machines are logical as well.

        I do not want to argue against Perl. It fits for people like me who like languages and I really love programing in it most time. But after all, to the novice it provokes an illusion of a machine that kind of understands him or her. The learning path from Perl to another language stricter by design is more frustrating than vice versa, I am afraid.

        To put it short: I do not explicitly recommend Perl to novices of programing because of this and if others doing so is the reason why it is not widely used (learned) any more, it is okay. I feel I am better off writing my own code in a way that as few knowledge of the downsides of the Perl language as possible is required to understand the program, and demonstrating every once in a while its upsides, e.g. the use of map in list context (edit: which also means never ever as a subroutine return value as you have limited control over which context the sub is called in). If my code arouses curiosity on Perl programing without my advocating it, well, that is worth the try.

        flowdy

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1071207]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others admiring the Monastery: (9)
As of 2024-03-28 09:45 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found