[Vienna-pm] Perl 7

Thomas Klausner domm at cpan.org
Wed Jul 1 11:13:08 PDT 2020


On 2020-07-01 16:13, Roland Lammel wrote:
> Nachdem ich einiges Go gemacht haben, finde ich den "there is one way
> to do it" Ansatz großartig. Das führt zu recht konsistentem und
> lesbaren Sourcecode.

Das finde ich generell auch, aber v.a. das Error-Handling finde ich
extrem furchtbar. Die fehlenden generics stören mich im Prinzip, aber
ich hab erst so wenig go gemacht, das ich nicht sagen kann, ob sie mir
wirklich abgehen würden.

> Und vor allem das Deployment ist großartig einfach, da einfach ein
> Binary gebaut wird (auch Cross-Plattform und auch statisch gelinkt,
> wenn man will).
> ..
> Binary für einen simples Webserver ist ca. 6MB groß, die Container
> fangen glaub ich grad mal bei 100MB an)

das ist überhaupt eines der Killerargumente für go (und rust etc) und
gegen Perl (und Python/Ruby etc). Perl-Container sind im Vergleich zu
go-Containern extrem riesig.

> Rückwärtskompatibilität ist mir persönlich weniger wichtig, als
> eine gute Dokumentation von Breaking Changes (oder Tools als Teil der
> Sprache für eine Migration auf den aktuellen Syntax).
> Ich hab auch so bei jedem Perl-Update immer wieder was zu tun.

Ich hab hier 2, 3 alte Perl App (geschrieben als 5.10 rausgekommen ist,
mit neuen 5.10-Features). Die laufen derzeit auf 5.20 ohne Problem, aber
irgendwann in den letzten jahren mussten wir mal durchputzen (wegen
smartmatch, und auch weil Postgres-UTf8-handling sich geändert hat).
Ich kann den Code in einem Container mit einem beliebigen Perl sperren,
alles gut. Ich kann das Zeugs wohl auch auf neuem Perl laufen lassen
(und muss ggfs ein paar Dinge anpassen).
Aber ich glaube auch, dass es besser ist, hie und da mal upzudaten,
sonst stirbt man unweigerlich an der tech-dept (spätestens wenn das OS
irgendwas tiefgreifendes ändert)

> Also würde ich mir Native Cross-Plattform Compilation wünschen,
> einen einheitlichen Syntax für Objektorientierung, Concurrency und
> Type-Checking. Alles im Perl Core, weil nur dann verwenden es alle.

Ich finde es auch OK, wenn das über Module kommt. Gerne über
"offizielle" Module (aber darauf werden wir uns nie einigen..). V.a.
weil es so wenige Core-Devs gibt, wenn die dann auch noch OO/Async etc
machen müssen, geht das nicht lange gut.

Wenn aber zB Ovid et.al. Cor machen, LeoNerd Async, etc und diese Tools
auch entsprechend als Standard kommuiziert werden: super!


> Ich hoffe, dass es eben mehr wird mit Perl 7 als nur eine neue Version
> zu machen, die dann höher als 6 ist und ein paar Defaults ändert,
> aber nicht zu viel, weil sonst passt es wieder nicht allen.

Perl 7 ist AFAIK genau "nur" das. Und hoffentlich kommt dann bald Perl 8
etc mit zB method keywords etc (das hätte ich gerne, wobei dann wohl Cor
erst recht im core wäre, womit ich mir gerade widersprochen habe.. :-)

> Ich wünsche mir diese Breaking Changes, ich wünsche mir Änderung,
> ich wünsche mir keine unendliche Vielfalt an Libraries, die dasselbe
> tun, um etwas zu ergänzen, dass im Core fehlt.

Es gab/gibt ja immer wieder mal die Idee, ein Battery-Included-Perl zu
machen, quasi zusätzlich zum "normalen" nackerten Perl.

Wobei ich finde, das in Zeiten von Containern und Dockerfiles etc viel
von diesen Module-Fragen etc nicht mehr so mühsam sind wie früher.


Und abgesehen davon:

IMO ist das Hauptproblem von Perl, dass es kaum noch Module für aktuelle
Tools geschrieben werden (geschweige denn Tools..). Theo hat das auf der
CiC so schon
nvCPAN genannt: Not Very Comprehensive Perl Archive Network. u.a. weil
es eben keine Tools für OpenTracing gegeben hat (coolerweise gibt es
jetzt anscheinend welche, weil sein Job da was entwicklet und
open-sourced hat)

Aber in der ganzen Cloud/Container-Welt ist Perl in der Tat nicht
existent. Dabei würde es sich IMO sehr gut für div. Tools eigenen; aber
wir (Perl Devs) stecken alle noch in der "Server-as-Pets" Phase und/oder
sind überausgelastet und haben keine Zeit. Und müssen deswegen an
YAML-Templating leiden.


Ich finde immer noch, das Perl am besten zu meinem Gehirn passt! (was
auch immer das über mein Gehirn und/oder Perl aussagen mag). Aber ich
glaube (leider) nicht wirklich, dass Raku oder auch Perl 7(ff) zu einer
Perl-Renaissance führen werden. Inzwischen verwende ich (v.a. als
Freelancer) Perl als meine Geheimwaffe.

-- 
#!/usr/bin/perl                              http://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}


More information about the Vienna-pm mailing list