develooper Front page | perl.perl5.porters | Postings from August 2020

Re: Q: what the hell is going on? // A: ...

Thread Previous | Thread Next
From:
H.Merijn Brand
Date:
August 6, 2020 09:52
Subject:
Re: Q: what the hell is going on? // A: ...
Message ID:
20200806115143.5ccfeb02@pc09.procura.nl
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


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About