Re: Why Perl in 2020
by VinsWorldcom (Prior) on Dec 09, 2020 at 18:31 UTC
|
Well written. But some harsh words in there for the new DevOps, microservices nirvana :-) ++ anyway!
Kidding aside, I don't think it's all that bad ... although 20+ years as a network engineer, I've seen a lot of wheels re-invented and lots of the Docker, Kubernetes, microservices ecosystems re-invents a lot - like DNS and overlay networking. I'm all for change if it makes things better, but change for change's sake - I (and I think the collective "we") can do without.
I always lament the biggest advancement in network automation over the past 20 years is moving from screen-scraping Telnet with Perl to screen-scraping SSH with Python. Not that I'm down on Ansible, it provides way more than my little Perl script (better templating, more device support, etc.) but the software abstraction band-aid did not solve the underlying problem - network devices do not have a common language. Maybe the Ansible development effort would have been time better spent in pushing forward NETCONF or similar open standards for network device data model abstraction instead of interface abstraction.
Cheers.
| [reply] |
Re: Why Perl in 2020
by marto (Cardinal) on Dec 09, 2020 at 18:16 UTC
|
| [reply] |
Re: Why Perl in 2020
by Leudwinus (Scribe) on Dec 10, 2020 at 02:18 UTC
|
Hi, Alex,
That is a great writeup and really enjoyed reading it. For background, I am not a professional developer and just program as a hobby. As such, I am free to choose whatever language suits my fancy. It's funny because when I first started on this journey, I swore I would never touch Perl as it was the most inscrutable and impenetrable language I encountered. But I recently decided to give it a try and have to say I have been pleasantly surprised. In addition to what initially drew me to it a few weeks ago, I've come to appreciate a few more things about the language, none of which are new to the stalwarts who ply the halls of the Monastery:
- Similar syntax to Bash, awk, grep, sed and other tools you commonly use on the command line. While not exactly identical, I like that they share a common structure which makes it easier to move between them.
- All (of my) problems have already been solved! Because Perl has been around for so long, virtually any problem I can think of has been addressed and written about multiple times, in places such as here, Stack Overflow or in a multitude of books. You can save a lot of time by not reinventing the wheel as chances are, someone has already laid the groundwork for you. And I'm not just talking about the large number of modules available in CPAN either.
- Friendly community. As someone who is not a professional developer, I know I will get stuck on problems. The Perl community here and elsewhere has been beyond generous in helping me get past these issues. For me personally, this factor probably outweighs whateve technical merits a language brings because if I can't get help to leverage a language's strengths, I'm not going to get very far.
The one downside for me is the TIMTOWTDI philosophy of Perl. I know that many advocates espouse this a a good thing but I sometimes wish there was just one idiomatic way to do something. I routinely struggle with the paradox of choice in many aspects of my life and this is one area where I wish I wouldn't suffer the same fate. But otherwise, I am really enjoying Perl. I've even managed to amass 13 stars in this year's Advent of Code competition with what little spare time I have this time of year. And I have to say, I'm really enjoying it!
Gratias tibi ago
Leudwinus
| [reply] [d/l] [select] |
|
Discipulus Leudwini saluta, (latin greeting)
> The one downside for me is the TIMTOWTDI philosophy of Perl.
Freedom is hard. Only the pure slave has one and only one path to follow.
As you are somehow new to Perl this can be confusing, but you stated you liked the similarity to bash, awk, grep, sed and other tools you commonly use on the command line. People coming from C recognize other similarities, functional programmers find they can program with Perl in the way they like, as OO people do. For what I saw from wiser monks Perl permits any programming tecnique without complaining.
This is the malleability ait is speaking about. This is what makes, in my opinion, Perl a humanistic language: the programmer is as free as possible to choose their own way to reach their goals.
I started as you as hobby (but many years ago) and after the first shocking impact with sigils (I wrote just few html tags before: no basic, no batch, no bash) I found very comfortable with Perl exactly because it permitted me to express myself in a primitive way without complaining. Then it is up to you to change the approach, but only if you have the need. I wrote my first real module (not a mess of exported subroutines, a real module) ten years later or so. Only recently (2 years ago) I wrote a real module with a decent test suite worth to be published on CPAN.
So, as you are writing from an abbey near Augusta Trevorum, you can now meditate about aribitrium with this sentences from my homeland: liberum arbitrium est habitus animae liber sui
L*
There are no rules, there are no thumbs..
Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.
| [reply] [d/l] [select] |
|
The one downside for me is the TIMTOWTDI philosophy of Perl. I know that many advocates espouse this a a good thing but I sometimes wish there was just one idiomatic way to do something.
There is a way to force yourself, or your team, to do things in a specific way and that is to use the Perl::Critic module combined with a set of your own policies. You simply pass everything you write through Perl::Critic, during a testing phase for example, and it will list everywhere you have broken the policies. After a while, a habit develops and your code becomes very consistent first time round. Great for new team members to help familiarise them with the house style.
| [reply] |
Re: Why Perl in 2020
by Discipulus (Canon) on Dec 09, 2020 at 22:08 UTC
|
Hello ait and thanks for this meditation, I read it twice.
Just my 2cents (and if you dont already know, they are really 2cents: I'm a Perl only programmer, with minimal excursions in other languages and sadly my perl activity is no more bound to my employment).
Making things complex is part of the business. While Perl defines itself as postmodern it is really more humanistic exactly because its malleability. As you know, Perl is extremely portable and supports a wide range of complexity. As you described very well, it just run from scratch and can be used as prototype or can be extended to a full featured program, gradually. This is what fascinate me after so many years: the programmer is in the center not the language nor the business scheme.
> .. using bare metal and real people.I mean real programmers and sys admins who actually knew what they were doing to fine tune a real architecture.
This sounds so wise that clash against what I see everyday around me.
Why cars have not interchangeable engines? For the same reason everything nowadays is virtualized and the real service is beyond many layers of abstraction and complexity, or as you said, layers of shit. Complexity does not sum up: it multiplies, but do you want companies managers understand this? Good luck.
The fragmentation of the work (and of workers too) is a central point in the economy model we are living in. The future is toward specialization and we will be (or our children will be) so specialized at the point we will be unuseful. 2050 or 3020? We will be at the best feeders for machine learning programs.
I suspect the same is valid for programming languages: take a glance to what microsoft is pushing. No one is anymore able to grab the big picture and the tools they use intentionally cover the picture with fog and.. clouds.
Virtualization is handy but was the ram cast into the market to sell incredibly powered hardware and to make it economically affordable you must put everything and more there adding many layers of complexity in one single shot.
Here in Eataly students learn Python at univeristy and I had a little (money driven) excursus with it. Basically is like playing Lego studing Architecture and when it comes to do more serious things I saw them installing a gargantuelian mega framework with many dead ends installation issues and unresolved dependencies (..how much I love Perl errors!) and when you finally get it installed you merely feed data into others work hoping they manage your data correctly.
Who want the programmer freedom (and the expresiveness, quality and geniality) as the center of the discourse? We want this but not companies.
In the meanwhile we can fight our battles as Perl Community in the fields that will be crucial in the near future and I'm with you when you say that will be a stamina run. Few fields I see as critical are, as VinsWorldcom pointed, networking but I'd stress also on maintaining as more as possible the wide platform compatibility (Microsoft is ugly but is a big share of the market and sometimes our community is too choosey..), parallelization (a big thank to MCE), web (and here we are gaining positions), and unexplored lands as phones, games and robots..
> It’s time for a new dawn of The Programming Republic of Perl.
I'm with you! Even if I suspect the ongoing iron heel does not like very much the Republic part.
Good luck to Perl and to our wonderful community for the next year and next eras!
L*
There are no rules, there are no thumbs..
Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.
| [reply] [d/l] [select] |
|
Making things complex is part of the business.
Today this observation is common among almost everybody. I will add "Making useless things" ("useless" in every sense of the word), and "inventing new (consumer) needs" (invent vs discover) and "working more (stressful) hours". But why? We were told that the Free Market and especially that "Invisible Hand" will take care of itself and select the most optimum solutions for our comfort and happiness as human beings. Today it is obvious that this is pre-conditioned on profit aligning with happiness. A claim that it was so lame, in hindsight.
I have already expressed my opinion in other posts about the above and how Perl's TIMTOWTDI is a good thing, in that it allows for the exploration of solution space. I would like to see TIMTOWTDI be integral in any future political and economic system (with safeguards against "TIMTOWTDI to screw you!") as this one will either eat us or we will eat it. The Programming Republic of Perl (the ideology of this statement and also the character of the community) can be a bigger thing than just InfoTech.
bw, bliako | [reply] |
|
| [reply] |
Re: Why Perl in 2020
by Tux (Canon) on Dec 10, 2020 at 12:03 UTC
|
I wholeheartedly agree to the basis of your post: the useless unneeded adding of layers over layers over layers, which only shows that those who do so do not understand the simple things at the bottom. And they then claim that it is simpler this way. NOT!
I however do *not* agree with your sentiment on raku! Raku is a beatifull new language that has even more whipuptitude and DWIM than perl ever had. I love both, but they serve different goals.
I think they both fir the perl-way-of-thinking: just braindump your solution into the language of your choice, and it almost always works out-of-the-box. TIMTOWTDI. And that serves me fine. As long as I am not shackled by formats and style, I have proven that I am able to solve most of the problems thrown at me with either perl or raku.
I sympathise with woolfy's feelings in this.
Enjoy, Have FUN! H.Merijn
| [reply] |
|
You are correct. I clarified my post and apologized to woolfy because the term "shadow" was not meant to trash Raku at all! It was meant more as "whilst Raku remained branded as Perl 6 it cast a long shadow over Perl".
Raku could be the best language on the planet, maybe a better language than Perl will ever be, but that is not the issue here, nor the point of the post.
| [reply] |
Re: Why Perl in 2020
by pritesh_ugrankar (Monk) on Dec 10, 2020 at 17:26 UTC
|
Hi,
Fantastic article!!. Wouldn't know about the Raku Language cause I never used it. For my purpose, Perl 5 seems more than capable, and yes, when it comes to decoding UTF 16 output, nothing comes even close to it.
I just hope that Perl regains it's position, especially in the DevOps field. It's just too good a language to be relegated to sidelines or be the favourite punching bag.
Nothing against Python, but the Python lovers I've come across seem not to have a "point to make" when I calmly sit down and try to do a point by point analysis of their favourite pet peeves against Perl.
When they tell me about the "weird regex syntax", I show them how the qr and # or ## can make it not only clearer, but powerful.
When they tell me about "Function Signatures", I gently point it out that the feature was experimental and can be used, but also show them how hashrefs can be used in sub parameters/arguments.....Please note, I am not a language purist, nor a trained software developer, but Perl "Just Works" for me.
When they tell me the "line noise", I show them some scripts which are clearly readable, all thanks to the amazing authors who have shown the clear way of writing scripts.
When they say "List Comprehensions/Dictionary Comprehensions", I calmly point them to sort, map and grep.
Then I ask them if there's something like a "state" variable in Python, or how my script/comments are not bounded by tabs/spaces, or the ternary operator, or qr function, or the simplicity with which I can write a command output to a file (no sub process shenanigans), or my favourite, the UTF 16 handling, or how my and our help me with controlling the scope, or the python equivalent of use strict and use warnings or the amazingly powerful references ( I just use 10% of what references have to offer, but I'm a happy man) they do not seem to have a satisfying answer except "It's not really needed/It is too cryptic" or some similar excuse.
As a final point, I show them Strawberry Perl, how it comes pre bundled with so many modules, how easy it is to simply move from one version to the other by just pointing it to a specific perl version, and of course, how the Portable version makes "Admin Access" a non issue, they generally "get my point" and let me be.
| [reply] [d/l] [select] |
Re: Why Perl in 2020
by talexb (Chancellor) on Dec 13, 2020 at 02:05 UTC
|
For me, in my current position as a maintenance programmer, Perl is necessary in 2020 because it was used in 1995. But more to the point, I can still get my job done very quickly in Perl. I could get the same result in C, but that would negate all of the excellent code that's already available and proven -- that's Perl's secret weapon. Sure, Perl's performance isn't going to equal that of C, but the development time of Perl is tiny compared to C.
The Raku excursion is an interesting side-line -- I've tried bits of this language now and then, but I think I may be stuck using Perl 5 (or Perl 7); that's not a bad place to be right now.
Happy holidays, everyone, and please stay safe!
Alex / talexb / Toronto
Thanks PJ. We owe you so much. Groklaw -- RIP -- 2003 to 2013.
| [reply] |
Re: Why Perl in 2020
by fidodido (Sexton) on Dec 10, 2020 at 10:53 UTC
|
I am new here, but I cannot tell you how profoundly knowledgeable I find this article to be. I wish I could allocate all my daily points to this one article.
Which truly makes me wonder, why such a fantastic language, enriched with the amazing modules, paradigms and most importantly, such an amazing, knowledgeable and genuinely helpful community is looked down upon. Perception is stronger than fact I guess.
"Today’s startup world is fast paced and very dynamic. Product requirements evolve in real time with actual product usage and software needs to adapt at lighting speed. When I see companies struggling every day with even the simplest of problems, I cannot believe they are not exploiting these capabilities of Perl." This reminds me of a comment on a youtube video where the author of the said video was stating how Perl is not used much now a days. The comment was from a (what I think )prolific perl user( I think his name was daveorg or something like that), stated how Perl is still used to do huge number crunching and moving data in and out of databases at lightening speeds.
P.S.: Not sure about Perl 6 (Raku), because, I am not that smart to know the difference or appreciate the advanced features it might have over Perl 5 or any other language for that matter, nor have I ever tried it.
| [reply] |
Re: Why Perl in 2020
by jo37 (Deacon) on Dec 09, 2020 at 18:07 UTC
|
ait, you just wrote my "node of the year".
How can you read my mind?
Greetings, -jo
$gryYup$d0ylprbpriprrYpkJl2xyl~rzg??P~5lp2hyl0p$
| [reply] |
Re: Why Perl in 2020
by woolfy (Chaplain) on Dec 10, 2020 at 11:11 UTC
|
"Well first, we finally got rid of the Rakudo shadow, and Perl 7 is on it’s way. I can’t believe we didn’t see this textbook example on how to kill a good existing product: advertise the new one is coming, before it’s even born. There are so many examples in history, of organizations shooting themselves in the foot this way, it’s even stupid. And yet, we did exactly that. The way Perl 6 was managed was really destructive to our beloved language, and our community. Yet here we are. We survived, we are tired and demoralized, yes. But I truly think we can finally start to heal and oxygenate the ecosystem with the coming of Perl 7."
It is difficult for me to express how angry, disappointed, sad, mad, and enraged I am because of this paragraph. And all those people who reacted to the whole post as a supreme bit of wisdom. I guess nobody needs to wonder any more why I (and other) left the Perl community. Please be free from the shackles we from that damned language put on your ankles. Free at last, heh? Good luck with your next disaster, Perl 7.
Yes, I am angry. And I know some of you are happy to see me go. For good. Rid of my shadow. | [reply] |
|
Dear woolfy,
Even if I was never deeply involved in the Perl world I know you as a fundamental column of the community.
I never commented about perl5/6/7/camelia/raku/whatsoever because I have no knoweledge nor skills to apport something useful to the discussion. Nor I never had the time to investigate nothing but (classic) perl.
I hear my name in your:
> all those people who reacted to the whole post as a supreme bit of wisdom.
I still think the original post is a bit of wisdom and I intentionally avoided the perl5/6/7/raku/whatsoever part in my comment.
But dont you know, being around for many years, that many people think this way? In many degrees, variations and shades? Perl6 did not changed the name to Raku?
A community must be sensible and sensitive about people perceptions in all its shades and taking a common denominator to progress as community.
If you get angry for the opinion you quoted, it means the wound is still open and I'm sorry for this.
I hope the best future for all projects perl5/6/7/raku/whatsoever and I'd not cast a disaster word to no one of these pieces.
As you can imagine I'm not happy at all (and I'm sure most of us) to see you go away, nor to see you angry. Democracy, or well freedom of expression, often offers mouthful hard to swallow but get angry does not help.
L*
There are no rules, there are no thumbs..
Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.
| [reply] [d/l] |
|
Thank you for kind words. They lessen my anger, but increase my sadness. Because they made me think back to the time when I decided I had to leave the Perl-community, and later the Raku-community too. Sadness also because I do not see enough reasons to come back on that decision. I do not see the need for anybody on this forum to write so negatively about Raku.
| [reply] |
|
I truly apologize if this generated any bad sentiment. Maybe I could have used a better choice of words, but I was trying to preach a reconciliatory message here, so pls. don’t kill the messenger. The result of Perl 6 is what it is, regardless of the effort and intention. I surely am not blaming Perl 6 per se, or targeting any particular group, and much less any individuals. When I say “ management” I am referring to the marketing aspects, not the execution and/or the product as such. My point is that it should have never been advertised as Perl 6. And this started with Larry Wall himself...
You don’t start a new version of a product by advertising: well you know what, Perl 5 is hopelessly broken and I’m going to set out to do it right this time. Lots of people were quite happy with the sigils and obscure magic variables and all the other quirks of Perl 5, and felt betrayed. There was no need to start off a project by trashing your old design and alienate a big portion of your loyal followers who actually love these “features” that you are NOW calling design flaws. People may not want to admit it in public, Mr. Wall, but I personally found that very distasteful and hypocritical when you’ve been preaching almost the opposite in the past few decades (linguistic origins, write what you mean, TIMTOWTDI, etc.) So NOW we want to clean up the language and make it more “appealing” and “correct”. How do you think that made the community feel as whole? When the founder himself is almost saying: well Perl 5 was fun but it was a mistake. Let’s create a language for the “future generations”, wtf? What happened to THIS generation, where do I, the CURRENT Perl hacker fit into all this? That OBVIOUSLY alienated a lot of people from BOTH Perl 5 AND Perl 6.
And if that wasn’t enough damage, we top it off by calling it Perl 6, and then take over a decade to deliver it. Making the whole language and both communities (now weakened and divided) become the laughing stock of the Internet. Like you, a lot of people simply left, and we let Python take over the world, even in bioinformatics! THAT is shameful. Everybody is angry and sad. It’s not just you. It’s all of us. We ALL screwed up, and we ALL lost, my friend.
The post was not about trying to show off a supreme bit of wisdom. It was to finally say that it’s time to heal and it’s time for both projects to succeed in their own right. Perl 6 was never a successor of Perl 5, and that is clear to everyone now. THAT is what I meant by “shadow” and I’m sorry you took it the wrong way,
It was a mistake that it started the way it did, but I am sure that no one had bad intent, especially not Mr. Wall, and surely none of us in the mere mortal user community. But the fact of the matter is, that a starting a NEW language and calling it Perl 6, hurt everyone. And I think it’s time we allow for these two projects to heal, make peace, and move forward in their own right, and hopefully together.
| [reply] |
|
Apology accepted.
In my recollection, Perl 6 did not start with marketing. It started out of frustration because of several problems that were needed to be solved to move forward with Perl 5, and solving those problems would mean breaking backward compatibility. It started with a cup-throwing moment. With groups of people sitting around and discussing and writing down things that needed to change. It took quite some time before marketing came into it.
Looking back to those years, I still think that when more people would have joined in, helping development of Perl 6, a functioning programming language could have come into existence before Pugs was made by Audrey Tang. If more people would have joined in to for instance convert a lot of modules from Perl 5 to Perl 6, to make a grammar in Perl 6 to execute Perl 5 code, both Perl 5 and Perl 6 would have benefited greatly. Instead, many people felt betrayed, and I remember mostly from those years a lot of flame-wars and a lot of people leaving and not returning.
Marketing... I still have stickers and buttons that say "we suck at marketing". We really do. Looking back at my own efforts in marketing Perl (5|6), I wonder how that money, time and energy could have been used better. Marketing for Perl has never been an impressive thing. I doubt more marketing would have improved a lot: we needed educational materials so Perl could be taught at schools and universities, talks about Perl at big conferences, articles about Perl in important magazines, etc, and I have been at brainstorm sessions to make overviews of what needed to be done, and we just did not have enough volunteers to do these things, or money to hire people to get them done.
Most of those problems from the beginning still exist in Perl 5, and breaking backward compatibility still causes anger, as was shown with the changes in smart match by Zefram.
I still love Perl. Both Perl 5 and Raku.
| [reply] |
|
|
|
|
|
|
|
|
|
|
Good luck with your next disaster, Perl 7.
Thanks for this outburst. P6 was demonstrably bad for Perl, given that it isn't Perl. You say you left, yet here you are, spreading the bad vibes, really sounds like you moved on to more positive hangouts
| [reply] |
Re: Why Perl in 2020
by Leitz (Scribe) on Dec 11, 2020 at 16:51 UTC
|
Virtualization is very useful for application isolation. Bare metal doesn't work for most applications; the cost in hardware overhead is high and the utilization is often sub 10%. Yet the application must be isolated from other applications for security or configuration reasons. Some things run better on bare metal, but the datacenter cost can be very high for medium to large companies.
Perl is very much a write-only language for most programmers, and even many Perl programmers. If the average coder has to mentally parse several sigils, matrix that with context, and then look deep into a subroutine to see what is done with a variable, it's not a good thing for the programmer. It can be done, and I'm sure those who live and breathe deep Perl on a daily basis can mentally parse things much faster. Most of us can't do that. We can parse things in our spoken language because we have lived in it for years. Yet we still miscommunicate and misunderstand. We spend hours trying to find some way to write a test for some undocumented subroutine that's a hundred lines long and heavily interdependent with other subroutines that make no more sense than this one.
Your post makes me think you're a skilled Perl programmer. Perl is a great language that can solve a lot of issues. The more we understand why "they" are making choices we feel could be done better, the more we can help them see why Perl might be a good fit for them. You have the ability to solve a lot of problems with Perl, probably moreso than many of us.
| [reply] |
|
Perl is very much a write-only language for most programmers, and even many Perl programmers.
This argument always struck me as being plain silly. That's like saying that I write some text in German, and am later unable to read it because it is not English. Or that writing something now means misunderstanding myself in the future. Sure, every outside is a more or less gross misunderstanding of an inside, not only when it comes to e.g. giving account of one self, but that's not the point here.
If I talk with my Syrian or Turkish fellows, hearing their particular use of the german language, I can understand them and adapt to their peculiar, sometimes funny, constructs; and by talking likewise and applying sparse corrections I can gently lead them to a better understanding of the language.
Talking with speakers of the various german dialects, I can understand them (if not, I ask), but I wouldn't be able to express myself the same way without picking up not only their accent, but a plethora of other idiosyncrasities as well. And yet that's all german.
If the average coder has to mentally parse several sigils, matrix that with context, and then look deep into a subroutine to see what is done with a variable, it's not a good thing for the programmer. It can be done, and I'm sure those who live and breathe deep Perl on a daily basis can mentally parse things much faster. Most of us can't do that. We can parse things in our spoken language because we have lived in it for years. Yet we still miscommunicate and misunderstand. We spend hours trying to find some way to write a test for some undocumented subroutine that's a hundred lines long and heavily interdependent with other subroutines that make no more sense than this one.
Same goes for other languages without sigils: look deep into a subroutine to see what is done with it. But if I see a bare identifier in, say, C or python, I have to look up declaration and typedef: is it a char *, a dictionary, a function pointer, a struct? Sigils tell me clearly what type of variable this thingy is, and if it is a reference, the deref, its usage, tells me what's inside.
Complex things are complex, in any poorly written program in any language you can find yourself struggling with an undocumented subroutine that's a hundred lines long and heavily interdependent - that's not a perl feature. Yet perl is immensely more parseable than other languages whithout sigils - because of the sigils!
There are people which can read a page of C code at a glance and understand what happens - I can't for lack of training, but surely can do with perl code.
perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
| [reply] |
Re: Why Perl in 2020
by betmatt (Scribe) on Jan 04, 2021 at 19:09 UTC
|
From your position I think that your sentiment is correct. A nicely written article. Artisan programmers will surely however only ever make a proportion of the programming work.
I have spent quite a lot of time looking at Python. When I look at Python code I miss Perl's syntax. However I do appreciate the requirements to conformity. The usual problem with programming to 'your own style' is that a lot of the time it is extremely dificult for others to understand 'the code'. That is great if we want to explore the world of possibilities. It does however make Perl a hard sell. This is not just because of academia. It really comes down to the requirements of industry.
When it comes to Raku. I've seen a talk at a Perl conference on this language. Having studied Python I can safely say that Raku looks like a beautiful language. I do believe that Raku and Perl 7 will at some point combine. The reasons. Well. Cloud based computing will necessitate object orientation of Python fame. Raku will offer that. Multicore processors will demand functional programming of the quality of Haskell. Raku will offer that.
I do think that if Perl 5 or 7 works well for you, then carry on using it. Unless you want to do something like AI then keep going with Perl. The reason: People overuse Object Orientation (OO) in my opinion. In such case, your point on migrating from Procedural to OO then becomes valid. Remember this. For Python, if you know and understand OO, then OO is fine. People get tied up in knots with OO because they don't fully understand the theory.
One of the reasons I originally went with Perl was because I didn't think that Java had the right syntax for OO. Python has gone a long way towards fixing that in my view. I think that Raku will learn from Python.
Given all of that I predict that Perl will comeback at some point and take Python's crown.
| [reply] |
|
"I do believe that Raku and Perl 7 will at some point combine."
No. Way. In. Hell. We've got 20 years of nonsense trying to separate the two. There is no way they will ever converge.
"People overuse Object Orientation (OO) in my opinion."
Would you mind sharing what your opinion actually is? I've got 54 (I think) CPAN distributions, and I'll bet less than 10% are non-OO. Most software in other languages I write in are OO as well. Typically, if I'm not writing low-level hardware interface software in C, I like OO (for the most part). What in your mind defines when OO is being overused?
"For Python, if you know and understand OO, then OO is fine."
Python, in-and-of itself, inherently is OO, right to its core. Whether you know and understand OO is irrelevant, because if you're using Python, you are by default using OO even if you don't want to ;)
| [reply] |
|
Python, in-and-of itself, inherently is OO, right to its core
Really? Care to elaborate?
Note that Matz invented Ruby because he disapproved of Python's OO, as indicated here:
I was talking with my colleague about the possibility of an object-oriented scripting language. I knew Perl (Perl4, not Perl5), but I didn't like it really, because it had the smell of a toy language (it still has). The object-oriented language seemed very promising. I knew Python then. But I didn't like it, because I didn't think it was a true object-oriented language – OO features appeared to be add-on to the language. As a language maniac and OO fan for 15 years, I really wanted a genuine object-oriented, easy-to-use scripting language. I looked for but couldn't find one. So I decided to make it.
Matsumoto describes the design of Ruby as being like a simple Lisp language at its core, with an object system like that of Smalltalk, blocks inspired by higher-order functions, and practical utility like that of Perl.
See also: old stack overflow discussion of Python OO
| [reply] |
|
|
|
|