Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

Re^9: Amicable divorce

by ribasushi (Pilgrim)
on Jul 12, 2020 at 17:12 UTC ( [id://11119231]=note: print w/replies, xml ) Need Help??


in reply to Re^8: Amicable divorce
in thread Amicable divorce

Named arguments, default values, parameter checking are all syntactic sugar, which sure, is somewhat nice to have, but is no possible way essential. Every time you go "I can do this using this little longer syntax" - you already disqualified it as a "long overdue must have feature".

If anything they are not long overdue: they are too late to the party. Using such snazziness would require me to leave behind 5.8-style perl, at which point I might as well leave perl behind altogether. The more "modern" you get, the geometrically smaller the pool of folks who would benefit from your work.

This is something I had to write 2 months ago. I can not write this in perl, and am not likely to ever be able to. Before you go "but async" - I will point out that in the entirety of my career IO has never been an issue. Given certain level of competence, you almost invariably end up bottlenecked on CPU.

But sure, let's talk about signatures and postfix-deref 🤮

Replies are listed 'Best First'.
Re^10: Amicable divorce
by LanX (Saint) on Jul 12, 2020 at 17:43 UTC
    > Named arguments, default values, parameter checking are all syntactic sugar, which sure, is somewhat nice to have, but is no possible way essential.

    I remember a talk from Damian from YAPC 2011 or 2012 showing the benefits of porting to Perl 6.

    The thing that stuck the most was when he showed how his subs shrank 30-50% only by using function signatures with parameter checking.

    > Every time you go "I can do this using this little longer syntax" - you already disqualified it as a "long overdue must have feature".

    Sorry it's not a little longer syntax, and training new programmers in how best to unpack @_ is a PITA.

    But, what's your concern here?

    That the syntax won't work on older Perl-versions???

    FWIW: It's possible to implement it with syntactic sugar in pure Perl without any XS, but the syntax would require at least one new sub args() which is called to unpack @_

    sub foo { args my $x, my $y ="default", name => my $name ="def2"; ... #body }

    When using Keyword::Simple this would also come without speed penalty, because args would be evaluated at compile time.

    Is that acceptable for you???

    > This is something I had to write 2 months ago.

    I'm no Go-go-boy , no idea what that means.

    > But sure, let's talk about signatures and postfix-deref 🤮

    I'm not fond about postfix-deref tho I'd avoid this emoji when criticizing other peoples work.

    But I'm a big fan of autobox which is backwards compatible.

    Something like $HoA{key}->push(1,2,3); is more readable than push @{$HoA{key}},1,2,3; , not only to beginners.

    Problem is that Autobox comes with a speed penalty, because ->push triggers a method lookup in a wrapper class for arrays (or undef scalars)

    A fast implementation would need to create Op-Codes for certain "special" methods like ->push or '->shift'.

    If the LHS is an array it would just execute the code for push() and 'shift()', etc without performance lost.

    Otherwise they would fall back to normal method lookup for objects.

    That's the way I would go for newer features:

    • first implementing a slow but light-weight backwards compatible variant
    • than implementing a fast XS variant on the same syntax and semantics
    • after a phase of proven experimental feature integrating it into the core language.
    Does this fit into your requirements, or do you still think Perl core should be frozen?

    PS: I'm using // nearly every day...

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    Wikisyntax for the Monastery

      > Does this fit into your requirements

      Absolutely not. My requirements are simple:

      Then maybe (and that is a huge maybe) I may reevaluate if something new is worth writing under /usr/bin/perl again. Today the answer is a resounding "fuck no".

      P.S. Golang the language (syntax-wise) is almost as shitty, and in places way shittier than Perl. Syntax is sugar: I have no problem copy-pasting code like an animal, provided my programs works, can push the resources I have to the max, and will continue doing so for decades.

      P.P.S. You really should not care what I think: I have not been paid to write perl since 2018, and I am unlikely to do so in the future. Perl work on a resume is a liability these days, unless you are happy with booking-level pay. I am decidedly not your target demographic.

        > Stop fucking around with syntax. If someone (including you) wants a new way to express the same thing, but shorter, they should pay the XS tax, not my userbase.

        I don't get it,

        • I showed two PP solutions ²
        • XS is a voluntary intermediate step to speed up (I can't hack C anyway°)
        • and if a feature is later included into a newer core, then syntax and semantics would stay the same.
        In short: It runs on 20 year old Perl versions just slower.

        ¯\_(ツ)_/¯

        PS: How do I pay the XS tax? Invoice or credit card?

        Cheers Rolf
        (addicted to the Perl Programming Language :)
        Wikisyntax for the Monastery

        °) I'm fucking around, tho ...

        update

        ²) wait, autobox does indeed require XS (I think it's overloading the -> operator)

Re^10: Amicable divorce
by jeffenstein (Hermit) on Jul 23, 2020 at 10:44 UTC
    Named arguments, default values, parameter checking are all syntactic sugar, which sure, is somewhat nice to have, but is no possible way essential. Every time you go "I can do this using this little longer syntax" - you already disqualified it as a "long overdue must have feature".
    Really, anything beyond binary can be considered syntactic sugar. It's up to you to decide how much you want, but I don't believe refusing a feature because it is "syntactic sugar" is reasonable; there are other, better criteria for this.
    This is something I had to write 2 months ago. I can not write this in perl, and am not likely to ever be able to.
    Ah, but this doesn't necessarily mean it can't be written in perl. You might just need to use a little longer syntax. ;)

      > > This is something I had to write 2 months ago. I can not write this in perl, and am not likely to ever be able to.

      > Ah, but this doesn't necessarily mean it can't be written in perl. You might just need to use a little longer syntax. ;)

      This is woefully incorrect. No amount of syntax will give me SMP-multithreading in Perl (preemptively: any type of async is not even close to multithreading). On top of that, in order to write the above I would need a proper, marshal-less, shared memory implementation.

      That said: I am behind the times with CPAN, so perhaps you will point me to an implementation of the above. I will be eternally grateful!

        No amount of syntax will give me SMP-multithreading in Perl

        Do you mean perl 5.005 threads?

        IIRC, the conclusion we got from there is that it is not doable without rewamping the runtime completely.

        Perl internal data structures were never designed for atomic access so locks need to be used to serialize their access. You could do as Python, have a global lock (bye bye SMP!) or require the programmer to lock by hand (that was the 5.005 approach), but that didn't work. Most modules failed to work in multithreading environments, usually because of the perl internals becoming corrupted... XS code was even worse.

        Perl 5.6 threads was a compromise where everything is cloned so that there is no interference between threads and whenever you want to share something, you have to say it explicitly and an intermediate (and quite inefficient) layer that does the locking and serializes access is set up by the runtime.

        So, in conclusion, do you want SMP in Perl 5? then write a new runtime! and forget about compatibility with any XS module!!!

        Would it be worth the trouble? IMO, well, maybe yes. There are so many things in Perl 5 that need fixing that could only be fixed by using a new runtime!!!

        But anyway, who is gonna do it?

        Update: oops, s/5\.6/5.005/g; s/5\.8/5.6/g;. I knew I had it wrong because I can still remember my excitment trying the threads support with LWP and getting SIGSEGVs all the time when perl 5.005 was released 22 years and two days ago! Just one of those things than randomly stick in your mind!

        A purist could pop in and say to you "no, I want Perl to just be P.E.R.L. and only that, no fancy additions."

        I don't agree with that view but we should not forget what Perl was created for.

        Asking for shared memory alone is vague. Asking for *efficient* shared memory is much more accurate. Only then we can see who is "swimming naked" ("You only find out who is swimming naked when the tide goes out" hehe, and let the source remain nameless) when it comes to comparing to other systems. Although I do not dispute that Perl's shared memory is inefficient.

        For the realist, if a solution must involve Perl, perhaps it should not be as fine-grained as to require sharing the million variables of a parallel algorithm. A coarse-grain implementation could be more suitable for Perl (being further away from hardware, compared to C, and this is the reason we all enjoy other perks!). That is, limit the amount of what is shared or access it in larger chunks of raw data where the inefficient lock mechanism does ot matter much. On the other hand, MMAPing a raw-memory buffer and sharing it, is easy but each thread interpreting it as a Perl nested data structure or object will take some efficiency away. Interpreting it as 100 such data structures in 100 threads it will be much slower. And then locking each of these.

        Additionally, there is the other route to harnessing state-of-the-art computer science developments: by using extenral libraries. For example the excellent implementation of AI::MXNet by Sergey Kolychev. Which is still a well-kept secret (I think? Anybody using it? Although regularly update. Thanks Sergey). Also see his relevant post http://blogs.perl.org/users/sergey_kolychev/2017/02/machine-learning-in-perl.html and my brief introduction to using it for very simple Dataflow programming Dataflow programming on CPU and GPU using AI::MXNet even on a GPU.

        These are great doors opened from within Perl. Fair enough, not what exactly you are asking for: transparent shmem-smp. But just write your algorithm as a Graph and let MXnet worry about parallelising it or even having the GPU solve it.

        Perhaps setting a concrete programming challenge can show the distance between practice and my theoretical blabber above?

        bw, bliako

        I was not being entirely serious in my comment (see the smiley at the end). That said, I'll still give it a go to answer your statements

        No amount of syntax will give me SMP-multithreading in Perl (preemptively: any type of async is not even close to multithreading)

        use threads;? Unless I'm missing something, which is likely here since the answer seems so simple.

        On top of that, in order to write the above I would need a proper, marshal-less, shared memory implementation.

        I'm not sure what you mean by unmarshalled shared memory, but then I'm not a full-time programmer, so this is probably my fault. There is PerlIO::mmap, the SysV shared memory modules, or a bunch of mmap modules on CPAN that might be usable for a generic blob of memory. I would guess that at least one of these would be usable, if not necessarily efficient or pleasant.

        Of course, it would be crazy to try to literally translate between two different programming languages, much like literally translating between spoken languages, so YMMV.

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others chilling in the Monastery: (4)
As of 2024-03-29 00:51 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found