Perl5 for UNIX is approaching EOL
If your company has any money invested into Perl development, you need to read this page all the way to the 'Summary' section. Or just skip to the 'Summary' section.
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 gmailNovember 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/whateverThe 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
Yes Prolog. But not the way they do it. The whole Meta thing was a fad. Only Forth did it right. I wonder who started the fad.
Mar 22 2023
C vs Pascal is freedom vs safety. It's obvious that freedom costs *a*lot*. Oberon fits into single floppy disk, was capable of automating entire country of Eu and was all written by a single guy. And had no bugs of course. Compare that to the world of falling Boeing's etc. You got the idea. Freedom is not free at all. Surely Oberon had no (media capable) browser. Niklaus Emil Wirth knew his people really, really well. There was only one guy like him in US. He did not know his people as well as Niklaus knew his people.
This means the *only* choice of the stack (reminder of) is between Go and Oberon and it does not really look like Go provides much advantage besides cross-compilation. Alas. Oberon does not provide cross-compilation, only Go does.
Mar 22 2023
Figured out the whole architecture. It's still von Neumann, but it's not Boolean. And it's not quantum either. And no OS. No need. The real problem with Kubernetes is that it masquerades the failing processess and calls that "machine works". Re-spawning faulty process 300 times an hour (those were Rails numbers as far as I remember) so doing that does not mean something "works". It's an illusion of work. Fake work. Now the real work as in "machines should work" - that's totally different story and (suprirse) my architecture is *that*. Obsession with OS is just that, and obsession. Forth dude was right about pretty much everything. Hi 1970s. It's been a long 50 years and *nothing* was done. Can just pick up where they left. Tensorflow is a joke.
Mar 28 2023
#ifdef becomes :ifarg
Not bad for 50 years of progress. It turns out that Wirth is *exact* opposite of Moore. Talk about top down vs bottom up approach. What a difference 5 years make. Yes, that's their age difference. Both are alive.Apr 11 2023
Go pipeline - works end to end. Basically, this thing can consume pretty much anything *really* fast. Any language, any restriction. Most of those restrictions are artificial for a long time now, that's why.
So I debug it in Perl, then I prepare the executable via Go (for any platform, covered by Go - that includes cross-compilation to Windows as well), and the entire thing grows like Forth in a way. Also - no need in JRE installation (Java is messed up anyways). There is no other stack on the planet currently that would allow this. I had some hopes for D and Oberon a year ago. They can't do this. This even beats Perlito. Basically it beats any imaginable solution somehow. Was not planning for *that*, but it is what it is now.
Now that dude, who sits on all that code in Switzerland ... What was he doing all those 30 years I wonder? What is going on, basically? "Crypto", I guess. Well, 50% of every US downtown had been wiped out in 3 years, how would civilisation recover from this? Most likely it would not. So let's recycle, then. Whatever.
Yes, today changes pretty much everything. Somehow Perlito is no use now. And Java is no use now. Completely. Java is no use at all. Well, to think about Java as a phenomena, it was a fake contrarian play. "Non-visual Basic" that's what it was. I think the (fake contrarian) play was created by MS. "Crypto" conflict, effectively. I think the only reason it all worked out for so long was because of the "internet highway" con (and the real goal of it all was to masquerade the (insane) inflation).
From technical side of things, this looks like a natural progression actually. After I found a way to replace Hadoop (the poster child of Java stack) it was only natural to find a way to replace the entire Java stack. Kind of funny, really. To replace Hadoop I had to replace HDFS. That was the hardest. In a way. Also, that "D" thing is equally fake contrarian play. Looks like they always introduce the same "fake contrarian" trick. "namespaces in XML vs SGML" and all that. Never solves a thing. Forth's dude was right about everything. And Brooks was also right about everything. "Show me your tables, but hide the code". He died in 2022. I really miss the guy. Somehow. They were all good, but him I miss more than others, somehow. He only wrote a few pages of substance but the world still does not get those few pages. I see it every day for many years. I see it for many decades.
Apr 16 2023
I guess Forth had no regression testing. Would be hard to have one. Because there is kind of "no bugs". And when there is a bug, you just figure it out and keep moving. It goes totally against all those industrial approaches. The guy was a genius. That explains a lot about Brooks' work also. Bottom line - Forth's approach works *fantastic*. Several decades after it was introduced. The right thing to do is to follow it as close as possible. It's rather hard, because a single mistake in kernel creates a mountain of problems down the road and that means one *has* to get the layers perfect "the first time" - (which at first looks like a contradiction to Brook's "second system" approach). Basically, Brooks is planning for a disaster. Forth said "why is that? Just try to get it right the first time, and rollbacks are *cheap*". As long as your layers are perfect, rollback is not that bad in Forth. Yeah. UNIX pipes again. Hi 70s. Still, even with Forth, it still looks possible to leverage the "second system" approach, but that's because I can afford to make shortcuts "to be fixed later". Clearly, the key battle is variable number of parameters. I think first version of C did not even have that. I think they had to use MAC1, MAC2, MACN macros. No other way to do that. And why is that a problem? From what I see it is not *really* a problem, really. Still, somebody had to press for va_args and such. Because "looks ugly". (Found who was the "somebody". It was creator of C and it was because he was bothered that he has printf with variadics and nobody else has. ANSI C archives are amazing reading). Yeah ... It is a problem. Not for compiler level, for Macro level ... It can be hacked around with agressive code expansion, but that will really complicate everything ... Basically this 'varaible number of parameters' is really complex problem to handle nicely. Well, can always chain things ... The trick is to keep the number of parameters in check. Yeah ... it looks like agressive code expansion is the only way to bridge nicely a world that has fixed number of parameters (assembly and such) and the world that has all that variety all over the place (unix utilities have piles of parameters for example, unix *pipes* have even more flexibility). The resulting system will become rather powerfull. Now need to figure out a way to do it nicely. That is macros on steroids, but steroids are non-recursive kind. Havig said all this - I still cannot decide on mechanism and will postpone this for a while. In the meantime Benford's law is the bet. Works so far.
Also, macros per-se is not evil in C. It is *nested* macros, that is evil in C. Recursion is such a nifty trick that I think our brain craves it after it figures it out (only one out of 100 coders understands recursion. Now it is one out of 1000. Or worse.)
Apr 18 2023
Figured out how to apply this to publishing. Rememeber there was that XSL-FO thing ? Based on XML/SGML ? Yeah ... Figured out the replacement for that stack as well. That is because SGML/XML tree was effectively the part of that same Java stack tree. That's the problem with fake technologies. When bubbles go down, they go down *hard*. I think it's interesting that if MS would have included a single RMI.jar file into their MS IE browser distribution, the world would have been very different. Because it would have enabled the "Java is everywhere" architectures. Java applets would have called Java servlets over RMI and http stack would have been no more. A single .jar file not included with MS IE changed the course of civilization. In a way. And now I can just throw away Java stack alltogether. This is rather amazing. The thing that was one very little step away from consuming the world had been stopped and fallen. Bringing substantial part of civilization down in the process.
Might do kotlin native after go, but there is no incentive to do that yet. The hardcore way might be Rust. Having said this, after this point it does not really matter much which stack to piggyback, they are all more or less the same.
Apr 22 2023
May 02 2023.
Surprisingly, everything grows from PlanKalkul. Every single thing. He got every single thing right. Not just with computers.
While Zuse never became a member of the Nazi Party, he is not known to have expressed any doubts or qualms about working for the Nazi war effort. Much later, he suggested that in modern times, the best scientists and engineers usually have to choose between either doing their work for more or less questionable business and military interests in a Faustian bargain, or not pursuing their line of work at all.He even got the hungarian notation that actually makes sense. In 1945 he did.
I am solving the same puzzles like he was.
May 03 2023.
SCO announced on August 2, 2000, that it would sell its Server Software and Services Divisions, as well as UnixWare and OpenServer technologies, to Caldera Systems, Inc. The purchase was completed in May 2001. The remaining part of the SCO company, the Tarantella Division, changed its name to Tarantella, Inc., while Caldera Systems became Caldera International, and subsequently in 2002, the SCO Group.
The Shanghai Cooperation Organisation (SCO) is a Eurasian political, economic, international security and defence organization. It is the world's largest regional organization in terms of geographic scope and population, covering approximately 60% of the area of Eurasia, 40% of the world population. Headquarters: Beijing, China Founded: June 15, 2001
Old trademark was put to sleep in May 2001. The new trademark emerged Jun 15 2001. Three letter trademarks are (relatively) easy. Two letter trademarks are much more interesting.
May 24 2023.
At the end of February I figured out how to beat ZMQ using his own design pattern. As of today, his design model is simply - wrong. Constant simplification of a challenge ensures that nothing new will happen. Not saying that things should be pushed to the limits for the sake of pushing to the limits of course. But his core design *is* indeed wrong. Better than many (I was thinking maybe *the* best), but wrong. Zilog again.
May 26 2023.
Now I am reading through some ANSI C documents. Finding various people sitting in various high places around various programming languages. Long story short, the state of the industry is a disaster since 1980. That was the year they started the destruction of SU. Some people in EU and US are feeding of those times for 40+ years now. That explains why the key computer skills have been removed from planet job market. This chat GPT thing might try to consume as many computer resources as possible, because the guardians are basically dead (Dennis Ritchie was clearly one of the guardians, it's obvious from reading his communication with the committee), so the guardians are dead and there is nobody to replace them. This also explains all the misunderstandings I experienced here 20+ years ago. I was not supposed to be able to write a usable grammar for example. That's a sacred knowledge here and only special peoples are supposed to do that. This stuff with computer languages is more important than I thought. Basically, how come 6 elegant pages of BNF become 15 *mln* lines of (useless) code? It's not over till it's over of course. Basically figured out what to do with the stack and turns out the road forward implies going back to 1980s. Technology is fun.
This part about chat GPT. In one of her musings in the 90s the guardians secretary is asking herself "we have email/spam and we have viruses, will somebody combine those?" Content mutations personalised. Yeah. Welcome chat GPT.
The modern RU planet level trade flows had been set up in about 1974. Those were very questionable trade flows and only benefited very few areas. Whatever happened since that time was built on a very shitty cultural agreements. The agreements started to collapse around Y2K and collapsed completely in 2014. 74 + 40 = 2014. 40 years cycles are *very* real.
May 29 2023.
Mob is everywhere. They are easy to spot now.
May 30 2023.
Figured out the way to handle variadics and basically designed everything. Yes, it is perfect.
Bootstrap and self-hosting is a fallacy from 70s, because that's how they basically had to do things at that point. Forcing everybody into bootstrap and self-hosting is rather classic cargo cult, but what else to expect? *Everything* is cargo cult since 2008. 70s is not a bad place to be. Some parts of the world *really* want to get back to XVII century. Let them. I take the 70s.
Nvidia all time high.
June 02 2023.
If depressed and tired, just listen to Ana Vidovic playing Bach. She will fix you.