On Wed, Nov 1, 2017 at 2:31 PM, Greg London <[email protected]> wrote:
>>> a real OO interface, >> Mouse/Moo/Mouse isn't good enough? > It looks amazing, but someone needs to go back and convert > all of cpan so blessed hashes are upgraded to moose. Everything has to do it the same way? That's not TIMTOWTDI. > Rakudo has what looks like really nice subroutine parameter design. > The problem is dealing with all the code that refers to $_[3] deep > in the middle of a subroutine. I don't see much of that. That would be a code-smell for sure. > Thats one of the things that makes simple support of someone elses > perl code so hard. They werent forced to name their parameter list > up front. I agree that's horrible. That's not idiomatic Perl. That's Perl (Perl 4) with a strong Shell accent. Such code does need modernizing. >>> Or if rakudo could run fast, id jump to that. >> All in good time. > Its been a lot of christmases in the making. Yes. Looks like the Yellow ± footnote that had been forestalling my trying some APLish matrix whacking is distinctly less missing. https://perl6.org/compilers/features#footnote_3 (Apparently there is still a possible PDL on top of quasi-native "compact" multi-dimensional arrays.) > I havent used it, but apparently python has extensions > That make it static type checked, speeding up run times > And making it more popular for embedded stuff. IDK. Python sure has one-true-way-thinking which will make it popular with folks who like that. People say "Perl doesn't have X" ... when what is usually true is that Perl doesn't have a single preferred X ... that is required ... or at least required unless you opt out aka default:on We generally have 3+ choices ... and the default is none of them ... (or the oldest and worst, and the best may not be in CORE yet). Our worst choice may not be better than Python's Hobson's Choice, but our best choice generally will be. If choice is good, this is not bad. If the choice made ages ago in your Legacy code wasn't bad, that's good. If however you have to support code that was written - by someone with bad taste, and/or - before the better options were available, and/or - before better options were in core distribution because CORP IT won't install CPAN in PROD yes, their historical choice can be beyond annoying. Then { /* Time to refactor! */ } [That's the sort of problem that can be outsourced to the professionals at The Perl Shop :-) ] *(Doesn't matter if decade(s) old Legacy was written by you a decade ago ... or dropped over the cube wall yesterday ... your taste, what's available on CPAN, what's available in CORE can all improve. What's allowed in PROD might get tighter, but with PERLBREW and/or Local::Lib, we can bundle a private Perl with the App and not rely on IT's no-CPAN-allowed /usr/local/lib/perl/lib , which could break an app if IT does OS upgrade so was always a bad idea anyway! ) IMO, Python's first big win vs Perl was picking a DLL / SO interface that was lighter, later binding. Perl standardized on compiler-binding with XS, a year or maybe just a few months too early. Which has made integrating with legacy C libs harder than it needs to be, making some deployments problematic. Even prevented me buying commercial Perl support for a Fortune 500 co. ! (We now have a light/late binding option also -- TIMTOWTDI -- but it's not the norm, so DBI DBD::* and XML::* still AFAIK don't normally use it.) Which makes numb.py and scipy the substitute for Fortran in BigData and Science, instead of PDL, etc etc. (PDL not being Core probably didn't help.) Sad. > I like perl. Its an old friend of mine. > It does some mind blowing amazing things. > But its like that old friend who has some really annoying quirks. Yep. Likewise. > Perl might be the sheldon cooper of programming languages. Heh. -- Bill Ricker [email protected] https://www.linkedin.com/in/n1vux _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
