A Tour of Old Languages

I think I learned a few things lately (or at least formed opinions). Programming language fundamentals change so seldom, I thought it would be fun to order this post in the order I first learned the languages even if this is a bit arbitrary.

BASIC

The idea certainly isn't due to me, but I may have mentioned previously that a much lower-cost way to deliver systems is to compile to native code (i.e. no JavaScript/Python/whatever - Golang might be a reasonable choice) and use SQLite. This means you can run on a (potentially large) cloud instance instead of a K8S cluster which is drastically simpler.

If you go a step further and don't need a Web app, you end up with requirements like old Visual Basic (and before that, dBase or Clipper) used to satisfy. A good way to satisfy these nowadays would be by adding a Golang interface to Tk, but there's actually something much closer to Visual Basic - PureBasic. Commercial product, but I didn't mind (I thought the price was reasonable). Has a form designer for quick prototyping, and the usual structured programming tools (i.e. no line numbers). Looks much faster to develop those line-of-business CRUD apps, if you can get away with running locally.

=> PureBasic home page

What I was surprised to find though is that there is a nice set of 2D and 3D game libraries on this platform too (3D based on Ogre). All in all, I think you get a lot.

=> PureBasic docs, including libraries | Ogre3D graphics engine

Assembler

There are a few methods to try make assembler easier to maintain. One that is used by the FFmpeg project is a Perl script and an assembler include file.

=> Preprocessor for Apple's ancient gas | Assembler "utilities"

asm.S implements something quite similar to the machine/asm.h file I mentioned in my previous post, defining macros for common tasks like defining functions, and architecture-specific oddities like IP-relative loads. And gas-preprocessor implements a compatibility shim for Apple gas, although I haven't found it necessary myself (running "cc -x assembler").

Anyway, my point is I was uncomfortable doing things like FFmpeg. It may be an unfair criticism, but some of the stuff seemed more concerned with signal processing for their project rather than general-purpose. And given that there are already two preprocessors running, the one built-in to gas and cpp for include files, adding a third as a Perl script seemed excessive.

So in the end I decided to stick with my previous plan:

• Use the OS-vendor provided include files, primarily machine/asm.h but some other system headers (and your own) can be processed by assemblers too using conditional compilation.
• Use the structured assembler macros I found (this is actually independent from other considerations).
• Use gas macros where I will be laying bytes in memory, cpp macros for helpers in one line.

=> Structured gas

One problem I hit, whatever I did to Apple's toolchain it wouldn't do some branches to local symbols for me. This may be user error, or a hint that I need to convert 100% of the code to use the structured macros?

I think I've converted about 90% of a small amount of code I was interested into this structured style (I hope it won't be followed by the 2nd 90% as the project management saying goes).

Ada

Not so much about the language, but ARM Macs (like I'm typing on) are now fully supported by the open-source Alire project. There was a time when I would have been delighted by this, but lately I'm thinking more that 2-level systems are better, e.g. FGHC & C.

If I wanted to do everything in one language (in $DAYJOB we use C++), Ada would definitely be a good choice. It (or Standard ML) should probably have been used for a lot of important systems instead of unsafe languages over the past few decades, and is far more stable than Rust. If you have time, it's worth learning for lessons you can apply to any language, e.g. interface design. I remember the first time I realised what software engineering could be it was from reading Grady Booch's Ada programming book (which went way beyond basic programming).

=> Alire, open source Ada library (and toolchain) package manager

Perl

At one stage, I wrote quite a lot of this. But for the past N years, it's all been Python. I'm not a big fan of Python, the language is surprisingly complex now for what's supposed to be a simple scripting language. And I have never succeeded in delivering built projects to customers, they always need to get source code and even then it can be problematic to get running on anything other than the developer's machine. And you have to use venvs, otherwise you break the whole OS installation (MacOS does this well, you are strongly recommended to use pipx to install apps & venv within your own project for library code).

But anyway, thankfully I haven't written much Python for personal projects. I think I should have kept using Perl a bit more though. The OpenBSD devs like it, the modern language is fine, and they seem to never break old working code. My latest recommendation for how to write Perl is to start scripts with:

use v5.36;
use utf8;
use open qw(:std :utf8);
no warnings qw(experimental::signatures);

which is derived from this link:

=> What happened to Perl 7

And in a nod to BASIC, the first language I learned, there is a project to rewrite simple games from an old book, and one of the targets is Perl. There is even a script to convert from vintage BASIC to Perl. But this is probably only useful as a first pass, the vintage variant of BASIC is quite unstructured compared to Visual Basic and PureBasic mentioned above.

=> Basic Computer Games | bas2perl.pl

=> Back to my gemlog