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.

Thanks.
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.

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 even use 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

Perlito is stagnant. Don't know if that's a good thing or a bad thing. In principle, I might be able to progress. But in a few years ... It's Lua or Go. Or Oberon. OK, D might have some hope after all. Go beats D, because crosscompiling. It's rather remarkable what is going on with the stacks recently.

Exception in thread "main" java.lang.UnsupportedClassVersionError: Main has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0

It was supposed to be "write once run anywhere". "Anywhere" now differs between two versions of Ubuntu for crying out loud. Perl is in better shape then. Wow. Who would have though.

Perlito is kind of OK but modules are a problem, yes. So need to untangle them one by one basically. Perl be Perl.

Jan 09 2023

Perlito can not compile insane Perl modules. Turns out, some of *core* Perl modules *are* insane. And there is a person, who was injecting the insanity. Yes, there was only one. Rather remarkable how much damage a single person can do. Perl codebases will be fun to maintain. Looks like there is rather simple way to get rid of this whole thing now. Who would have tought. I don't blame Perlito. I would have done more or less the same that he did. This *does* explain cries for help that some Perl core maintainers were including inside the modules. Perl core *was* purposely destroyed by the set of appointed peoples. It is very interesting what happens to this engine which effectively created the Web.

So there is a function localtime that takes time and returns the array. It's part of the language. But also there is a function timelocal that does the opposite (and it is *not* part of the language. It's a module). Surely in 30 years somebody would notice such an oddity and fix it? Nope. Not how it works.

The core Perlito pipeline - 100% done and works. Maybe I'm missing something, but it will be easy to fix. Did I say Perlito is an awesome project? Perlito is a godsend, basically. Like Perl 4 was.

#!/usr/bin/perl -I/u/PP -I.

use P;
use STD;

my ($sec,$min,$hour,$mday,$mon,$year) = localtime();
my $dt =  STD::Timelocal($sec,$min,$hour,$mday,$mon,$year);
print "$dt\n";

ubuntu@ubuntu-desktop:/u2/P$ ./t.pl
1673908092
ubuntu@ubuntu-desktop:/u2/P$ ./t.pl _j_
1673908103
ubuntu@ubuntu-desktop:/u2/P$ 

---

This pipeline allows for a clean port of Munin to Windows. I do use a Munin's subset (there was one person who did the minimal port ages ago) but that subset is very limited, really. It only covers very few metrics, not the whole thing. Then again, maybe nobody needs the whole thing. Still - after today, there is a clear path to bring Munin client to Windows.

Jan 16 2023

It is clear that Rust will produce more problems than even Java, because (lack of) patterns.

Jan 17 2023

Figured out the only pragmatic way to pull it all together. It is based on my work that I did 30+ years ago.

Feb 04 2023

LAMP stack is clearly no more. There will be plenty of business on all those PHP codebases

Feb 05 2023

Put the first component production. It works. The pipeline is a bit strange, because Perlito does have some bugs in code generation that sometimes get in a way in some major way. So far I always find ways to patch around via P layer, but eventually I will need to fix Perlito's codegeneration. Also, this kind of enforces "good style" (goto does not work, but while(1) does work), but some of the things are not so nice. ARGV is absolutely messed up somehow, backicks are messed up etc. Still - it's all doable, the design works *great* and this whole construction will carry on for as long as Java exists. And that will be a long time with all those people feeding of it.

I have the whole thing working. Regression testing. Automatic code coverage etc. Took a day to put it all together. Automatic code coverage is very good to have. Even if homegrown.

Prolog might be next. Yes. Prolog might be *perfect* fit for this. Who would have thought. Basically this all means that I might drop dependency on Perl as collective. It allows me to write in Perl, deploy *production* and have no dependency on Perl (and eventually on UNIX). This is big, really. Freedom.

Suprisingly, some parts look like JCL. JOB SYS IN DD. Yeah.

Feb 15 2023

Turns out - situation with Java packaging degraded substantially over these years. Comparable to LAMP stacks. So this now could move two ways. Was there anybody fixing anything at all last 6 years? Looks like they were only breaking things and stashing what they could not break. "Smash and grab" has that effect, yes.

Feb 16 2023

Figured out how to do the same trick around this, like systemd did to UNIX. The trick destroys node.js. Just eliminates it. Completely. Like back in a day I eliminated Hadoop. Pfs

Feb 18 2023

Figured out how to beat the ZMQ. Ironically, using his own real-life pattern.

Feb 19 2023

I now have some major questions about this Perl thing. Why is every module basically messed up? In a way this goes back to 90s when the only two operational VMs on this planet were Perl's and Java (neither is usable by this time). With the complete destruction of recent PHP builds ... So it's now Lua or else. "Else" is what I am doing. It works. Now the post-Java mainstream languages were (primarily) Go and then marginalia, like D, C# and such. So this means Go is the *only* usable mainstream toolchain (with messed up language layer, but they got everything else right). Go is becoming more and more interesting. As a toolchain of course. Of course! There is this JavaScript thingy, blocking the scripting niche. So yes ... The trick that I found primarily destroys Node.JS. Not that I was planning that, it just happened.

The resulting construction looks a bit unusual. But then again, nothing is "usual" last 6 years, so the only thing that matters is if it works or it does not. It works. It works great.

Mar 04 2023

This is re-incarnation of Forth and Prolog. And C. What's not to like? So far so good. Hello 1970s, we meet again. It will take about a week to consume Go (and Windows). This is moving *fast*.

There is only one university on this planet (in Eu) who is doing similiar stuff and they are only doing it because they have my blueprints from 30+ years ago. Nothing changed in 30 years. Absolutely nothing.

Are there problems with Perlito codegeneration? Yes, there are. Is it a dealbreaker? Nope.

Mar 05 2023