I always liked the line from the 1987 UK black comedy film Withnail and I: “We’ve gone on holiday by mistake.” I wanted to recycle it.

Keen readers of this blog (of which there are none) will know that I sometimes talk about the accounting package I have written and rewritten many times over. Implementation languages have included Python, C++, Haskell, Go, Raku, Perl 5, C, Nim. Partial, often only tiny fragments, have been written using Forth, Cobol and Scheme. I might have missed a few.

Cobol made a showing due to my interest in retro languages. Boy, did that turn out to be hard work. It’s not so much the verbosity of the language that was the problem, but it was oh so manual, and lacked some pretty basic things. Cobol doesn’t support sorting, for example, claiming that it isn’t necessary because OSs normally include such a facility. Hmmm, OK, interesting argument. There also seemed to be syntax incompatibilities between various versions of GNU Cobol.

The upshot is that Cobol is a great big “no” in my book. Interestingly, there’s a language out called LDPL (LDPL, the Dinosaur Programming Language), which was insipred by Cobol, of all things. It’s a one-man show I think. The latest release was in December 2019, so it’s actively developed. No doubt it clears up a lot of Cobol issues and makes it a more usable language.

Haskell was interesting. Monads proved to be a learning curve. The syntax is exceedingly terse, even terser than Python. It has a deserved reputation for “if it compiles, then the code is correct.” I have said before that the perfect programming language would probably be some kind of hybrid of C++ and Haskell.

My criticism of Haskell is that it’s a good language with a bad ecosystem. There’s regular Haskell from your repo, a Haskell Platform and Stack. I suspect that “Platform”, which tries to be a “batteries included” system, actually causes more problems than it solved. Stack looks good, but when I tried it on Windows, it wanted to download a Haskell compiler of about 50M. No, don’t do that, I already have a Haskell compiler. Stack can resolved package dependencies. Then there’s Cabal, which either is a package dependency manager or it isn’t, depending on who you ask and whether words mean what they want them to mean, or not.

Upgrading Haskell systems can also be a source of pain. The problem is with Platform/not-Platform/Stack/Cabal etc. and their virtual or non-virtual environments is that the developer is faced with what looks like a mish-mash. It’s difficult to know what/which Haskell is looking for what library and why.

Go was interesting for a little while. It was faster than Python by quite a distance. I found myself criticising it for many of the reasons that Go detractors normally do.

My most recent developments were in Raku and Nim. Raku is slow, but it does have some nice touches to it. Nim is fast, has common-sense syntax, and it’s something that I’d generally recommend people investigate if they like fooling around with languages.

Perl 5 code is nippy. My Nim code was faster on a Raspberry Pi 2. But then again, the P5 stuff did use UNIX pipes and soforth, whereas the Nim version did not, so a P5 implementation could probably have been sped up significantly. Probably not to Nim levels, though.

At that point, I made up my mind about the direction of my accounting program: use P5. My reasoning is that it is ubiquitous (on Unix platforms at least), fast and likely to be preinstalled. I use my accounting program a lot, and I often tinker with various flavours of Unix. With a P5 implementation I can start from a clean Linux distro, bootstrap my user account from a git repo, and my program is ready to go straight out of the gate.

As a non-P5 programmer, I must admit to being confused about the whole sigil thing. I think it’s the case that the sigil you use is the type you want it to be; although oftentimes the type that you think something is is not the type it actually is. I’m sure it’s all very logical once you “get” it, but for the meantime, there’s a fair bit of cargo cult programming on my side. It works, but there’s something of a mystery as to why.

Despite that, I’m happy with P5. I’m sure one day it will “click” as to exact logic involved. My aim is to write small programs, so I am not fussed about issues like maintainability.

In fact, I am so happy with P5 that I decided to see if I could deprecate my usage of a Python library I used on rare occasions. I doubt that I will leave Python in its entirety. Jupyter and Micropython are absolutely great for programming microcontrollers like the ESP32.

So, in summary, I think I’m really coming to Perl 5 via Perl 6 (Raku). Perlers seem to have noticed a resurgence of interest in Perl 5, and it’s probably Perl 6 that’s driving it. I think people are discovering that Perl 5 is not as bad as its reputation.

It is a device enabling the drunken driver to operate in absolute safety.