Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

Re^3: Cor—An object system for the Perl core

by perlfan (Vicar)
on Jun 01, 2020 at 18:23 UTC ( [id://11117564]=note: print w/replies, xml ) Need Help??


in reply to Re^2: Cor—An object system for the Perl core
in thread Cor—An object system for the Perl core

(moved from OOP and the Perl core per suggestion in rt)

I am not sure how these Quests work, but I will offer something to this notion. Why have all attempts to add a MOP or some sort of "object system" to Perl failed?

The answer for me is simple. The resulting attempts have, rather than created an idiomatically consistent linguistic interface to Perl, created monstrousities that have lead us away from perl. Moose and all its bastard children are perfect examples. Not only have they simply created new declarative and unrecongizable mini-languages with-in perl, but they have spurred wasted time and talent in totally separate languages with-out. Moose (and it's elk), Perl 6/Rakudo/Pugs/Parrot/MoarVM, etc have become poisoned pills that shattered the community and distracted us from true enlightenment. I've watch this train wreck for nearly 20 years and each passing year only confirms for me that this is true. Every fight, every new release, every name change.

Recently I have seen something that gives me true hope that an idiomatically consistent approach to objects in Perl is possible. That thing is Util::H2O. I am not saying it is perfect, but hot dang it's exciting to see what can happen as a post-modern approach to OOP begins to spring to light.

One last thing I has point out is any successful OOP in Perl shall recognize a couple of things:

  • Perl doesn't have strong types (other than, yanno - hashes, arrays, scalars, etc); and it never will.
  • Perl is a forever language. It will never die, therefore we must accept its "limitations" (in quotes because I don't think they exist)
  • Any "OOP" will simultaneously looks like beautiful, idiomatic Perl to those who can appreciate it - and satisfy the itch (I say, chaffe) to have TRUE_OOP_IN_PERLtm.
Previously I brought up Util::H2O. In closing, I shall bring up a great example of a different kind of language that was cast into the mold of Perl by people who love Perl. PDL is a data language created by such people (and by their own admission). Notable in their handbook 1 is this experpt:
This is an important PDL concept: PDL stores its data arrays in simple perl variables ($a, $x,
$y, $MyData, etc.). PDL data arrays are special arrays which use a more efficient, compact
storage than standard perl arrays (@a, @x, ...) and are much faster to access for numerical
computations.
What is my point? Well, this is important, too: up to now people who have championed OOP in Perl have been people who arguably HATE Perl. What shall succeed will be done so by thoses who LOVE Perl and everything about it. Maybe it's the person who wrote Util::H2O. Maybe it's someone who has yet to be born. I have no idea. But I do know that this is how I feel after 20 years of being immersed in Perl.

References

  1. PDL Handbook
Update In addition to finding a perlish way to have OOP, also having a perlish to do through SMP threading would also have a tremendous impact. I suspect the path to this is withing something like PDL, which I believe has the right approach and is the right place for introducting some shared memory type things (if it's not there already, been a while).

Replies are listed 'Best First'.
Re^4: Cor—An object system for the Perl core
by etj (Deacon) on Apr 21, 2022 at 08:37 UTC
    When I was updating the slightly-outdated PDL::Dataflow doc recently, it occurred to me that
    • Perl is single-threaded and there are various ways to get round that, but no amazing ones
    • PDL's current multi-core functionality (which is indeed shared-memory, using POSIX threads) freezes the main thread until all the broadcasted operations are finished
    • it doesn't use the GPU at all yet
    • so long as there's only one POSIX thread running Perl, there's no reason PDL couldn't fire off other pthreads (or, in due course, GPU operations) then "await" (pun intended) / react to the completion of those in an async fashion with a suitable event loop
    That would be a lot closer to proper SMP, within Perl. My limited knowledge of parallel programming suggests that it's hard to reason about unless you have a "main" thread that's in overall charge, which this model would retain.

Log In?
Username:
Password:

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

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

    No recent polls found