Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

Re: A Melancholy Monkday

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


in reply to A Melancholy Monkday

It saddens me too.

It also saddens me that large parts of the community are still in denial about the downwards trend. Yes, I know that the TIOBE methodology sucks (I've said so myself), but business people still make decisions based on those numbers.

Moreover there are other, less contestable comparative metrics by which Perl is losing, like module count and job counts (yes, that's from 2008, I know; but newer comparisons I've seen but don't remember the URLs of right now mostly confirm the trend). Also, github has numbers that place Perl at no. 12, which is disturbingly close to what TIOBE says.

Some people use the argument that goes like this: those comparisons are relative, and the programming language "game" is not zero-sum. The total number of programmers is increasing, so even if Perl is losing in terms of relative numbers, it is (or might be) gaining in terms of total numbers. That argument is somewhat correct (and again, I've used it myself in the past), but I still think that it is a rather weak argument for defending the status quo.

Maybe I'm hanging out with the wrong Perl 5 people, but many parts of the Perl 5 community don't feel all that vibrant, and when I try to answer a Perl question with code that is far from best practises, I try to search for a tutorial that explains how to do it better (use strict; use warnings; use DBI placeholders; use lexical file handles etc.) and most of the results that come up are crap (outdated, or don't get the essential points across). Finding Perl programmers for $work is very hard, and so on.

Even if you ("you" meaning the casual reader, not the OP here) are not convinced, please ask yourself one question: If we want to improve things, what's the best starting point? Admitting that there might be a problem, or insisting that everything is fine?

Assuming for a moment that you are with me, and not with the denial camp, the next step is asking "why?".

I think there are several reasons. One is that Perl isn't new and shiny anymore. Sadly there's not much we can change here.

Another reason is that there has been a lack of killer applications written in Perl in the past year, or people simply don't talk about that stuff is written in Perl. I have hopes that http://www.builtinperl.com/ changes the publicity situation a bit for the better, and personally I'm excited about Duck Duck Go and the Lacuna Expanse.

But there is a very important reason that is easy to overlook if, like me, you love Perl: There are parts of the language that are plain crap. Not having subroutine signatures is plainly embarrassing. Having to bless objects yourself is embarrassing. The fact that say reverse 'foo' doesn't reverse the string (even though reverse is the recommended way to reverse a string) is just wrong. There are lots of other WTFs in the language that I won't go into; that's a topic for a different Meditation, if there is sufficient interest. But any experienced Perl programmer has come across a lot of them.

Perl people often react with denial to these problems as well. The standard response is "But we have Moose" or $WhateverCoolModule. Well, Modules are a great tool for tasks like speaking HTTP, but to be an accepted patch for a missing language feature, it needs to be very widely adopted. Moose probably comes closest to that in the OO world, but when you take a look at the three big web frameworks, you'll see that only Catalyst uses it (and some of the core contributors regret it), Dancer doesn't, and Mojolicious uses its own OO implementation.

The situation is even worse in the realm of subroutine signatures; there's a myriad of modules out there, most of them using source filters (and yes, Devel::Declare still shares the downsides of source filters), most of them force you to write a different keyword than sub (which trips up any static analyzers, linters etc.) and none of them seems to be a clear winner.

So, we need evolution and/or revolution. In the core, not just in modules. Since I invest my free time in revolution, it is not my place to comment on how evolution should be done. I just observe that it's vital.

All other efforts depend on that, in the end; writing good tutorials depends on having a consistent, understandable thing to explain. Having fun using the language depends on not having to re-implement OO (or relearning the currently hip OO module), and so on.

And all efforts depend on admitting that there's something wrong in the first place. Thank you, starX, for brining up the topic, even if it's an unpleasant one.

Replies are listed 'Best First'.
Re^2: A Melancholy Monkday
by BrowserUk (Patriarch) on Jan 19, 2014 at 15:32 UTC
    The fact that say reverse 'foo' doesn't reverse the string (even though reverse is the recommended way to reverse a string) is just wrong.

    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.

    Instead of celebrating Perl's unique characteristics; explaining their utility and exploring their merits; highlighting and contrasting the effective productivity that results from having a language and language constructs that favour the concise and simple construction of algorithms for the common cases over the theoretical niceties of full orthogonality; the Perl community has become apologist for not being like every other language -- verbose, laborious and painstaking in putting the desires of the grammar theorists over and above the requirements for code development and the needs of the developers.

    The pedants and purists have done far more damage to the prospects of Perl, than all of the discontinuities they perceive, put together.

    If language is defined as a means of capturing and communicating complex ideas; then there is simply no need for a language -- computer or otherwise -- to comply with, nor be constrained by, any grammatically perfect set of definitions or rules.

    Take any natural language. They all have their anomalies and discontinuities. They have homographs, and homophones, and heteronyms, and heterographs, and synonyms, and polysemes. They have ambiguities and contextualities and disorthoganalities. They are flexible and fluid and living, evolving entities. Indeed, it is the anomalies of natural languages that we human beings most delight in and celebrate.

    When was the last time you saw one of those verbose and tortuous amalgamations, of boiler-plate phrases with prescribed meanings, studiously devoid of proscribed constructs, so beloved of the law-making and law-enforcing professions; win awards or plaudits for its construction?

    In fact, it is exactly the opposite of those that we celebrate. Poetry and prose in all its diverse forms would be almost non-existent if it all had to comply with some set -- whichever set, assuming you could get agreement on a single set -- of formally defined rules of grammar.

    What I see over the last 10 years is that instead of explaining, justifying, and indeed, celebrating that we use a language that favours capturing the semantic needs of the common case, with concise and efficient syntax; we've become collectively apologetic for the disorthoganalities that arise from the pragmatic favouring of utility and practicality, over academic nicety and theoretical purity.

    Perl5 has its great strengths -- born of its unique qualities not despite them. And the way to reinvigorate Perl as a language and development environment is to embrace those strengths not deny them. To explain, teach and laud those unique qualities; and to build upon them whilst staying true to the original design philosophy of the language.

    (*Absolute versus relative).

    As the number of programmers grows -- especially through the creation of entirely new markets for software; eg. mobile/tablet/SmartTV/SmartDash apps -- the relative proportion of Perl programmers has fallen due to there being no viable Perl presence -- nor possibility for it -- in those market places. That's further weakened by the near absence of Perl in the cloud market place; mostly due to Google preferring Python to Perl.

    I perceive that there is also a fall-off in the absolute number of Perl programmers. In part this is due to there having been some proportion of people using Perl that came to it because it was the in-thing at the time. They've since migrated away to RoR or PHP; then Objective-C or Java; and will shortly be looking to GO or Dart or whatever else they think will make up for their inabilities as programmers.

    In part it is because Perl(5) reached a point where it was due for an upgrade; but despite the coming and going of many Christmases, that upgrade has never arrived. The result is that Perl5 first stagnated; then started a phase of trying to evolve through a) prosthetics: the rapid adoption of ill-designed and badly integrated stick-ons; and b) comb-overs, wigs and plastic surgery: cosmetic makeovers designed to flatter and conceal rather than modify the underlying nature of the beast.

    Like sticking a side-car on a motor bike and calling it a car; or wrapping over a 40 year-old veedub chassis in a plastic facsimile of a GT40 and calling it a race car; both forms of 'evolution' are transparent failures.


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

        ... 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.
        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.
Re^2: A Melancholy Monkday
by hippo (Bishop) on Jan 19, 2014 at 12:33 UTC
    Not having subroutine signatures is plainly embarrassing.

    Strangely enough, I've been programming in a variety of languages for over 30 years and this is the first time that I can remember coming across the term "subroutine signatures". But since moritz thinks they're crucially important it seemed only fair to find out what they are.

    So, off I go to my default search engine and ask it about subroutine signatures. It turns out that they are just interfaces - essentially what would be described by a well-functioning prototype system. Presumably this precise term is used in some other branch of English which is why I haven't come across it before today.

    However, the pertinent thing is that of the first 10 results (my arbitrary choice) returned by the search engine, fully 8 are specific to Perl (and one of the others is the wikipedia entry explaining the term). I was pleased to find that contrary to the doom and gloom in this thread and that perpetuated by the devotees of other languages more generally, Perl is actually at the forefront of discussions on some computational matters.

    So let us not despair too much. For all those who would rally round and actively try to boost Perl's reputation, very good luck to you. The starting point is to my mind at least not so low as many might suggest.

Re^2: A Melancholy Monkday
by Anonymous Monk on Jan 20, 2014 at 05:38 UTC

    Its strange that you talk so much at length about Perl 5 and not mention a word about Perl 6.

    Nothing that Perl 5 can ever do will bring back those glory days. Mostly because many things that Perl 5 used to offer as USP are now available in other languages. The remaining ones don't really make that much of killer features.

    Perl 6 was supposed to fix these very problems. Due to unfixable problems plaguing Perl 5. And we haven't seen anything from the Perl 6 project that could be considered worth replacing Perl 5.

    A moment of introspection. Don't take this is as a the usual Perl 6 troll posts. But frankly speaking how much of band aid can possibly fix Perl 5.?It can keep Perl 5 alive for its existing user base. But there is no way you can compete with the newer breed of languages with routine 2 year release making small time syntax improvements.

    Perl 6 has to also take it as seriously as Perl 5 does. Stop pedantic debates on production readiness and release something what rest of the world considers production ready.

      Its strange that you talk so much at length about Perl 5 and not mention a word about Perl 6.

      I did mention it, albeit indirectly. Just look at where the "revolution" link takes you. That said, I've talked about Perl 6 here on perlmonks often enough that I assume most regulars here are familiar with stances. Or if not, it's easy for them to read my older ramblings on Perl 6.

      Perl 6 was supposed to fix these very problems. Due to unfixable problems plaguing Perl 5. And we haven't seen anything from the Perl 6 project that could be considered worth replacing Perl 5.

      Nothing from the Perl 6 project can, at the moment, be considered a worthy replacement for Perl 5 at every level. At individual levels (for example expressiveness, or concurrency (on the JVM backend at least)), Perl 6 and its current main implementation, Rakudo, are actually superior to Perl 5. There is still much work to do (much more than anybody imagined when the Perl 6 efforted started), but I'm still hopeful.

      But there is no way you can compete with the newer breed of languages with routine 2 year release making small time syntax improvements.

      ... which is why I'm invested in the Perl 6 effort. I wish more people would realize that the long term health (and I'm talking about > 5 years here) of Perl depends on Perl 6. For all its maturity, Perl 5 simply can't move fast enough to be competitive with all the rest of the languages out there.

      Stop pedantic debates on production readiness and release something what rest of the world considers production ready.

      Telling volunteers what to do is never going to work. That said, you can be assured that I spend about 98% of my Perl 6 time actually improving stuff, and only 2% responding to troll.

        I disagree that Rakudo is superior to Perl 5. It depends on the definition you use. But I would say talking in terms of usefulness, Perl 5 is definitely a far stable alternative, with documentation, and CPAN support. Rakudo is slow, feature incomplete, has no documentation and standard libraries(let alone CPAN support)

        >>There is still much work to do...but I'm still hopeful.

        This almost smells like RMS defending the GNU Hurd project. Which when applied to the Perl 6 project is really scary.

        >>Telling volunteers what to do is never going to work. That said, you can be assured that I spend about 98% of my Perl 6 time actually improving stuff

        One can argue what that stuff is, For example was MoarVM even necessary? All that effort could have rather been spent on making Rakudo feature complete. Rakudo has seen so many rewrites, so many sub projects given the history one can almost say there won't any thing worthwhile may be even 5-6 years from now.

        My worst fear is, Rakudo branching out to more backends in the near future. Stalling all feature completion efforts and instead having several other bug ridden ports for other backends

        >>2% responding to troll.

        Of course these days, any criticism of the Perl 6 project is considered trolling.

        and lastly ...

        You mentioned in your previous comment

        And all efforts depend on admitting that there's something wrong in the first place.

        I think you should read what you wrote a couple of times, seriously and ponder how much that applies to Perl 6

Log In?
Username:
Password:

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

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

    No recent polls found