Front page | perl.perl5.porters |
Postings from August 2020
On Thu, 6 Aug 2020 11:09:30 +0200, André Warnier (tomcat/perl) <aw@ice-sa.com> wrote: > And I cannot stop myself from wondering, if the point is really to > make changes to perl to make it more "modern" and more attractive to > young programmers (**), why not switch to Perl6/Raku then ? 1. Raku is a completely different (and beautiful) language Learning it is absolutely worthwhile, but it still is a different language (though the possibilities to express your thoughts in code is probably even better that perl) 2. Perl is still extremely faster than Raku is some areas, esp if XS is used. If speed is crucial, you will have to write something in both and compare for your situation to decide 3. CPAN is "the solution code base" for Perl, and will be. Noone is trying to make it obsolete or fail. 4. The point is not "just" to make the language more attractive to new programmers. (if that was the only point to make, Raku could well be the answer). We - as core developers - are currently hindered in making changes to the core to fix issues or add features we want to have (with end users in focus) *without* breaking the world. We now have to live with years of legacy code of which some has been written for perl4. As an example, $Foo'Bar'x was perl4 syntax for $Foo::Bar::x and it is *still* supported. Getting rid of that in a limited scope will make the parser a lot easier to extend and e.g. support try/catch. (this may be a false dependency, but used just as an example). I honestly think that there is less than 0.01% of the users who would object to dropping support for "'" as package separator if that would open the road to full-featured exception handling. *Those* are the changed being discussed. 5. In this process, we (the core team) also modernize the internals to follow the guidance we always give to new users: use strict and use warnings will be always on in *internal* code. Note that end-users or modules will not even notice. The code is just safer and better tested. FWIW I have used and still use Perl since 4.018, where I implemented a Unify database layer ala ora_perl in uni_perl. I currently maintain Text::CSV_XS and we used that as a canary in the coalmine to see if anything we discuss would break that (and some other modules high up in the river). So far, we are just in discussion, and - as rjbs already said - nothing has been carved in stone. Text::CSV_XS currently supports perl version 5.6.1 .. 5.33.0 (all of those are tested threaded and unthreaded before a release is made) and also passes its tests if I would enable all the restrictions that have been proposed in the discussion process, so I think that "Everything will break" is extremely exaggerated and not true at all. If we do not discuss a road forward, nothing will happen and people will leave to other languages that *do* allow the features they hope to find. For me, Perl is *the* language of choice, as it enables me to express my thoughts in a language that I like in a format/style that I like. I use Perl in production code (with a minimum of version 5.14.2 for different reasons) and I do not want to have that code break. At all. -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.31 porting perl5 on HP-UX, AIX, and Linux https://useplaintext.email https://tux.nl http://www.test-smoke.org http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/Thread Previous | Thread Next