Perl5 for UNIX is approaching EOL

I've been talking recently to various Perl groups all over the planet and it looks like not many of them understand that next year might well be the end of Perl5 (all it takes to decommission Perl5 forever is major UNIX maintainers to include Perl6 as default - that was the process tested before). It was done with systemd and then it was done with Python (2 vs 3 switch) so it's only a matter of time when that happens to Perl5. Now because last few years not many people were able to make a living with Perl5 coding, this kind of hostile termination of Perl5 on UNIX can be relatively easy to do.

That's why last few years various Perl shops are trying different approaches to deal with (imminent) discontinuation of Perl5. Some shops are rewriting everything. Some shops are investing into their own distribution (Strawberry Perl is the most active example). There were various other attempts under Perl 11 umbrella (not one solid enough, but there are some really good moves out there). Active State is no longer dedicated to Perl (they were never dedicated to UNIX anyways).

Now important moment here is UNIX also. After IBM acquired Red Hat, that basically marks the End of UNIX in Americas Enterprise. There were various notifications of that happening for several years. (Oracles Moves, Debian Moves, stuff like that).

There are of course some branches of UNIX that might still survive as a marginalized shops (BSD, for example, never left that niche and they are fine being who they are). Only I think there would be not much enterprise budgets coming into UNIX most likely (and that would mean even less enterprise support for Perl, which was non-existent last 12 years anyways).

I know how to save (and rejuvenate) Perl5 for UNIX. I used to provide my own Perl5 distribution very long time ago, I also used to provide my own distribution of UNIX (long time ago, based on Debian) that's how I know.

If your shop would like to get your own Perl5 distribution for UNIX going - I know how to make it self-funded. By doing the exact same move Perl did in the beginning of it's life. Some moves are described on my website

Pass around? Maybe somebody would like to give it a try.

pault12 at gmail

November 28 2021

Professional Xsl

Disclaimer There is my name on that book. I know, what I'm talking about.
I'm a software engineer and I code every day. In Perl. End of Disclaimer

If you think good technology can't vanish - think again. AxKit - Apache Axkit was retired in August 2009 Problem is, it was retired not because it was bad or something. It was actually retired because it was the only way on this planet to produce scalable and flexible rendering pipelines that can be used by humans.


application server produces xml (or csv, the data flow) -> preprocessor (php + templates, say, in case of AxKit it was of course Perl) -> CSS/whatever

The attempt that started it all was XML + XSLT , but they managed to mess up XSLT layer very badly (because language). So what happened, happened, but as a result the (only possible) pipeline, that was a brainchild of the smartest people on the planet with decades of publishing experience (academia) was ruined in *production* (elitism), so everybody started to dance around PHP + CSS since then. The *only* working solution was AxKit.

If you want to produce a better version of AxKit - I can tell you how. I made some progress on a language level since then. Making rejuvenated AxKit a keystone for rejuvenated Perl 5 distrbution is kind of a no-brainer. They try to do something in that general direction with "modern perl". Since Larry Wall retired they are all a bit lost. Unfortunately.

December 09 2021

Figured out the roadmap. Interesting how it took exactly one month. Zope-Beans Resurrection ( And 20+ years of course ).

January 09 2022

So I install some Perl modules, read some comments. Many of the Perl people, whom I remember ... They're dead. Or destroyed. I wonder if I'd become one of them if I was a "Perl person". Which I'm not. I'm more of a Forth person.

March 31 2022

Why does OpenBSD still include Perl in its base installation?  First shot at removing Perl from *nix distro. Fascinating reading. End of 2019. What's interesting here that the guy is actually correct, but he got it backwards. The right move is to *keep* the Perl and remove everything else. It's possible. I did it in 2005 and it worked all right. Here is a bit more

April 01 2022

Larry Wall is an example of a great humanitarian leader. Most of the statements he made are indestructible. Yet there were a very few little things he got wrong. One of those he admitted - ( use strict should have been default ). Some he could not 'admit' because it's very hard to make a call about complex things. One of those things is "don't use spaces for alignment of assignments". I understand why he made it (you let that 'in' and might end up with Python) but I think it's dogma. He was better off not trying to enforce that one in particular. He escaped Python dogma, but failed for Bourbaki dogma. In his defence, I think he had no idea about Bourbaki when he was writing his guidelines. No matter what we do with computers, the fixed width / variable width dichotomy (for fonts) will always stay with us.

April 03 2022

Long time ago I learned C then Perl and then English. In a way those languages saved my life. The difference is that C and Perl only provided me with the good stuff (well, C was 100% good stuff, Perl was 90% good stuff and 10% some crap that can be ignored). I could have written the ratio for impact of Engish language on my life, but I will not do that. But I could. This Scandinavian stuff they started in Europe ... It will pass. As to the languages ... The only language worth learning is the one that improves your employment situation. The rest is bullshit. One can easily calculate which languages they should have learned last 20 years.

April 10 2022

Not very decentralized, you know ... There is only one guy, who holds Perl VM together. Only possible because cPanel pays him. Here is the inteview with him - Interview with Reini Urban

perlcc is still the original compiler. There were some minor outstanding bugs, which didn't hinder cPanel to use it for over 12 years with 5.6.2 successfully. There were some new and changed OP* and SV* data structures, but nothing dramatic. There were always B bugs, which I fixed by overriding the bad methods by my own.

And sometimes as in the latest years it does not make much sense to add support for a new release, because the latest releases had other dramatic problems, the maintainers were not able to understand. At least they eventually fixed it over time. Or let's say I had to fix it.

If you follow the development cycles for every new major release it is not much work. The problem is something else. Usually p5p is not able to come up with a proper design of a new feature, and the API is usually horrible. I am not talking about B. The normal API for XS developers and even core developers. Every new design is just horribly bad. Almost nothing would be acceptable in another language with proper SW developers and management. I have to leave out python and ruby here because they are even worse than perl5, but at least there is some kind of management going on. They have RFC's e.g. This upsets me of course, but you are not able to critize the developers. Their manager RJBS even recently came out with the new policy to enforce "faith" into his p5p developers, because of my constant critism. If you don't show "faith" you will be punished. perl5 has not only bless to create objects, it is now officially an religion and heretics are driven away. They don't show up anymore anyway.

So it usually needs some time to overcome my anger about so much stupidity and actually start implementing support for it. For example I could leave out immediate support for 5.16 to 5.20 because those releases where not worthwhile to support. But when Oleg Pronin/'syber' came along with his PIC patch, polymorphic inline caching to store the last used class pointer in the method with a 30% performance improvement, 5.22 suddenly became the most interesting target since 5.6.2 and 5.14.4. Of course p5p managed to talk Oleg down to throw away the PIC advantages and only use a naive monomorphic inline cache, i.e. store no hash of classes, just the last used class, but it is still a monumental improvement for method calls. "Why do we need a third hash implementation?" People should really be more critical and either use the older properly maintained versions or don't let p5p get away with technical nonsense. They usually have no idea what they are talking about, most normal CPAN developers do know better.

Platform support is done via the perl5 porters. They are the experts for platform problems and maintainance. I'm the expert for the compiler and the VM.

Yes, it is this bad. It's actually worse. He is in Europe. He has no idea how good he has it.

The future of perl5 is in hands of single German dude (who is pissed off).

Having said that - there is a way out. The dude is too focused on Lisp approach, so he is missing Forth escape.

cperl is a huge undertaking

perlcperl - a perl5 with classes, types, compilable, company friendly It will not prevail because there is no justification for a user to use this project. The user will follow standard perl5 into oblivion for as long as it would be possible because complaince. There could have been a way to boost the visibility of this project (by focusing on B::C part of the toolchain) only the author himself does not understand the importance of that, so the B::C section is buried in the middle of the document. The correct approach : throw away the entire document and only do B::C section, but do it right, not "Maybe provide python-like precompiled". Currently the stuff does not compile and there is no way to understand why it does not compile. Google is silent. This means nobody is compiling it. Last activity was in 2019. I would prefer something that actually installs (even if it does not support CPAN nor classes). On the positive side, I'm the only known perl5 developer who is properly paid 100% to work on perl5 core full-time. Exactly.

cperl is out, looks like. That leaves Rperl (which does not install and is very unusual) and Perlito. And that's it. Perlito only compiles into suboptimal backends, so the best approach is just to take Perlito and grow it. (Which is Forth way). Perlito worked like a charm. Very good project.

May 14 2022

perlito chokes on modules. GCJ also choked on modules (to the point that it died compeltely as a project). perlcperl did the great effort supporting the modules for that very reason. perlcperl is a huge undertaking indeed. perlito path looks a bit better still. If only all the way to AST. ... AST is suboptimal ... There was no need for AST to be like that ... That's because all the semantics of perl 5 and perl 6 and everything. All those years produced *this* ? I begin to feel German dude's pain. Backticks not working - how come. Backticks actually work but it depends on a shell command. Perlito is fun. UNIX has a way out. Allows to work around pretty much everything. Perlito path - works so far.

May 20 2022

python2, python3, python3.9. "python". Crypto is the same actually. On steroids.

Perlito does the job. It's very consistent with the first builds of Perl. "It does the job". Amazing effort. Perlito is clearly awesome. As long as you use UNIX instead of modules (the way it should be). Now the funny problem is one messed up part in runtime, after it's figured out the rest just works. *However* this little thing means not many people actually use this amazing code. Same with cperl. Perl remains an interesting part of the universe.

There is only *one* way to handle perlito's little runtime problem nicely. And that way is based on patch. The thing that Larry Wall wrote *before* Perl. This is really spectacular. Perlito (that is the same miracle in modern world, like Perl was 30 years ago) effectively brings us back 40 years, before Perl even existed. This is some splendid stuff. *Nothing* changed in 40 years? How was that even possible? Yet here we are.

May 21 2022