Powtils developers took a break for a while to step back and think. Every time fpc released a new compiler, it seemed to break powtils in many different ways. This should not occur, because if you write code, it should work for years, preferably indefinitely since according to Edsgar Dijkstra software is not "maintained" like a car is, as a software code is just a peice of math. People do not continually update their old math papers from school to get them "working" to conform to the latest calculators that just came out, from Casio... so to speak. Once the code is written, or once the math is written, it should work for years, if not forever. For example, when you write E=mc2 that equation is literally a lifetime equation that always works. Maybe in 4005 years they discover that the constant of light is slightly off, but not every few days or months, and even in 4005 years it's probably not going to be a different constant. Compilers are just fads, they change like clothing, or fashion.
So powtils 1.6 should work for eons, as it's just a solid piece of code that just works. And many people use it still, and brag about it, how they just can't stop using powtils even though it's an old version as they like it. But when we added new demos to 1.7 and new tools, and started making Powtils more modular where you could add sessions units of your own rather than having to use the one we give you, we found that the initialization and finalization sections in FPC were breaking our code, and people thought powtils was at fault and "buggy". When someone says "powtils, as far as I know, is no longer maintained" they are actually really saying "powtils works, but each time we release a new compiler we break powtils (not purposely, just, because compilers love to break existing code and annoy developers), but powtils is at fault, even though really we broke it via our compiler incompatibilities which has nothing to do with powtils code."The compiler keeps breaking code, with new function names deprecations, thread bugs, unit initialization bugs, unit finalization bugs... so what does a powtils developer do? We have to continually muck around with powtils code to get it working on the latest compilers, and it got boring pretty quick. Or we had to chase haunting bugs down (actually they are ERRORS). How would you like it if you had written beautiful mathematics on paper in school, and 1 year later you go back revisiting your math and it doesn't work any more. I.e. 1+1 is no longer equal to 2, because the new math that just came out changed. This is not how mathematics and programming works: code stays as code, you don't change it's oil, fix broken worn out parts: code doesn't wear out: it's mathematics with state. Your math from 1970 works on a casio calculator from 2016. So why doesn't your code work? So you sometimes just take a break, and come back later to revisit the scene. Maybe the compiler is better now, maybe libraries are fixed. Maybe not, depends. Hopefully things have gotten better.
Instead of actually getting web programming done and making websites powered by Powtils, developers spent a lot of time chasing down compiler bugs or strange RTL/system issues, or threading issues. For example at one time Aservia, a small webserver even more tightly coded and compact than Nyume, was working. Aservia was based on Nyume, but we took out some bloat and made the executable smaller and more compact, even though Nyume was fairly compact - it just needed improvements. Then with Aservia, it broke when FPC released some new compiler version. Then I studied Nyume code and found out that his code was very good but there were serious thread bugs. But was it Nyume that had the thread bugs? i.e. did he forget about a variable that wasn't freed properly or the thread was not programmed in such a way that the thread closed? Actually it was a compiler bug unrelated to Nyume code. Threads were leaking horrendous amounts of memory. Every time Nyume served a web page, it opened up a serious leak not because of any bug in Nyume but rather the fpc compiler had buggy threads. So obviously since Aservia was based on Nyume, aservia naturally inherited all the bugs too. i.e. you take some code that is great code, you change it to be even better, but both code is already broken because of the compiler you are using. Nyume appeared to work fine for all those who tried it, but they didn't actually try hitting the webserver hard and doing about 1000 web page hits to see thread leaks. Most people that try Nyume don't look at their CPU monitor (ctrl shift escape on MS Windows, and add the memory columns if not already there, and download old Sysinternals procmon tools, thread monitoring tools, etc. before Microsoft bought out Sysinternals company).
So we spend time looking for bugs in powtils code for days, weeks, months, trying to solve haunting bugs and errors, and then we find out it is not our code that's the problem! We have to become FPC compiler developers and fix the bugs or at least report them, and this is very time consuming so one just wants to give up and leave, as we are not fpc compiler developers we are fpc users. The problem is when you find a bug that surfaces in a Nyume program, or aservia program, you have to somehow make a small test case for the FPC team which can prove extremely difficult, as actually isolating the bug is very time consuming. Just giving the Nyume server to FPC and showing them the problem is not tolerated, you must isolate the bug into a tiny test case that's really simple. This is easier said than done.
Fixing the compiler is easier said than done, as it's a complex beast. Now there are indeed some powtils errors that have existed which are powtils fault. i.e. we had a IFDEF win32 define and not ifdef win64, so people had problems when 64 bit computers became more popular. Simple fix, simple problem, easy.
And there is another problem: FPC has so many complexities and compiler "modes", preprocessor, ifdefs, tricks, clever hacks, unlike simpler languages such as Oberon or even plain C, or GoLang. FPC spends all its time chasing Delphi complexities to try to mimmick it and copy it, plus fpc implements its own special modes that are not delphi compatible.. so you get this monstor compiler that can do all sorts of things kind of like complex Ruby (but ruby doesn't have multiple modes! so in a way fpc is worse). To fix a bug in the fpc compiler requires sifting through all this code and it's not easy. Whereas you look at an oberon compiler and it is simple as can be because it doesn't support all these features and features and features.
FPC is still offering turbo pascal modes too. It's not a pascal compiler, it's a multi try to do everything in the universe compiler, kind of like Emacs is everything and the kitchen sink, or how GCC is not just a c compiler but an Ada compiler, GNU pascal compiler, and a million more.
FPC has a lot of test cases, but this gives a false sense of confidence. In order to really test a compiler, you would have to have not a few thousand or million tests, but rather more than a billion times a billion times a billion, up to infinity, because you have so many possibilities. Test cases only cover 0.00000001 percent of the compiler (actually, less than that). This was also discussed long ago in Edsgar Dijkstra's article about tests proving the existance of known bugs, but not guaranteeing in any way a million unknown undiscovered bugs (proving absence?). So when someone says it passes the test suite, they think they are really confident about their code, when in fact it's introducing new bugs into the compiler going undetected, because you can't test a billion possibilities. Only tiny programs and simple programs are fairly easy to either Prove correct or test.
The more complex the FPC compiler gets, the more delphi features and fpc specific features it gets the more bugs are introduced. Code that's already written and done, is not actually done at all because new bugs get thrown in to the mix for older code when you update the compiler with a new feature as the code all affects other code in ways that the programmer doesn't predict.
But what happened to powtils? did we just get tired of chasing FPC bugs and never actually get much web programming done? Pretty much. My web programs are still running fine on my servers because I wrote the code and it works... I didn't bother continually recompiling my web apps with the latest fpc compilers, I simply used Fpc 2.0.x and ignored the latest and greatest nonsense that came out, like compilers that broke powtils code for no legit reason, or generics for OOP (why not generics for procedural code too?). GoLang is simpler, but we aren't abandoning FPC, we are just stopped to think about it for a while and figure out some kind of sensible plan. Step back, take a deep breath, analyze the nightmare of "compiler evolution". Because it certainly is not "design".
We're going to update 1.7.2 and fix some minor things and see how it goes, and port some of the utilities to GoLang as it is a fairly simple language without massive delphi complexities and a million modes. That doesn't mean we are stopping Powtils development for FPC and using GoLang 100 percent, we are just going to use multiple tools, fpc and golang.
Also, our user base is so small that there is almost no way to make serious money from Powtils and fund it, because only 10-100 people on earth use powtils for web apps. Consider a consulting company that wants to use Powtils to give their customer a web scraping program, or a wiki program, or a web forum, or a web service. Companies prefer PHP, Ruby, Java, C++, and known technologies. These technologies are monsters, "gorilla in the room". Terrifying. At least there is GoLang, which is pretty neat. FPC is pretty neat, but suffers from also being a monster.
Powtils has the problem of being tied to a dead language which is modern pascal. Whereas golang has momentum, developers, and no bad reputation that standard pascal has. So we'll try developing powtils side by side as an fpc project, golang project, etc. We tried even converting some powtils to Oberon but Wirth can't get strings correct and never has... Powtils for oberon would be like using Plain C... strings are not good in Oberon at all. Imagine either allocating memory for strings each time you use a string, like in C, or using fixed arrays of chars in Oberon kind of like Standard pascal but beyond 255 chars. No reference counted ansistring like Delphi has had for eons, a time proven guaranteed to be loved feature by programmers.There is a reason why pascal is dead (mostly), or it's variants are dead. Now oberon is pretty dead too, and never really has been alive. PHP is alive because it has strings! Perl the same. Ruby the same. Python the same. Everything we do these days is strings. The only time strings don't matter much is embedded programming where sometimes you have an LCD screen with 8 characters on it and you simply don't need ansistrings, and that's where Oberon works it seems.
GoLang is pretty alive, well, and kicking. Again this doesn't mean we abandon fpc and delphi, it's just a little taste of reality. FPC has a very small user base, but it's larger than Oberon. Oberon's user base is absolutely tiny, and really it's just a toy for Wirth's helicopter embedded control software and such... a few programmers use Component Pascal but it's strings are painful to use too, even though they tried extending the language to make strings easier to use. Modula is pretty dead. Ada is pretty complex and overengineered. See the pattern here.. no one actually likes pascal that much, in numbers. In big numbers.
Powtils had some cool simple demos that no other web framework had... programs that absolutely screamed simple while PHP creates complex messes daily with regex after regex after regex. Perl Cpan full of spaghetti code...Ruby Designed by the developers to be super complex like a human beings internals (yuck) but claims to be elegant on the outside like a beautiful human (sure, sure.. analogy FAIL). GoLang is looking pretty interesting and is almost a fork of the oberon project, even though it's not really, but kind of is. Just sort of. Once again, just because GoLang is looking interesting doesn't mean powtils stops development for FPC.
The idea that software has to be "maintained" is just another way of saying " your compiler keeps breaking your code whenever they change something so you have to fix your code to compile with the new non standard language that's always evolving". If someone designed something properly it wouldn't need "maintenance" it would just need more features over time, and even features are not always good as features are sometimes bugs. We have little time to add features to Powtils because we are so busy chasing down errors in compilers or RTL or libraries that powtils uses. Simple example: sockets was broken, then worked, then broke, and we chased those bugs down. But powtils appeared to be buggy to powtils users, because a bug in the compiler or the RTL or the system unit or sysutils, or sockets, that had nothing to do with powtils. The bug comes right up to powtils and infects all of the programs... even though they aren't powtils bugs.
One bug that really was powtils problem is the Windows 64 bit issue. We simply didn't have Windows 64 bit machines to test on back in the day when 32 bit processors were much more popular, so we forgot that IFDEF win32 needs to also add ifdef win64. This was because a transition stage was occuring where people were deciding to use IFDEF windows, or ifdef win32, or ifdef win64, etc. So if you are running an older copy of powtils you will likely have to edit the IFDEF win32 to now include IFDEF win64. What if WIN128 comes out or win256?
See how developers chase down problems that have nothing to do with the code logic that is already correct? The idea of running powtils on a 64 bit computer requiring fixes, should not be an issue, as the powtils code basically remains exactly the same! i.e. code should be portable. Powtils algorithms don't just change when 64 bit is added... powtils code is simple code that should run on any system... but things break, win32 defines are like the old C programming language problem... preprocessor being abused/used/misused. Developers waste time fixing stuff that has nothing to do with logic, and it's just trivial stuff but takes hours of time to hunt down. We criticize Plain C for having a unmaintainable preprocessor that does magic behind your back, and FPC has one too... so how can we criticize C? FPC is actually kind of C++ ish too, it even has C++ compiler style mode to add += and things like that. Cool feature, or cool bug? Or just a gimmick? Complexity is added to the compiler for these cool gimmicks?
I had issues even with basic file locking mechanisms because at the time of major powtils development there was no file sharing/locking utilities for FPC, other than the unix low level calls or directly calling the Win32 api, which is painful to deal with. Wikis need file locking if they don't use a database, when you store the content as one content page per file. A wiki page has to be locked when someone edits it, if it is multi user live web program. It appears fpc has added more file locking ability in the open file functions. So now the wiki can be updated to have better file locking, as we tried implementing our own file locking system a while back but it is much better to use operating system locking than to roll your own. We'll see how that works and update a copy of Simple Wiki and other tools.
But isn't this the case with all utilities, not just powtils? i.e. don't all developers have to deal with breaking code every time Python or PHP releases a new version? Well, hopefully software will be getting better if more people use simpler easier to understand tools that are not massive beasts, like portable GoLang code. Or even if Oberon fixed the string problem and didn't force programmers to write in CAPS LOCKS reserved words, Oberon would be a pretty neat Modern Pascal to work with. Is there hope? probably not, but, at least golang is fairly simple. Once again, this doesn't mean that GoLang is the new language for powtils, it simply means we will add it to the collection of tools. Will GoLang create a standard defined language or will things break? Time will tell.
Then there is the whole unicode farce. It was much easier when we just had to deal with english characters. Unicode is hyped to be the best thing ever, when in fact it creates numerous bugs in databases, web programs, infinite possibilities (a bad thing). It's hard to force people to just use 255 english characters, or 10 of them, or 128 of them or whatever you pick... but that simplicity is much better than trying to deal with 3 billion or 7982 billion characters. No one even knows how many characters there are any more, and parsing becomes extremely weird, buggy, strange, and difficult. Meanwhile programmers pretend it's all good and unicode is just great. Globalization, internationalization... Wonderful! A great nightmare, like Vanilla Sky.
GoLang is trying to solve the unicode issue by using Runes instead of Chars, but it makes the golang code harder to understand than the old Plain C char by char way of doing things where we just dealt with english, or the Delphi/FPC simple string[i] indexing which was great. But with unicode you have fpc developing is own unicodestring or ansi unicode string or whatever you want to call it, and then you have delphi doing their way. Then you have old win 98 or WinXP or Win2000 delphi apps that have strange issues compiling on new delphi compilers so people tend to keep old compilers on hand, rather than porting to the new "evolving" compiler that's never designed right.. it just "evolves" like evolution in nature (ugly mess).
You have fpc unicode modes that have to be implemented in the compiler to support delphi style or fpc style... more complexity. Or is it just types, and not modes? Or compiler magic? You have the debates about why fpc uses it's own unicode system and not delphis, or why delphi generics are not like fpc's. Double the features, double the bugs, double the wasted time updating the compiler to infinitely chase Delphi. Plus it still compiles turbo pascal code - interesting gimmick, more code to maintain. 255 standard pascal string limitations? even those exist because some of the fpc code is written in old 255 string code.
With unicode you have ansistrings that no longer work as you seem, strange converter functions that have caveats or gotchyas or catch 22's. Sometimes you forget whether you are supposed to be using this unicode conversion function, or that one, or whether you don't need to convert. UTF8 or UTF16? Double the bugs, double the variations. In other words Unicode complexifies the living shizzle out of your code, and you put on your rose colored glasses and say "yeah unicode is great! my chinese and arab customers can now view my site!". No. You just broke your site and created an international nightmare. Ever go to those websites where the database is corrupted because of unicode character gotchyas and conversion issues... I see these unicode bugs almost daily, on thousands of sites. Or how about the "quotation" turning into "quotation", or some bizzare character, or some other database corruption, or misconversion? Then you've got MySQL which isn't even a proper relational database that is used by the masses.... that's installed on 100 percent of all the servers out there (or 99 percent, or 97).
Dreaming of simpler days in the future.
Thanks for reading --Powtils Developer. We'll be right back after this advertisement from Life Extension. Then back to the dream.
