Perl5 for UNIX is approaching EOL
If your company has any money invested into Perl development, you need to read this page to the end. Or just skip to the end.
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 pault.com
Pass around? Maybe somebody would like to give it a try.
pault12 at gmail
November 28 2021
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.Pipeline: 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
There are some obscure technical moments in crypto technical stack that were bugging me for some time (more is here: On Bitcoin) Today I finally figured out *why* it is the way it is. Amazingly, the technical problems of crypto stacks all originate from fundamental limitations of UCSD Pascal. In case somebody still does not know - there was Java before Java (1994) and it was called UCSD Pascal (1977) - which spans from Niklaus Wirth approach to computing!
In 20th century there were only two people, who knew, what they were doing with computers and Wirth is still alive and his approach is going strong - in academia. If you need an illustration of "how little things affect big things" - this is the clearest possible illustration. The Wirth's implementation of VM is skewing the market cap of Several Trillion Dollars! Yes. That's why Perl's VM is so *censored* important. It's the last one alive. Not for long, though.
As to crypto stack - it has a blind spot and that blind spot is specific to UCSD Pascal. It's embedded into that product line, so people who are only exposed to that product line will *never* see the obvious engineering approach, that is perfectly available outside their sandbox. That blind spot costs them trillions of $.
Real Programmers Don't Use Pascal - this piece talks about it. 1983.
He had located the data he was working on near the top of memory -- the largest locations the instructions could address -- so, after the last datum was handled, incrementing the instruction address would make it overflow. The carry would add one to the operation code, changing it to the next one in the instruction set: a jump instruction. Sure enough, the next program instruction was in address location zero, and the program went happily on its way.
Little problem with perlito runtime turned out to be a problem the size of UNIX. Clearly, perlito dude only runs it on Windows. It's not big of a deal yet, but I can't fix it nicely as fast as I was planning. Anyway, German's dude code can not even compile on my hardware, it needs a normal computer. Perlito works. Well ... looks like 50% of correct solution can be done easily. Ironically, there is a tcl way that allows crappy runtime to pretend that everything is OK. Wow. So now I understand the way tcl was produced.
The only reason Perl (and hence the Internet) prevailed was because of very few extensions written by very few british freaks. I think british managed to run out of freaks by this time. Somehow.
May 27 2022
Patch of 1 line fixes 90% of the problem. The rest 10% (hardest one) are pushed to the future. UNIX way, indeed.
You *do* understand why Perl is represented by Camel, right? It's a very old joke about design by committee. Internet says the joke is (at least) 1952.
Well, pretty much everything related to UNIX and files is borken. So it was not really 90% more than 50%. It needs some help, basically. Very much like perl4. Pretty straightforward so far.
May 28 2022
Hungarian notation was an interesting convention. Perl is the only existing programming language (except shell of course. PHP is just a crippled Perl repackaged and friendly) that contradicts it.
May 29 2022
So here is the summary. If you are currently doing anything in Perl
1. If you plan to throw away all your Perl code in a year or two, this page does not affect you. Could write everything in, say, Python (and rewrite everything every time somebody changes something, the Python world is different from Perl world). Or could use even plain shell (some corporations are doing that now).
2. If you plan to use Perl for web development - an ultimate solution for that is briefly described on this page (and no other solution exists on this planet and nobody is going to produce it because it already had been produced but the author is no longer operational).
3. If you plan to use Perl for *non-web* development - an ultimate solution for that is also hinted on this page and no other solution exists on this planet, because they are a bit lost last few years. This creates a very interesting situation around Perl.
In simple terms - everything you do can go down the drain any moment. And that is specific to Perl. Read this page to understand why.
May 30 2022
Perlito + Munin client makes for another strong blend. Figured out the name. Usually that's 50% of the project. Tried to figure it out for 10+ years now.
Jun 03 2022
C vs Pascal is Freedom vs Safety.
Jun 04 2022
If you still think Docker exists - you're a bit behind. Better to catch up.
Jun 09 2022
Larry Ellison is out. He was the last one. 77 y/o. Yes, this is very relevant to Perl.
Jun 10 2022
Figured out the prefect move for perlito. That solves 99% of the problems.
Figured out a way to improve on UNIX. A little bit. Yes, everything can be improved. UNIX is rather old. 1 minute granularity, race conditions etc. Systemd was interesting move. Useless, but interesting.
Jul 08 2022