I became a #perl 5 programmer by mistake

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.

 

withnail-1.jpeg

About mcturra2000

Computer programmer living in Scotland.
This entry was posted in Uncategorized. Bookmark the permalink.

4 Responses to I became a #perl 5 programmer by mistake

  1. Curtis Poe says:

    Perl dev here, but used to be a COBOL programmer for an insurance company.

    What’s going on with the whole “no sort function” thing is that COBOL generally wasn’t used to build monolithic systems in the way we tend to think of systems today (though sometimes it was and woe betide anyone who maintains that unholy mess). Instead, COBOL was often run via something called JCL (Job Control Language) and that JCL had steps (https://en.wikipedia.org/wiki/Job_Control_Language), which can be *loosely* thought of as a primitive shell scripting language (but not Turing complete). A simple JCL “job” might have the following steps.

    1. A COBOL program to fetch some data and filter out the data you don’t need, writing it out to a new file.
    2. OS utility to sort that new file.
    3. A COBOL program that takes the sorted file and aggregate the data
    4. OS utility to copy the aggregated data to a new file
    5. … and so on

    Note that effectively, many COBOL programs are built as small tools, similar to the Unix philosophy, and by combining a bunch of these tools together, you can build bigger systems. In this philosophy, sort isn’t needed because it’s already there. It’s just not where you expect it to be.

    So this precursor to the Unix philosophy actually meant that you could build some pretty amazing things with COBOL, but it was still a verbose, frustrating environment to program in.

  2. Pingback: 2020.04 Almost Springtime – Weekly Rakudo News

  3. It helps if you think of sigils as dereference operators

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s