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

The Future of Perl 5

by Laurent_R (Canon)
on Aug 18, 2018 at 13:17 UTC ( [id://1220578]=perlmeditation: print w/replies, xml ) Need Help??

Yesterday, for the last day of The Perl Conference (formerly known as YAPC) in Glasgow, Scotland, Curtis "Ovid" Poe delivered a very inspiring keynote address on the future of Perl.

Ovid's idea was to imagine where Perl 5 would stand in ten years from now.

These are some of the things Perl would have in 10 years in Ovid's vision:

As an example for the first point above, consider the following subroutine:
sub fibonacci { my $n = shift; return 1 if $n == 1 or $n == 0; return fibonacci($n-1) + fibonacci($n-2); }
This subroutine should work correctly if the subroutine is called with a positive integer, but a number of things could go wrong: what will happen if no parameter is passed to the subroutine? or if the parameter is a negative integer, say -3? or if the parameter is a positive number but not an integer, e.g. 3.14? or if the parameter is not a number but a string? (Note that there would also be a problem with a large integer, but that's a different story.)

For the above subroutine to be correct, you would need to add probably half a dozen boiler plate code lines to guard against invalid input, for example maybe something like this:

sub fibonacci { die "..." unless defined $_[0]; my $n = shift; die "..." unless is_a_number($n); # the is_a_number function is to + be defined die "..." if $n < 0; die "..." if $n != int $n; # ... }

With (non experimental) function signatures and proper typing, all you would need might just boil down to something like:

sub fibonacci (PositiveInt $n) { return 1 if $n <= 1; return fibonacci($n-1) + fibonacci($n-2); }
I think this would look quite cleaner.

I hope the video of Ovid's talk will on-line soon.

Comments are welcome.

Update (Aug 23): ovid created a new meditation explaining his views with some details here: Recap: The Future of Perl 5.

Replies are listed 'Best First'.
Re: The Future of Perl 5
by LanX (Saint) on Aug 18, 2018 at 14:22 UTC
    I saw the talk in the stream and I have to disagree that the decline stabilized at a respectable level, because the community is aging and slowly collapsing. (Sorry for being blunt)

    In my (not so humble) opinion does "Perl" need a believable long term strategy to escape it's evolutionary dead end and attract "investment".

    But I don't see a strategy I only see traditional tactics.

    The first (meta) things are to

    • Identify what "Perl" means
    • Who the target groups are
    • What (used to make) makes Perl great
    • Which market developments helped promoting Perl
    • How to adapt to environmental changes of the last 25 years
    • How to open up development for faster prototyping, evolution and competition of stable solutions

    For instance:

    • Curtis is talking about inlined functions, what's the difference to the old syntactic macro discussion?
    • Function signatures are long overdue, but why the hack do we need to wait for a fast implementation? We could start with a slow one like shown in Function::Parameters °, stabilize the API ASAP and implement the fast version afterwards?

    I know some core devs will feel insulted now (sorry!), but evolution means that obsolete features have to die.

    Sorry for not spreading "Yes, we can!" slogans, positivity is not my mentality.

    I prefer direct speech without meaning it as an insult.

    At the same time I take funded critic without being insulted.

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

    °) which has it's foundation in a "macro" mechanism!

      Function signatures are long overdue, but why the hack do we need to wait for a fast implementation? We could start with a slow one like shown in Function::Parameters °, stabilize the API ASAP and implement the fast version afterwards?
      My current intention is to have *all* of that done by the time 5.30 is released.

      Dave.

        Dave that would be great, thanks! :)

        Not sure what "*all*" means, but if it includes named arguments I'm happy already!

        Cheers Rolf
        (addicted to the Perl Programming Language :)
        Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

      Thank you, Rolf, for your valuable comments.

      IMHO, Curtis provided neither a strategy, nor tactics, but rather tried to offer a vision. He did not try to say: to get there, we need to do this and then that. He simply said: this is where we could be in ten years from now.

      Having said that, I certainly agree with you that Perl needs a believable long term strategy.

        "believable" or achievable? I heard an interesting idea late on Friday night at dinner that seemed really good.

        Please don't get me wrong I'm not criticizing Curtis.

        I'm glad he gave this talk.

        You asked where Perl 5 should be in 10 years, I tried to sketch an approach to find perspectives and ways ....

        Cheers Rolf (addicted to the Perl Programming Language :)
        Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

      I saw the talk in the stream

      Is it available after the fact? Link?

      perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
Re: The Future of Perl 5
by FreeBeerReekingMonk (Deacon) on Aug 19, 2018 at 10:53 UTC
    As a sysadmin, I have an ancient perl (on AIX, Linux has quite a modern Perl), no access to CPAN (well, at least not the modules that need to be compiled) and python is being installed on all Linux, but not on the AIX machines. Nobody can read perl at the moment (ok, a bit, but there are no perlguru's around anymore) thus I can not use modern or other extravagant syntax let alone make complex perl scripts (so instead need to write readable loops instead of using map, for example). Perl6 is not on any of the systems and deemed not production ready for some time to come, if ever.

    We still use ksh and bash and awk. So my guess is Perl goes the way of awk. Minimally installed on the system for backward compatibility, used by a few.

    Perl is a white dwarf... it still shines but not with the candor of old.

      For me the more interesting question is, why people consider ksh (or bash) more readable than Perl?

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

Re: The Future of Perl 5
by Jenda (Abbot) on Aug 19, 2018 at 00:21 UTC

    I feel like I've read something like this before. Years ago. About 18 years ago actually. Back then they wrote about "Perl", not "Perl 5", but it does sound familiar. "In ten years Perl will have this and that and for that we have to break compatibility in a few places. Only as necessary of course!"

    And then came the feature creep and ten years later we had a promise that "before Christmas for sure ..." and some years later we have something that somewhat resembles a merge of Perl, APL and Ada with Perl having the least influence named Perl 6 (with a "cute" logo and a bunch of SJWs burping about inclusivity) and a repeat of the discussion we had before that project started.

    Somewhere along the way something went terribly wrong!

    Jenda

      "In ten years Perl will have this and that and for that we have to break compatibility in a few places. Only as necessary of course!"

      Here's what he actually said in his speech announcing the current P6 project in 2000:

      "It is our belief that if Perl culture is designed right, Perl will be able to evolve into the language we need 20 years from now. It’s also our belief that only a radical rethinking of both the Perl language and its implementation can energize the community in the long run."

        He also actually said:

        Now, this is not going to happen quickly. We expect to have alpha code a year from now, or some definition of alpha. We might even ship it, but we expect it to be well-designed alpha code.

        ... and:

        Basically what we are saying at this point is if we are going to bite the bullet and require translation of Perl 5 to Perl 6, that really means that we can consider anything that still allows us to translate most scripts. Now we do not expect to be able to translate a 100 percent, but if we can translate with 95-percent accuracy 95 percent of the scripts, and 100-percent accuracy 80 percent of the scripts, then that’s getting into the ballpark....

        Either the Perl culture was not designed right or that belief was wrong then.

        And there was more than this speech back then. While it was clear from the start that total compatibility was not a goal, the resulting hodgepodge of ad hoc changes is not what was promised back then.

        Jenda
        Enoch was right!
        Enjoy the last years of Rome.

Re: The Future of Perl 5
by ajs (Novice) on Aug 19, 2018 at 14:46 UTC
    Typing sounds like a good thing. It's almost always not. Why? Because we get lost in the idea of "correctness," and so what looks like:
    sub fibonacci (PositiveInt $n) { return 1 if $n <= 1; return fibonacci($n-1) + fibonacci($n-2); }
    actually reads more like:
    sub fibonacci ($n ... # Wait, wait... hold on a second! What is this $n thing you claim # to be sending me?! Is this a thing? Is it the kind of thing that # I approve of? What about my friends? Will my friends respect # this thing? Let's ask them... Hold on, now, do I trust my # friends? Maybe not. Better take some precautions... # Time for some state management in the form of eval. That's light # weight, right? # Also, now is a good time to pre-format some error messages just # in case. Okay, I think this $n thing is up to snuff, but just in # case, I'm going to do some state management. Hold on a bit... ) { return 1 if $n <= 1; return fibonacci($n-1) + fibonacci($n-2); }
    What I'd rather see is the ability to quickly validate, completely under my control, and completely duck-typed. For example:
    sub fibonacci($n {$n >= 0 && int($n) == $n}) { return 1 if $n <= 1; return fibonacci($n-1) + fibonacci($n-2); }
    Where this expands to something more or less like:
    sub fibonacci($n) { die '$n failed check "$n >= 0 && int($n) == $n"' unless $n >= 0 && + int($n) == $n; ... }
    I have no problem with typing as a shorthand that people can use if they want, where
    sub fibonacci(PostiveInt $n) {
    is equivalent to
    sub fibonacci($n {$n = PostiveInt->new($n)}) {
    But in that case, I've opted in to a potentially very expensive type construction from my potentially very simple value.
      I love any efforts to advance Perl and all involved but Ovid does this charming and polite self-deprecating thing I see a lot online in the language wars that seems contradictory and counter productive in terms of rhetoric and mindset.

      Perl is criticized for being too verbose and hard to read.

      Perl is then compared to some other less potent language with no sigils or lexical variables or lots of other cool features that require traditional language concepts such as punctuation.

      Perl is then berated for being longer and more complex than the perl-for-idiots reinvented-wheel that has been completely golfed, making it easier to read for an expert, but potentially much harder to understand in practice--due to increased cognitive load of having to keep all the missing punctuation in your head so the language can appear to be "pretty" like makeup or plastic surgery for your brain!

      Almost every common criticism of Perl can be turned around and touted as the feature it actually is.

      Run this 3 point program to turn this thing around, in your head, and in reality:
      1. Perl's verbosity, and lack thereof, enhances understandability. 2. Perl sigils are the best invention since rn and patch; Because they are so meaningful and context dependent; Beautiful symbols everyone knows and loves: $, @, %. 3. Perl 5 is PERFECT (but there's always room for improvement)!
Re: The Future of Perl 5
by bliako (Monsignor) on Aug 23, 2018 at 01:39 UTC

    There is a lot going on around us in the computing world besides serving webpages. Today I was looking for some open source software to train with and classify images. Most people pointed to Tensorflow. Which is written in C++ but all examples and usage are on python (liaks). "Why is that?" many people asked on forums far and wide. We have the ultimate tool written in C++ but do we need to command it via py***? That's right. You write your model in @&*£?*! and it is executed by calling C++ functions or perhaps execs. Most data manipulation is done within these C++ calls. For example you have a training dataset of a million 20-vectors. You want to train a classifier with it and also test it. In @&*£?*! call train_and_test(mydataset,80,20) which takes your data, splits it 80/20%, the first for training the rest for testing and returns back assessment statistics and the classifier weights. So, just a glorified glue.

    Here is a bright future for Perl: a glue for ML apps. Can it do it?

    Yes, it can be done with Perl. <boast mode on>I have done it, training an assembly of hundreds of neural networks. But I did not do RPC or inline function calls. Just calling executables for data manipulation (e.g. split a dataset in train/test cases randomly etc.) or neural network training.

    So, why is @&*£?*! out there driving a Mercedes Benz and Perl is shtack at serving webpages?

    I started researching and found out that's my lovely Perl is stuck in the past in regards to ML support and there's no any recent developments in this area (like full last decade).
    
    Now look at Python! Tensorflow, MXNet, Keras, Theano, Caffe, and many, many more. Java has it's deeplearning4j, Lua has Torch and what had Perl ? 
    

    by Sergey Kolychev, from http://blogs.perl.org/users/sergey_kolychev/2017/02/machine-learning-in-perl.html

    I will dare a sacrilegious over-statement and say that it does not matter whether there are function protos or automatic parameter checking in Perl. Although this are great enhancements. But maybe (and in my opinion) the real future lies in being out there along with these big ML efforts providing the glue and improving Perl (along the lines of function prototyping and other things) on the way.

    Digression: I am not saying that what ML is out there by these big corporates is set on stone or is The ML. It is not. It is old stuff we ruminate on because we can afford it with our brand new teeth and that brute-forcing brings results soon to stall, again. I am just waiting around the corner, pie in hand, for that new Minsky and his risky predictions.

    So, how can this be achieved?

    More ML training and demos in meditations and, please, more ML posts in the Monastery.

    That @&*£?*! really does not deserve all that attention. Help liberate that hardware running @&*£?*!

    Sure, let all flowers blossom and black cat white cat what does it matter as long as it catches mice. But there are also aesthetics and power consumption.

    bw, bliako

      I will continue on the ML point and rhetorically ask if Bioperl (bioperl home here) was a good project, what its state is today and why.

      I say that it was a great project with a lot of effort put by hardened hackers in dealing with frivolus, newbie-like-carelessness-approaching-criminality, narcissistic, life-science rectors' mess quite effectively: they created lots and lots of databases and sites to scrape, different formats, and a lot of overlapping or contradicting naming conventions. Bioperl did a good job at trying to work in this mess.

      Now, where is all that effort and effect put in Bioperl gone? Newcomers to bio-informatics, e.g. graduate students, prefer R which does an excellent job with Statistics but it is not R's forte to scrape, download, parse / regex / string manipulation/comparison etc. Something that it was and is Perl's niche. (Notice that most bio-questions asked here have to do with huge string comparisons, the genes). When they find R usage beyond the basics impenetrable to fathom (which is quite true) they (instinctively?) turn to python. Probably because it is the only thing they know from University or from gloglo. And that needs to be fixed in order for Perl to gain the popularity it deserves.

      On the other hand, and semi-jokingly, I would say Perl's future's woes are nothing compared to Latex's which is a super-duper typesetting system which so many of these people (doing Nature publications, working at Nasa, talking to BBC on Science subjects) snob for the sake of an idiotic, substandard, buggy and most of all a sworn enemy to aesthetics and scholar-ship: word (<-- this is a lower case word btw, i am not pin-pointing something else).

      Marketing is number one I am afraid (i say and excuse my cynicism, some more's coming...). Sponsoring these big heads with material things is key in order to indoctrinate their students and point them towards Perl - look how a book is adopted for a course in most universities and how that makes the author rich and famous in a day.

      On the good side, on a recent trip to a remote place where Capitalism is still controlled by strong State (not far east), a student there told me that their professor banned them using python.

        I agree with a lot of your points. My point about Perl is that there are not enough apps. Python has continued to add medical space stuff. Perl has the UMLS stuff and BioPerl but the former is difficult to install, takes up a lot of disk, and requires external licensing steps and the latter was, the last time I looked in semi-functional disarray as, like you mentioned, it's a hodgepodge to account for hodgepodges. I despise Word but LaTeX is terribly hard to use if your project doesn’t conform exactly to an existing package and a non-programmer would have almost zero chance of getting a project done with it in such case. I don’t think we need indoctrination. We need good, easy to use, tools. When programmers have a problem to solve they reach for the most feature complete, robust, and dev friendly tool.

        Pretty sure that Glasgow University still teach a class on Perl for Bioinformatics.

      Today I was looking for some open source software to train with and classify images. Most people pointed to Tensorflow. Which is written in C++ but all examples and usage are on python (liaks). "Why is that?" many people asked on forums far and wide.

      From www.tensorflow.org/extend/language_bindings :

      "Python was the first client language supported by TensorFlow and currently supports the most features. More and more of that functionality is being moved into the core of TensorFlow (implemented in C++) and exposed via a C API. Client languages should use the language's foreign function interface (FFI) to call into this C API to provide TensorFlow functionality."

      From FFI::Platypus :

      "Platypus is a library for creating interfaces to machine code libraries written in languages like C, C++, Fortran, Rust, Pascal. Essentially anything that gets compiled into machine code. This implementation uses libffi to accomplish this task. libffi is battle tested by a number of other scripting and virtual machine languages, such as Python and Ruby to serve a similar role. There are a number of reasons why you might want to write an extension with Platypus instead of XS:"

      Go ahead, change the world...

Re: The Future of Perl 5
by TheloniusMonk (Sexton) on Aug 22, 2018 at 11:57 UTC
    My guess is there will be a Perl 7 designed to compete with other languages, the same way Fortran and COBOL got upgrades to introduce block structuring features. But 7 because it needs to read perl5 by default, needs a 'use Perl6' to process a block of perl6 code and 'use Perl7' to be free to do what it likes.

    Update: Given that Postgres at No. 4 database is growing in popularity at 50% pa with the top 3 declining, it is worth considering that functions in Postgres can only be written in four procedural languages: pgSQL, Tcl, Perl and Python, with also the ability to write functions in C. Note also that the scripts pg_load and pg_restore plus a bunch of others including for starting and stopping the cluster are all written in Perl. Perl is also just about the sanest language for the majority of devops work. Perl is also still the main language for some of the world's most successful and complex websites.

Re: The Future of Perl 5
by Anonymous Monk on Aug 19, 2018 at 14:16 UTC
      Ovid in talk complains perlobj doesnt link perlreftut .... Well :)

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://1220578]
Front-paged by Athanasius
help
Chatterbox?
and the web crawler heard nothing...

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

    No recent polls found