It's 40 years later - long enough to see several revolutions in the field - so surely these are obsolete, right? They belong in the same category as "always carry a bundle of hay for the horses" or "you won't always have a pocket calculator with you" or "tie an onion on your belt to stay stylish".

Ah, my sweet summer child! Plus ça change, plus c'est la même chose. You'll find nearly everything in here depressingly relevant.

Before we dive in, a word for Bentley on the provenance of this collection:

Programming Pearls.

Although there is some truth in each saying in this column, all should be taken with a grain of salt. A word about credit. The name associated with a rule is usually the person who sent me the rule, even if they in fact attributed it to their Cousin Ralph (sorry, Ralph). In a few cases I have listed an earlier reference, together with the author’s current affiliation (to the best of my knowledge). I’m sure that I have slighted many people by denying them proper attribution, and to them I offer the condolence that Plagiarism is the sincerest form of flattery.

Here we go!

Coding

When in doubt, use brute force. Ken Thompson - Bell Labs

Straight off the bat, a winner! Almost all problems are solvable through brute force. It may take time - but throw more resources at it! Once you know it can be done, then it is time to see how it can be done better.

Avoid arc-sine and arc-cosine functions - you can usually do better by applying a trig identity or computing a vector dot-product. Jim Conyngham - Arvin/Calspan Advanced Technology Center

And then, just like that, something broadly irrelevant today. These sorts of mathematical functions have been optimised so far that it probably doesn't matter which way you calculate them.

Allocate four digits for the year part of a date: a new millenium is coming. David Martin - Norristown, Pennsylvania

*weeps* Why didn't they listen to you, David? While I would hope any code written this side of Y2K uses ISO8601, it is amusing that you still occasionally encounter people who want to save two bytes somewhere. Handy in some small systems, but mostly just a recipe for disaster. Looking at you, GPS!

Avoid asymmetry. Andy Huber - Data General Corporation

I'll be honest, I'm not sure what Andy is going on about here. I assume that he's talking about having the ability to go A->B without being able to go B->A. Equally, it could be about accepting data in one format and outputting it in a different format. Some more discussion on the topic.

The sooner you start to code, the longer the program will take. Roy Carlson - University of Wisconsin

Bam! Right in the truth. Much like the woodsman who spends his time sharpening his axe, we know that diving into code is probably the least efficient way to create something.

If you can’t write it down in English, you can’t code it. Peter Halpern - Brooklyn, New York

So many bugs come from us not understanding the requirements of the user / customer.

Details count. Peter Weinberger - Bell Labs

Hard agree, Pete! It's very easy to go for the "big picture" view of the software. But unless all those sharp edges are filed down, the code isn't going to have a happy life.

If the code and the comments disagree, then both are probably wrong. Norm Schyer - Belt Labs

Ah, the dream of self-documenting code will never be realised. Again, this goes back to our (in)ability to properly describe our requirements and our (in)adequacies at turning those comments into code.

A procedure should fit on a page. David Tribble - Arlington, Texas

Famously, Amazon has a "Two Pizza" rule which defines the maximum size of a team. The larger and more complex something is, the more likely it is to go wrong. Yes, there are limits to DRY and YAGNI - but we seem firmly in the paradigm that large procedures / functions are ruinous to one's health.

If you have too many special cases, you are doing it wrong. Craig Zerouni - Computer FX Ltd. London, England

IF/ELSE and CASE/SWITCH still really test our patience. Beautifully clean code which is ruined by special subroutines for rarely occurring situations. But it is hard to call them "wrong". Sometimes the world is complex and it is the job of computers to do the hard work for us.

Get your data structures correct first, and the rest of the program will write itself. David Jones. Assen, The Netherlands

Dave is right. A well-defined data structure is still the essence of most CRUD systems.

User Interfaces

[The Principle of Least Astonishment] Make a user interface as consistent and as predictable as possible. Contributed by several readers

*weeps* Why isn't this hammered into every programmer? Today's tools are filled with hidden UI gestures, random menus, and a complete disregard for the user's time.

A program designed for inputs from people is usually stressed beyond the breaking point by computer-generated inputs. Dennis Ritchie. Bell Labs

I think this one is mostly irrelevant now. Humans can only type at a limited speed, but computers can generate massive amounts of data instantly. But our machines' abilities to ingest that data has also grown. I suppose the nearest thing is the DDoS - where a webserver designed for a few visitors is overwhelmed by a flood of automated and malicious requests.

Twenty percent of all input forms filled out by people contain bad data. Vic Vyssotsky. Bell Labs

Ha! Vic didn't know that we'd have <input type... validation in the 21st century! But, yeah, people write all sorts of crap into forms.

Eighty percent of all input forms ask questions they have no business asking. Mike Garey. Bell Labs

Mike was sent from the future to warn the people of the past - but they paid him no heed.

Don't make the user provide information that the system already knows. Rick Lemons. Cardinal Data Systems

I'm going to slightly disagree with Rick here. Asking for repeated information is a reasonable way to double-check you've got that information correct. It also helps to validate that the user is who they say they are.

For 80 percent of all data sets, 95 percent of the information can be seen in a good graph. William S. Cleveland. Bell Labs

Those of us who have seen Anscombe's quartet know how true this is.

Debugging

Of all my programming bugs, 80 percent are syntax errors. Of the remaining 20 percent, 80 percent are trivial logical errors. Of the remaining 4 percent, 80 percent are pointer errors. And the remaining 0.8 percent are hard. Marc Donner. IBM T. J. Watson Research Center

Syntax errors are rarer now that we have IDEs. And I hope visual programming languages will further reduce them. Logic errors still plague us. Pointer errors have been eradicated unless you're working at the very lowest levels. And I'd say the number of "hard" bugs is probably higher now due to the complex interaction of multiple libraries and systems.

It takes three times the effort to find and fix bugs in system test than when done by the developer. It takes ten times the effort to find and fix bugs in the field than when done in system test. Therefore, insist on unit tests by the developer. Larry Bernstein. Bell Communications Research

We can quibble about the numbers and the ratios - but it is generally harder to fix in prod. That said, getting crash logs from the field has considerable shortened those ratio.

Don’t debug standing up. It cuts your patience in half, and you need all you can muster. Dave Storer. Cedar Rapids, Iowa

I'm with Team-Standing-Desk! So I think Dave is wrong.

Don’t get suckered in by the comments - they can be terribly misleading. Debug only the code. Dave Storer. Cedar Rapids, Iowa

Hmmm. Yes, this is probably correct. I'm not going to say code is self-documenting these days; but it certainly is a lot easier to read.

Testing can show the presence of bugs, but not their absence. Edsger W. Dijkstra. University of Texas

Dare we disagree with Dijkstra?! Well, perhaps a little. With modern fuzzing tools we can show the absence of certain kinds of bugs.

Each new user of a new system uncovers a new class of bugs. Brian Kernighan. Bell Labs

Yup! Our code would be bug-free if it weren't for those pesky users!

If it ain’t broke, don’t fix it. Ronald Reagan. Santa Barbara, California

Amongst the many things about which to disagree with the former President, this is up there! Code needs maintenance. Some things aren't broke until all of a sudden they are. Sure, maybe don't change your app's layout because a manager wants a bonus; but things constantly need fixing.

[The Maintainer’s Motto] If we can’t fix it, it ain’t broke. Lieutenant Colonel Walt Weir. United States Army

I believe in you. Self deprecation is fine, but self confidence is better.

The first step in fixing a broken program is getting it to fail repeatably. Tom Duff. Bell Labs

Yes! Transient errors are the worst! And a huge source of the "it works for me" antipattern.

Performance

[The First Rule of Program Optimization] Don’t do it. [The Second Rule of Program Optimization - for experts only] Don't do it yet. Michael Jackson. Michael Jackson Systems Ltd.

As true now as it ever was.

The fastest algorithm can frequently be replaced by one that is almost as fast and much easier to understand. Douglas W. Jones. University of Iowa

I'm only mostly in agreement here. Many of the security bugs we see in modern code are due to "clever" tricks which turn out to have nasty strings attached. But, at the microcode level, performance is still everything. And a well-tested fast algorithm may be necessary. As part of the climate crisis we should all be thinking about the efficiency of our code.

On some machines indirection is slower with displacement, so the most-used member of a structure or a record should be first. Mike Morton. Boston, Massachusetts

We live in an age of ridiculously fast SSD and RAM access times. Sequential reads are still slightly faster than random jumps, and structures like B-Tree give us a good mix of the two. We don't need to align data to the physical tracks of a spinning disk any more.

In non-I/O-bound programs, a few percent of the source code typically accounts for over half the run time. Don Knuth. Stanford University

I wonder how true this now is? Perhaps we could replace "I/O" with "Internet requests" and still be accurate?

Before optimizing, use a profiler to locate the “hot spots” of the program. Mike Morton. Boston, Massachusetts

Mostly true. But you don't lose much by doing some manual optimisations that you know (from bitter experience) will make a difference.

[Conservation of Code Size] When you turn an ordinary page of code into just a handful of instructions for speed, expand the comments to keep the number of source lines, constant. Mike Morton. Boston, Massachusetts

I don't think this is relevant these days. Perhaps it is useful to spend time explaining exactly what trickery you're pulling off with weird syntax. But our tools are now line-count agnostic. Mostly.

If the programmer can simulate a construct faster than the compiler can implement the construct itself, then the compiler writer has blown it badly. Guy L. Steele, Jr. Tartan Laboratories

I think this is rather self-evident. But compilers are so ridiculously optimised that this scenario is increasingly rare.

To speed up an I/O-bound program, begin by accounting for all I/O. Eliminate that which is unnecessary or redundant, and make the remaining as fast as possible. David Martin. Norristown, Pennsylvania

I think this can be generalised even further. I'm reminded of NPM's progress bar slowdown issue. There's a lot of redundancy which can be removed in many programs.

The fastest I/O is no I/O. Nils-Peter Nelson. Bell Labs

Man! They were obsessed with I/O back in the day! At large volumes, it is still an issue. But perhaps now we can relax just a little?

The cheapest, fastest, and most reliable components of a computer system are those that aren’t there. Gordon Bell. Encore Computer Corporation

A little unfair, I think. It's cheaper to have less RAM, but that doesn't make my laptop faster.

[Compiler Writer’s Motto-Optimization Pass] Making a wrong program worse is no sin. Bill McKeeman. Wang Znstitute

Personally, I don't think it is the compiler's job to tell me I'm doing it wrong.

Electricity travels a foot in a nanosecond. Commodore Grace Murray Hopper. United States Navy

And a nano-Century is Pi seconds! One of those pub-trivia facts which are irrelevant to modern computing.

LISP programmers know the value of everything but the cost of nothing. Alan Perlis. Yale University

Nowadays LISP programmers are a protected species and shouldn't be subject to such harsh treatment.

[Little’s Formula] The average number of objects in a queue is the product of the entry rate and the average holding time. Richard E. Fairley. Wang Institute

Another of those truisms which kinda don't matter in a world with infinite disk space. Speed is our greatest worry.

Documentation

[The Test of Negation] Don’t include a sentence in documentation if its negation is obviously false. Bob Martin. AT&T Technologies

I don't know if that's the same guy as Uncle Bob - but it sounds like the sort of claptrap he'd come up with. What's obvious to you might not be obvious to others. Test your writing with your audience to see if they understand your meaning.

When explaining a command, or language feature, or hardware widget, first describe the problem it is designed to solve. David Martin. Norristown, Pennsylvania

Agreed. It doesn't need to be an essay, but documentation needs context.

[One Page Principle] A (specification, design, procedure, test plan) that will not fit on one page of 8.5-by-11 inch paper cannot be understood. Mark Ardis. Wang Institute

I do have some sympathy with this - see the Two-Pizza rule above - but I think this ignores the reality of modern systems. Yes, we should keep things simple, but we also have to recognise that complexity is unavoidable.

The job’s not over until the paperwork’s done. Anon

Amen!

Managing Software

The structure of a system reflects the structure of the organization that built it. Richard E. Fairley. Wang Institute

This is Conway's Law and it is still fairly true. Some studies show it is possible to break out of the paradigm but it holds remarkable power.

Don’t keep doing what doesn’t work. Anon

If only we could tattoo this on the inside of our eyelids, eh?

[Rule of Credibility] The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time. Tom Cargill. Bell Labs

Agile methodology has somewhat dimmed the potency of this prediction. I think people are generally better at estimating now. But it is hard to escape Zeno's Paradox.

Less than 10 percent of the code has to do with the ostensible purpose of the system; the rest deals with input-output, data validation, data structure maintenance, and other housekeeping. May Shaw. Carnegie-Mellon University

How many times have you installed a simple program only to see it pull in every dependency under the sun? We need an awful lot of scaffolding to keep our houses standing.

Good judgment comes from experience, and experience comes from bad judgment. Fred Brooks. University of North Carolina

I lean slightly towards this. I also strongly believe that you can pick up a lot of good judgement by listening to your users.

Don’t write a new program if one already does more or less what you want. And if you must write a program, use existing code to do as much of the work as possible. Richard Hill. Hewlett-Packard S.A. Geneva, Switzerland

This is the open source way. Much easier to fork than start again. But at some point you'll run up against an unwanted design decision which will be load-bearing. Think carefully before you re-use.

Whenever possible, steal code. Tom Duff. Bell Labs

ITYM "Respect the terms of an OSI approved Open Source licence" - don't you, Tom?

Good customer relations double productivity. Larry Bernstein. Bell Communications Research

A lesson learned by Apple and ignored by Google.

Translating a working program to a new language or system takes 10 percent of the original development time or manpower or cost. Douglas W. Jones University of Iowa

I honestly don't know how true that is any more. Automated tools must surely have improved that somewhat?

Don’t use the computer to do things that can be done efficiently by hand. Richard Hill. Hewlett-Packard S.A. Geneva, Switzerland

A rare disagreement! Things can be efficiently done by hand once or twice but after that, go nuts! Even if it's something as simple as renaming a dozen files in a directory, you'll learn something interesting from automating it.

I’d rather write programs to write programs than write programs. Dick Sites. Digital Equipment Corporation

There will always be people who love working on the meta-task. They're not wrong for doing so, but it can be an unhelpful distraction sometimes.

[Brooks’s Law of Prototypes] Plan to throw one away, you will anyhow. Fred Brooks. University of North Carolina

I'd go further an suggest throwing out even more. It can be hard to sell that to management - but it is necessary.

If you plan to throw one away, you will throw away two. Craig Zerouni. Computer FX Ltd. London, England

Craig with the double-tap!

Prototyping cuts the work to produce a system by 40 percent. Larry Bernstein. Bell Communications Research

Minor disagreement. Prototyping is part of the work. And it should probably take a considerable amount of time.

[Thompson’s rule for first-time telescope makers] It is faster to make a four-inch mirror then a six-inch mirror than to make a six-inch mirror. Bill McKeeman. Wang Institute

Yes. It is always tempting to go for the big win. But baby-steps!

Furious activity is no substitute for understanding. H. H. Williams. Oakland, California

Goodness me, yes! It's always tempting to rush in pell-mell. But that's a poor use of time.

Always do the hard part first. If the hard part is impossible, why waste time on the easy part? Once the hard part is done, you’re home free. Always do the easy part first. What you think at first is the easy part often turns out to be the hard part. Once the easy part is done, you can concentrate all your efforts on the hard part. Al Schapira. Bell Labs

Oh, Al! You card! Luckily, there are very few "basic" problems to be solved in modern computing. We know what most of the hard problems are. Perhaps Agile teaches us to always leave software in a working state, so we start with the easy parts?

If you lie to the computer, it will get you. Perry Farrar. Germantown, Maryland

We shouldn't anthropomorphise computers; they don't like it. Actually, nowadays it's is quite common to "lie" to computers with dummy data and virtualised environments. It's fine.

If a system doesn’t have to be reliable, it can do anything else. H. H. Williams. Oakland, California

Perhaps it is my imagination, but we seem less concerned with reliability these days. A Tesla car is a wonderful example of that.

One person’s constant is another person’s variable. Susan Gerhart. Microelectronics and Computer Technology Corp.

I wonder about this one a lot. Scoped access to variables possibly makes this less of an issue in the 21st century?

One person’s data is another person’s program. Guy L. Steele, Jr. Tartan Laboratories

I don't quite get this. Anyone care to explain?

Eschew clever rules. Joe Condon. Bell Labs

The pearls end with this gem.

What have we learned today?

The majority of my disagreements are minor quibbles. And while disk-bound I/O is rarely a problem, network latency has replaced it as the main cause of delays. We've managed to fix some things, but many seem irrevocably tied to the human condition.

Which one was your favourite?

After skimming through a few options, I found Tempest Highlight. It has nearly everything I want in a code highlighter:

•  PHP with no 3rd party dependencies.
•  Lots of common languages.
•  Modern, with regular updates.
•  Easy to use functions.
•  Range of difference style sheets.

But, on the downside:

•  No WordPress plugin.
•  Not all languages supported.
•  CSS embedded in HTML.

I can live without some esoteric languages, but I don't really want to run composer install on my blog. I just want a quick WordPress plugin. So, here's how I did it.

Here Be Dragons

This is a quick prototype. It has an audience of one; me. It may break in unexpected ways. Use at your own risk.

The file layout is relatively simple:

WordPress Plugins
├── Highlight_Plugin
│   ├── src/
│   ├── autoload.php
│   ├── index.php
│   └── base.css

The src/ directory contains the src/ directory from Tempest Highlight.

The Art of Loading without Loading

Normally, to install a PHP package, the composer app creates an autoloader which will magically import everything you need into your project. We can't do that here. Instead, we need to manually load the library.

Create a file in the plugin's directory called autoload.php - its job is to autoload everything in the src/ directory.

<?php
spl_autoload_register( function ( $class ) {
    //  Project-specific namespace prefix
    $prefix = "Tempest\\Highlight\\";

    //  Base directory for the namespace prefix
    $base_dir = __DIR__ . "/src/";

    //  Does the class use the namespace prefix?
    $len = strlen( $prefix );
    if ( strncmp( $prefix, $class, $len ) !== 0) {
        //  No, move to the next registered autoloader
        return;
    }

    //  Get the relative class name
    $relative_class = substr( $class, $len );

    //  Replace namespace separators with directory separators, append with .php
    $file = $base_dir . str_replace( "\\", "/", $relative_class ) . ".php";

    //  If the file exists, require it
    if ( file_exists( $file ) ) {
        require $file;
    }
});

I don't know if that's the easiest way to do it. But it works!

Testing

The index.php file can now be tested:

//  Load the Tempest Highlight library
require_once __DIR__ . "/autoload.php";

//  Set up the namespace
use Tempest\Highlight\Highlighter;

//  Define the theme.
$theme = new Tempest\Highlight\Themes\InlineTheme( __DIR__ . "/src/Themes/Css/light-plus.css");

//  Create the highlighter.
$highlighter = new Tempest\Highlight\Highlighter( $theme );

//  Print some formatted HTML
echo $highlighter->parse("<em id='foo' class='bar'>test</em>", "html" );

All being well, that should produce this:

&lt;<span style="color: #0000ff;">em</span> id='foo' class='bar'&gt;test&lt;/<span style="color: #0000ff;">em</span>&gt;

That has the CSS embedded. Not ideal, but certainly good enough. I picked "light-plus" because it was the only theme which seemed to meet at least WCAG AA when on a white background.

OK, so how do we go from printing out a scrap of HTML to extracting all the code snippets from a WordPress blog?

Draw The Rest of the Owl

In theory the code is relatively straightforward.

Find code snippets

My Markdown plugin transforms this:

 ```javascript
 var a = 2.0;
 ``` 

Into this:

<pre><code class="language-javascript">
var a = 2.0;
</code></pre>

No need to use a regex, the new PHP 8.4 HTMLDocument gives us direct programmatic access to the HTML.

//  Load the content into PHP 8.4's HTML DOM.
$dom = Dom\HTMLDocument::createFromString( $content, LIBXML_NOERROR | LIBXML_HTML_NOIMPLIED, "UTF-8" );

//  Select the code snippets.
//  `<pre><code class="language-*">`
$codeSnippets = $dom->querySelectorAll( "pre>code[class^=language-]" );

Replace the snippets

From the above, I have the language and code, so it can "easily" be replaced.

//  Iterate through each snippet.
foreach ( $codeSnippets as $code ) {
    //  Get the HTML from within the <code>.
    $originalCode = $code->textContent;
    //  Replace the contents of <code> with the highlighted HTML.
    $code->innerHTML = $highlighter->parse( $originalCode, $language )
}

Replacing the code in that node manipulates the original DOM. Which means, after looping through all the snippets, I can return the altered HTML like so:

return $dom->saveHTML();

And then…

Obviously, there's a bit more too it than that. It ignores RSS feeds, it adds a base CSS style to the head, some SVGs get embedded, semantic metadata is included, and it all gets a bit tangled and complicated.

ToDo

A few things need to happen to make this even better.

• Encoded comments as well and posts.
• Add new languages.
• Don't in-line the CSS into the HTML, but add it as a separate stylesheet.

But, for now, it is running on my blog and that's good enough for me!

Get the code

You can play about with the WordPress plugin. Bugs reports, pull requests, and suggestions all warmly welcomed.

There are now multiple Markdown parsers, each with their own idiosyncrasies. To make matters worse, there's a set of extensions popularly known as "Markdown Extra".

Extra has support for things like tables, footnotes, and - in some dialects - autolinks.

Most of the time, when an author writes the text Visit https://example.com they want the URl to be automatically turned into a hyperlink. Most Markdown parsers support that. Hurrah!

But there's a rather nasty little edge case.

Markdown is explicitly designed so that authors can mix and match HTML and Markdown in the same document. This is perfectly valid:

I <em>love</em> the delicious taste of **fresh** oranges!

Which becomes:

I <em>love</em> the delicious taste of <strong>fresh</strong> oranges!

This is also valid:

<a href="https://example.com/">Visit my *favourite* site https://example.com/</a>!

The parser is smart enough to ignore the link inside the href="" but will process all the Markdown contents of the <a> element.

The text favourite is converted to <em>favourite</em> correctly.

But what about the link? Should that be autolinked?

Here's how a few dozen different Markdown parsers fare.

Nearly all of the ones which support Autolink end up producing broken HTML. They nest an anchor within an anchor. Something explicitly forbidden by the HTML specification.

<a href="https://example.com/">Visit my
   <em>favourite</em> site 
   <a href="https://example.com/">https://example.com/</a>
</a>!

Others break in weird and unexpected ways.

Is this a bug?

Markdown is an excellent example of "do what I mean, not what I say" software. To the human reading the text, it might seem obvious which parts need to be transformed and which don't.

There are various specifications for how autolinking should work - but I couldn't find any documents which explicitly discuss where it shouldn't work.

At this point, you're probably going to leave a comment saying that it is the users who are wrong. They should wrap links in brackets, or stick to pure Markdown, or some other tosh.

Markdown was supposed to simplify the process of writing HTML. Anything which forces the user to write in an unnatural or confusing way is a bug.

Markdown allows you to write using an easy-to-read, easy-to-write plain text format, then convert it to structurally valid XHTML (or HTML).

Markdown Introduction

I don't think any of the authors of Markdown parsers have been naughty here. They mostly just follow the spec. But Markdown was designed without ever being tested with real users. And real users break things in all sorts of unexpected and delightful ways.

That's where the real bug is. When we don't test with users and fail to meet their expectations, we produce faulty software.

Fine! I'll expand a little more.

Large Language Models are a type of Artificial Intelligence. They can read text, parse it, process it using the known rules of English, and then regurgitate parts of it on demand. This means they can read and parse a question like "In Python, how do I add two numbers together?" and then read and parse the Python documentation. It will produce an output like:

What happens if you search the official Python documentation for "adding numbers"? Nothing useful.

Now, perhaps you think that's a trivial and unfair example. Python has an excellent tutorial which explains addition and the main documentation isn't really aimed at the casual user.

But how many times have you tried to use a moderately popular library, searched through its documentation, and found yourself lost in a maze of twisty passages, all alike?

Be honest! Reading bad documentation sucks. Sometimes it can be impossible to look up the most inconsequential piece of syntax, and sometimes it's maddening to find an example which does exactly what you're trying to do.

We all know that StackOverflow built its empire on the back of poor documentation. Take a look at the highest ranked questions in your favourite language and see if you could answer them using only the official documentation.

Humans aren't good at doing boring things. And programmers (a sub-type of humans) hate the boring job of writing documentation and tutorials. It seems anathema to them. Even when they can be arsed to write documentation, it is rarely tested with users to see if it is understandable.

We've had over half a century of people writing documentation which is so poor that publishers have made a fortune selling books called "Learn How To Program in ___ the Easy Way!"

Do LLMs occasionally get things wrong? Yes. But official tutorials are also frequently outdated.

Do LLMs burn through hideous amounts of electricity? Yes.

Do LLMs have infinite patience when being asked simple questions? Yes.

Do LLMs win in this arena because humans are lazy? Yes.

For those new to the format, there is a popular meme about things which computer programmers erroneously believe. This isn't intended to shame anyone - just to point out things which may not be immediately obvious to the neophyte.

There's nothing us Brits love more than moaning talking about the weather. And, just as Inuit speakers have hundreds of words for snow, so English speakers have hundreds of words for rain.

What's cold for you is not cold for me

I've visited countries where I was sweating as soon as I stepped off the plane while the locals were dressed in layers and shivering.

Similarly, I'm sure you've visited a blustery northern English town at night and worried that the hoards of teenagers on the lash are going to catch a chill.

It doesn't always snow at Christmas

A few years ago, I had the delightful experience of enjoying Xmas in the southern hemisphere. The weather was blazing hot - and several stores had artificial snow in the windows for a "festive" look.

There are plenty of calendars which have snowy motifs for December, even on the side of the planet where the Moon is upside down.

℃ ℉ °K

Perhaps the most obvious one. 100° may either be delightfully warm or fatal, depending on what system you use.

There are, of course, many different temperature scales. I recommend Hasok Chang's Inventing Temperature for more information.

And more?

Feel free to add your favourites in the comment box.

When I write code snippets in Markdown, they look like this:

```php
$a = 1;
echo $a;
if ($a < 5) {
   // Do Something
   return thing( $a, true );
}
```

But I want to render that with code highlighting. I was using the Prismatic Plugin. It is excellent and very customisable. But it uses JavaScript to do the code highlighting. I want to respect my readers' time and battery life; so I'm trying to reduce my dependency on Client-Side rendering.

I've switched to a modified version of WP-GeSHi-Highlight. That turns the above Markdown into:

$a = 1;
echo $a;
if ($a < 5) {
   // Do Something
   return thing( $a, true );
}

Necessary Changes

When the JetPack Markdown pre-processor encounters a code block, it changes:

```php

into

<pre><code class="language-php">

This means the WP-GeSHi-Highlight detection needs to be changed.

Old version:

return preg_replace_callback(
    "/\s*<pre(?:lang=[\"']([\w-]+)[\"']|line=[\"'](\d*)[\"']"
   ."|escaped=[\"'](true|false)?[\"']|cssfile=[\"']([\S]+)[\"']|\s)+>".
    "(.*)<\/pre>\s*/siU",
   "wp_geshi_store_and_substitute",
   $s
);

New version:

return preg_replace_callback(
    "/\s*<code(?:class=[\"']language\-([\w-]+)[\"']|line=[\"'](\d*)[\"']"
   ."|escaped=[\"'](true|false)?[\"']|cssfile=[\"']([\S]+)[\"']|\s)+>".
    "(.*)<\/code>\s*/siU",
   "wp_geshi_store_and_substitute",
   $s
);

One of those matches looks for escaped= which can be true or false. I always want this to be true so, later in the code, I change a variable from:

$escaped = trim($match[3]);

To:

$escaped = true;

Style Changes

By default, everything looks pretty good - but there are a few changes I found necessary to make.

Firstly, there was something weird going on with the line-heights of my style, so I added this to my site's CSS:

/* GeSHI Highlighter Fixes */
pre:has(> .wp-geshi-highlight-wrap5) {
    line-height: 0;
    padding: 0;
    background: none;
    filter: invert(1);
}

The invert gives it a dark mode.

Secondly, in order to make any changes to the default styles of the highlighter, you need to add the bundled wp-geshi-highlight.css file into your style directory. The plugin will use that if it exists - so you can change font size and padding to be the same as your main theme.

Limitations

There are a few limitations with this approach.

No line-numbers. The plugin looks for something like line="13", but there's no way to add that in Markdown.

GeSHi hasn't received style updates on some languages for quite some time. It hasn't received any significant update since 2019. Which means bugs and security issues are likely.

Language definitions are quite strict. You can use javascript but not json.

The plugin doesn't have any options - nor an easy way to override its settings. So I've monkeypatched everything above. If the plugin updates, I'll need to change my code.

Demos

A few demos - just so you can see what it looks like.

Python

#!/usr/bin/env python
from datetime import datetime, timedelta
from mastodon import Mastodon
from bs4 import BeautifulSoup

import config

#  Set up access
mastodon = Mastodon( api_base_url=config.instance, access_token=config.access_token )

#  Get user's info
me = mastodon.me()
my_id = me["id"]
year_joined = me["created_at"].year

Bash

if [ "$(basename $2)" = "Image.gz" ] || [ "$(basename $2)" = "vmlinuz.efi" ]
then
# Compressed install
  echo "Installing compressed kernel"
  base=vmlinuz
else
# Normal install
  echo "Installing normal kernel"
  base=vmlinux
fi

if [ -f $4/$base-$1 ]; then
  mv $4/$base-$1 $4/$base-$1.old
fi

Rust

// This is the main function.
fn main() {
    // Print text to the console.
    println!("Hello World!");
}

JavaScript

if (hour < 18) {
  greeting = "Good day";
  alert( greeting );
} 

In her book about the divergence of the English and American languages, Lynne Murphy asks this question:

wouldn’t it be great if language were logical and maximally efficient? If sentences had only as many syllables as strictly needed? If each word had a single, unique meaning? If there were no homophones, so we’d not be able to mix up dear and deer or two and too?

That got me thinking about the creativity which can be expressed in code - and whether its a good thing.

Let's take an incredibly simple and common operation - incrementing an integer variable by one. How would you do that? You've probably see these variations:

$i = $i + 1;

or

$i = $i++;

or

$i = 1 + $i;

or

$i = int( float_adder( float($i), 1.00 ) );

or

i1, i2 = i1^i2, (i1&i2) << 1 

I'm sure you can come up with a few more esoteric methods.

The Python programming language has a list of aphorisms for good programming practice. One of which is:

There should be one-- and preferably only one --obvious way to do it.

Is that right? As described in What is Pythonic?, the Python language itself has multiple ways to accomplish one thing.

But, is it a good idea?

Back to Lynne Murphy again:

No, absolutely not. No way. Quit even thinking that. What are you, some kind of philistine? If Shakespeare hadn’t played with the number of syllables in his sentences, he would not have been able to communicate in iambic pentameter.

Shakespeare wasn't writing Python though, was he?

It tasted basically fine - no different to any shop bought tofu. It wasn't noticeably cheaper, it wasn't more nutritious, nor was it easier to store and prepare. I'm sure that if I spent several attempts I would gradually get closer to creating something comparable with the shop-bought product. And then what? Do I want to spend a few hours tending to my tofu whenever I feel like a stir-fry?

Cooking - and learning its chemistry - can be fun. It can also be a drudge. Sometimes I don't want to individually peel and slice a dozen ingredients. I want to push a few buttons on my microwave and then eat something.

The same extends to nearly every field. I could knit my own clothes and - no doubt - I would find the process interesting, relaxing, and entertaining. But for everyday wear, it would be a startling waste of my time to do so. Even if I avoid sweatshop labour and fast-fashion, a decent jumper is cheap and provides excellent utility.

But part of the joy of making - and mending - is that you get to learn a little slice of how the world works.

I first encountered Conway's Game of Life when I was a kid. I thought it was the hideously complicated thing which I simply was not qualified to understand. But after reading the biography of von Neumann it suddenly clicked. I understood its simplicity.

In order to test my understanding, I built my own Game of Life interpreter. It's nothing fancy. A few dozen lines of Python. It won't win any awards for efficiency nor for coding style. But it works.

In the unlikely event that I ever need to use Life in production, I'm going to use a mature and well supported library. But by building my own toy implementation, I have a superficial understanding of what it is meant to do, where the pitfalls are, and what limitations I might encounter.

And that's my approach to most things. Learn how to make, understand the obvious problems, fall back to the mainstream option if it is easier than continuing.

As pointed out by Dave a company called Nordigen was set up to provide a free Open Banking service. It was quickly bought by GoCardless who said:

We believe access to open banking data should be free. We can now offer it at scale to anyone - developers, partners and Fintechs - looking to solve customer problems.

And, I'm delighted to report, it works! As a solo developer you can get access to your own data for free via the GoCardless APIs.

You'll get back a JSON file from each of your banks and credit cards with information like this in it:

{
   "bookingDate": "2023-07-11",
   "bookingDateTime": "2023-07-11T20:52:05Z",
   "transactionAmount": {
       "amount": "-2.35",
       "currency": "GBP"
   },
   "creditorName": "GREGGS PLC",
   "remittanceInformationUnstructured": "Greggs PLC, London se1",
   "merchantCategoryCode": "5812",
   "internalTransactionId": "123456789"
}

For foreign exchange, transactions look like this:

{
   "bookingDate": "2023-10-01",
   "bookingDateTime": "2023-10-01T21:41:40Z",
   "transactionAmount": {
      "amount": "-0.82",
      "currency": "GBP"
    },
    "currencyExchange": {
      "instructedAmount": {
         "amount": "1.00",
         "currency": "USD"
      },
      "sourceCurrency": "USD",
      "exchangeRate": "1.2195",
      "targetCurrency": "GBP"
   },
   "creditorName": "KICKSTARTER.COM",
   "remittanceInformationUnstructured": "Kickstarter.com, Httpswww.kick, 1.0 U.S. DOLLAR USA",
   "merchantCategoryCode": "5815",
   "internalTransactionId": "987654321"
}

Depending on your card and the transaction type, you might also get a few more bits of metadata.

Get started at https://gocardless.com/bank-account-data/. From there, it's a case of following the quickstart guide.

A few niggles

There's a bit of bouncing around. You've got to get an API key, get the institution ID, sign in, get redirected, get an ID from the callback, then get the bank account details. And then you can get the transactions!

Oh, and the access token only lasts a short while, so you'll need to either re-auth or use a refresh token.

Bank authorisation only lasts 90 days, so you'll have to refresh your details every 3 months. That's standard across all opening banking, but a bit of a pain.

GoCardless have pretty comprehensive bank coverage but they are missing a few which you might find useful.

Because there are so many financial institution in there, you might find it difficult to work out which one you need to log in to. For example, if you have a Barclays Credit Card, which of these is the right one for you?

{
    "id": "BARCLAYCARD_COMMERCIAL_BUKBGB22",
    "name": "Barclaycard Commercial Payments",
    "bic": "BUKBGB22",
    "transaction_total_days": "730",
    "countries": [
      "GB"
    ],
    "logo": "https://cdn.nordigen.com/ais/BARCLAYCARD_COMMERCIAL_BUKBGB22.png"
  },
  {
    "id": "BARCLAYCARD_BUKBGB22",
    "name": "Barclaycard UK",
    "bic": "BUKBGB22",
    "transaction_total_days": "730",
    "countries": [
      "GB"
    ],
    "logo": "https://cdn.nordigen.com/ais/BARCLAYCARD_COMMERCIAL_BUKBGB22.png"
  },
  {
    "id": "BARCLAYS_BUSINESS_BUKBGB22",
    "name": "Barclays Business",
    "bic": "BUKBGB22",
    "transaction_total_days": "730",
    "countries": [
      "GB"
    ],
    "logo": "https://cdn.nordigen.com/ais/BARCLAYS_WEALTH_BUKBGB22.png"
  },
  {
    "id": "BARCLAYS_CORPORATE_BUKBGB22",
    "name": "Barclays Corporate",
    "bic": "BUKBGB22",
    "transaction_total_days": "730",
    "countries": [
      "GB"
    ],
    "logo": "https://cdn.nordigen.com/ais/BARCLAYS_WEALTH_BUKBGB22.png"
  },
  {
    "id": "BARCLAYS_BUKBGB22",
    "name": "Barclays Personal",
    "bic": "BUKBGB22",
    "transaction_total_days": "730",
    "countries": [
      "GB"
    ],
    "logo": "https://cdn.nordigen.com/ais/BARCLAYS_WEALTH_BUKBGB22.png"
  },
  {
    "id": "BARCLAYS_WEALTH_BUKBGB22",
    "name": "Barclays Wealth",
    "bic": "BUKBGB22",
    "transaction_total_days": "730",
    "countries": [
      "GB"
    ],
    "logo": "https://cdn.nordigen.com/ais/BARCLAYS_WEALTH_BUKBGB22.png"
  },

But, overall, it's an excellent service. Now I just need to find / write something to ingest the data and do something with it!

Hand-coding YAML files is a mug's game; one wrong whitespace and everything is broken. Left a semi-colon off the end of a line of code; watch the compiler moan. Mixed up your ints, floats, and strings; the computer has a conniption.

This, frankly, is bollocks. And it isn't solved by having a better IDE gently putting danger lines under errant code.

It's solved by having tools which don't let you make that kind of mistake. For example, Scratch lets you drag and drop elements and makes it really hard to have a syntax error - even in complex code: (Snippet of MD5 in Scratch)

Scratch isn't perfect. It doesn't prevent you from making logical mistakes - but it makes it much easier to visualise and debug what the computer is doing.

I've long been a fan of the DRAKON programming language. It lets you draw a flow chart and then generate code from that chart. Sadly, the desktop software is rather flakey. But, there's a new interactive web editor. It lets you draw flow charts and immediately compile them into JavaScript.

Here's an excerpt from their demo Tetris game:

It takes seconds to design a flow chart and, after a single click, have it spit out relatively optimised JavaScript.

I think you should give https://drakon.tech/ a try. It isn't quite as slick as Scratch in terms of having a strictly defined set of "blocks" to use - but it is a much easier tool for creating conditional statements compared to hand-creating a bunch of nested if-else statements which branch off in a twisted mess.

Are there any other tools which let programmers visually design their algorithms?

I wondered how true that was. You can, perhaps, moan about the shenanigans around Java's licencing and you mutter about whether it is easy to get involved with C++'s JTC1/SC22/WG21 - but the core tech behind the two is open. Anyone can read the language specification freely and anyone can build a compiler legally.

It's the same with, to choose a random smattering, Python, F#, and even Apple's Swift.

Once upon a time, Flash ruled the roost. Now Flash is dead⁰. While COBOL existed before the term Open Source was coined, it is now an open specification with a GPL Compiler. Everything has become open!

But...

There is still a stronghold of proprietary languages. MATLAB is still heavily used by mathematicians and scientists. Languages like R are Open Source and making great in-roads. But MATLAB is popular.

The K Language is widely used in financial firms.

Excel Macros, inexplicably, run the world.

Local scripting languages like AppleScript, and cloud languages like Google App Scripts are also closed - and can only run on proprietary software.

In the gaming world - while Lua and Godot and Blender are open - Unity is the big beast. And that's closed.

And, deep down in the silicon, the microcode running on your CPU, the blob in your Pi's multimedia decoder, and the baseband of your phone's modem are all locked down tighter than a whalebone corset.

But...

Even in those closed gardens, the weeds of Open Source take root. There are hundreds of Open Source libraries, plugins, and tutorials for all proprietary languages. That doesn't get us to an open compiler or specification, but it brings the culture of Open Source with it.

So, has Open Source won? Mostly, I'd say. At the very least there are good Open Source alternatives to nearly every programming language and paradigm.

There are some niches - science, finance, gaming - which rely on proprietary languages. And Cloud services run custom software on their custom OS running on custom processors. The new paradigm of LLM AI might eventually be fully open, but rely on processing power so out of reach of mortals that it might as well be closed.

But as more and more students become aware of Open Source, I hope that those last bastions of jealously guarded code will eventually fall.

Got any more examples of proprietary languages? Join the discussion on Mastodon

The other day I had to fix a multi-line Regular Expression (RegEx). After a few hours of peering at it with a variety of tools, I finally understood the problem. Getting that deep into the esoteric mysteries made me feel like a powerful wizard with complete mastery of my domain. And I think that's dangerous.

I'm sure we've all read a story about a witch or wizard who distractedly substitutes eye-of-newt with iron-ute with disastrous consequences. Humans are easily confused. And confusion leads to unexpected mistakes.

Look, most humans are very bad at reading compiled code. Without any external tools - can you tell me what the following code does?

0000000 c031 d88e c08e 15be b47c ac0e 003c 0474
0000010 10cd f7eb 48f4 6c65 6f6c 202c 6f57 6c72
0000020 2164 0a0d 0000 0000 0000 0000 0000 0000
0000030 0000 0000 0000 0000 0000 0000 0000 0000
*
00001f0 0000 0000 0000 0000 0000 0000 0000 aa55
0000200

No. Of course not⁰. That's why we write code in a more human readable language and then compile it to computer readable instructions.

Regular Expressions are a sort-of halfway house. They're slightly readable by humans - but written in such a terse vocabulary as to be mostly unintelligible without concentration. There's no space for comments. Different engines have variable support for all their functions. They are a symbolic language with unhelpfully indecipherable and inconsistent symbols.

As a result, once the RegEx becomes more than trivially complex they're hard for most humans to understand. That makes them difficult to debug. It also makes it difficult to add or remove functionality.

I genuinely - and possibly misguidedly - believe that even something like ^\w+([-+.']\w+)*@\w+([-.]\w+)*\.\w+([-.]\w+)*$ might just as well be written in BrainFuck.

My contention is that almost all RegExs would be better served by more human readable code and that the very existence of RegEx101.com ought to bring shame on our industry.

Here are some positive use-cases for RegEx:

• You want to show off how smart you are.
• You need maximum efficiency when combing through a billion lines of text.
• You have a desire to build something hard to debug.
• You don't have lots of printer paper and need to make your code as terse as possible.
• You think if/else and switch/case statements are the mark of a diseased mind.
• You don't trust compilers.

I know what you're thinking: "This guy's too stupid to get regular expressions!" Yes. Yes I am. So are most people.

What I'm getting at is that source code is designed to be read and edited by busy and distracted humans. We should be writing intelligible code for each other and letting computers do the boring work of making it more efficient.

You don't have to agree with me. That's fine. But, perhaps you'll take note of the famous maxim from the "Wizard" book:

a computer language is not just a way of getting a computer to perform operations but rather that it is a novel formal medium for expressing ideas about methodology. Thus, programs must be written for people to read, and only incidentally for machines to execute.

Structure and Interpretation of Computer Programs

We are not wizards. Nor should we strive to be. The alchemists fell.

The obvious answer is that the humble keyboard usually only has around 100 keys - and most humans have a hard time remembering where thousands of alternate characters are.

Some programming fonts attempt to get around this with ligatures. That allows the user to type <= but have the font display ≤

Are there any modern programming languages which allow the use of semantically correct Unicode symbols as operators?

As far as I can tell, there's only one!

Scala

Here's a trivial example which creates the ÷ operator:

case class A(v: Float) {
  def ÷(b: A): A = A(v / b.v)
}
val a = A(9)
val b = A(5)
a ÷ b

According to the Scala reference documentation, valid characters for operators include "Unicode categories Sm, So".

That's "Symbols, maths" and "Symbols, others". That covers quite a lot of useful symbols. Including some Emoji! So you could have ☺ as an operator.

Try it in your browser.

Others

I took a quick scan through some other modern languages:

• Ruby
  • Ruby has a Unicode Math gem which lets you write code like ∛ 27. But, as far as I can tell, there's no way to create your own operators.
• Haskell
  • There's an extension for some Unicode characters. But there's not many there and no way to create new ones.
• Python
  • Nope. There's no way to create your own operators. And function names can only contain a subset of Unicode.
• C++
  • Nope. You can overload existing operators but cannot define your own.
• Go
  • No.
• Rust
  • Also no.
• Java
  • Nuh-uh.
• Javascript
  • WAT.

In fact, according to the inimitable Xah Lee the only other languages which allow user-defined Unicode operators are Julia and Wolfram.

Julia, I had some difficulty with, but this works:

☺(x)=sqrt(x)
print(☺(25))

÷(x,y)=x/y
print(25 ÷ 6)

I am, sadly, not clever enough to even understand the documentation for the Wolfram language.

What next?

Obviously I am now a convert to Scala and will henceforth rewrite all my code in it using multiple Unicode symbols.

But, more practically, I wonder if there's demand for a (new) programming language which treats Unicode operators a first class citizens? Or perhaps future versions of your favourite language should embrace the loving warmth of the Unicode consortium?

Thoughts?

How do human brains understand code? What neurological quirks do we all have? Which common mistakes can be easily avoided? Only by understanding our puny hardware ("Isn’t it a miracle that humans can do anything with no more than 1 byte of memory") can we understand how we should read, write, and think about code.

It is a relatively quick read - I burned through it on a 4 hour flight - but there are lots of practical exercises to do. And it is worth taking the time to think about the process of thinking about code.

Some of the insights are a little obvious - but it is worth spelling them out. For example:

when debugging, many programmers prefer to make small changes to their code (tweaks) and run it again to see if the bug is fixed rather than spending the energy to create a good mental model of the problem

It me! Why do I do that? Why do I think bashing around on a keyboard is more productive than taking 15 minutes to investigate my assumptions about what I'm trying to do - and what the previous programmer was trying to do? The book has answers - and some practical guides for helping you correct your behaviour.

Even "simple" things like naming conventions get a thorough examination, with plenty of academic references:

8.3.2 Snake case or camel case? The results of Binkley’s study show that the use of camel case leads to higher accuracy among both programmers and non-programmers 8.4.1 Code with bad names has more bugs Butler’s study found statistically significant associations between naming issues and code quality.

There are lots of footnotes if you want to go wandering into the academic studies - and there are many.

The book - rightly - throws a bit of shade on those of us who have got into bad habits, but haven't reflected on whether they're actually working for us.

11.2.5 Some thoughts on multitasking The interesting thing is that people who multitask often feel very productive

Ha! True. The book goes into the studies of why people feel the way they do - and whether the data bears out those feelings.

I urge you to read this book. If you are just getting started, it will help you develop good habits. If you're an occasional coder, it will keep you from straying. If you've been doing this for so long that your code is indecipherable to anyone else - it will give you a much-needed reality check.

The book is available DRM free from publisher in PDF, ePub, and Mobi. At about £25, it's probably worth charging it as a business expense.

Thanks to the publishers for the review copy.

Most programming languages have the concept of relational operators. How does variable X compare to variable Y?

If we want to ask if X is less than or equal to Y, we write X <= Y. Which is a bit weird, because Unicode has a "less-than-or-equal-to" character: ≤. But because there's no button for that on a standard keyboard, we use a hacky solution of jamming two characters together.

In the R language, the assignment operator is <- this is because programming keyboards used to have a ← button on them. That button has gone from modern machines, so we make do and mend.

There are some programming fonts which contain ligatures to automatically convert these characters (although this makes some people very grumpy).

Unicode includes ⩶ (U+2A76) and ⩵ (U+2A75) as distinct glyphs. So why are we still hitting the = key multiple times like savages?

This leads to the deeply weird situation where "⩵" ≠ "==" and absolutely no programming language that I know of will let you use the correct Unicode characters!

(Except, of course, Raku - which made this change based on my suggestion.)

Ideally, we need programming languages which support Unicode symbols as first class characters, and keyboards with a hundred more buttons.

It's trivial to create a palindromic program in, say, Python:

print("hello") # )"olleh"(tnirp

Save that as test.py and then run cat test.py | rev | python3 and it'll work. But that's boring!

You could do the same by reversing the bits, rather than the characters:

01110000 01110010 01101001 01101110 
01110100 00101000 00100010 01101000 
01100101 01101100 01101100 01101111 
00100010 00101001 00100000 00100011 
00000100 10010100 01000100 11110110 
00110110 00110110 10100110 00010110 
01000100 00010100 00101110 01110110 
10010110 01001110 00001110

That requires a bit more bit-bashing to run properly. And, if I'm honest, I think padding stuff with reversed comments is cheating.

Is it possible to make an executable assembly program which can be read forwards and back?

Alex @regularfry@mastodon.social Young

@regularfry

Replying to @edent@edent Related question: are there any paper tape programs which are valid when taped end-to-end as a mobius loop?

---

I always used avatars.io - but sadly that service has bitten the dust. So I've switched to unavatar.

It's dead easy to use. https://unavatar.now.sh/twitter/edent will return @edent's avatar. You can use GitHub, Facebook, Gravatar, Instagram, Telegram, YouTube, SoundCloud, and a couple of other providers.

Simple to use, and easy to embed in an <img> element.

It's also open source and looks pretty easy to deploy if you want to host it yourself.

Why is this needed?

In an ideal world, there would be a standard for where to find a user's avatar. Possibly a .well-known resource. Until then, we have to make do with 3rd party services playing intermediary.

Or, you could go down to your local newsagent, buy a magazine, and laboriously hand-type in a code listing. Sometimes, they would look like this:

Yikes! Ah, but they were simpler days...

I recently rediscovered an old issue of a British microcomputer magazine called "Input". It contained code listings for several popular machines. Here's a sample:

See those little icons beside each code listing? Here's what they meant:

Thirteen different computers with seven different programming languages. They share some common syntax, but not much. The commands are terse and unintuitive. But are things any better today?

A properly written Python3 program will run on Windows, Mac, and Linux - whether it's an expensive desktop or a pocket-money Raspberry Pi.

Or you can write in Go, Java, PHP, Haskell, Ruby, JavaScript - and many others that I'm not cool enough to know.

I know why we have different programming languages - but it sometimes seems that we're making life unnecessarily hard for ourselves.

"But why do I have to learn Python?" She wailed, "I like Scratch!"

"I know," I said, "But there are different programming languages for different sorts of tasks."

"That's stupid" she said, with all the perception of 6 weeks Code Club experience. "You can do everything in Scratch."

I found it hard to argue with the twelve-year-old - you can do just about anything with the child-friendly Scratch programming language. You can even build an entire Operating System.

Here are some analogies, of increasing complexity, to try and describe to a non-technical person why we have different coding languages.

The Orchestra

A guitar and a violin are both stringed instruments, but they make very different noises.

You can hit a guitar with a drum stick, but playing a drum kit is easier and produces a wider range of percussion sounds.

Sometimes, you just want to do one thing and do it well. Playing the Triangle gives you one sound, consistently.

You can, of course, use a synthesiser to play more-or-less any instrument. But synthesisers require you to play everything on a keyboard, and they are complex instruments to understand and learn.

Different programming languages are usually specialised to particular tasks. Sure, you can build a 3D adventure game in Excel, but it is easier to use the right tool for the job.

We learn and evolve

In 1934, a young Alfred Hitchcock released "The Man Who Knew Too Much". A tense thriller which opened to worldwide acclaim. In 1956 he remade it.

The newer version doesn't just have a more technically advanced production - Technicolor! Hi-Fi sound! Widescreen! - it has 20 years more film-making experience behind it.

The same is true of programming languages. As we learn what computers can and can't do - and how humans like to work with them - we build new languages to take advantage of that knowledge.

Man's monstrous ego

Some people just want to create something in their own image. Someone, somewhere, didn't like the way one programming language handled certain features - so they split and created a new language.

A cult can develop around a charismatic leader. Entire conferences can be dedicated to obscure languages which attract acolytes. Each convinced they've found the "one true way" to program - and that everyone else is heretic scum.

Humans, eh?!

A counterpoint

But, you don't always need to use the right tool for the job.

My favourite example of this is colour recovery from black-and-white TV broadcasts. How would you take a B&W film and recover the colour information from it? Not artificially add realistic colours.

Perhaps you'd use OpenCV? Experimental C++ bindings? Write some AI tool to burn through parallel GPUs?

Nope. A dedicated team built an accurate program in 3,400 lines of BASIC!

Because the world is round

Is poetry more romantic in French? Is Shakespeare best performed in the original Klingon? Is demon summoning most effective in ancient Latin or Sumerian?

Some of these are a matter of taste. Some are just what we are used to. And some are just tradition.

Computer languages are an abstraction. We don't want to deal with the messy business of flinging electrons around circuit boards. Different people have different preferences for how they like to code.

Perhaps, once everyone has finished rewriting their websites in flavour-of-the-month JavaScript frameworks, we'll see a renaissance in hand-crafted bits and bytes.

Or, just perhaps, the next generation will rewrite everything in Scratch!

Do You Want To Phone A Friend?

A popular website asked me to confirm my phone number. It "helpfully" pre-filled the country-code with +1. And proudly displayed the Stars and Stripes.

Except, of course, the USA isn't the only country to use +1 - our friends in the Great White North also use +1.

Thanks to the North American Numbering Plan, a full 25 countries or territories use +1. From Anguilla 🇦🇮 to Turks and Caicos Islands 🇹🇨. OK… their flags look pretty similar! But they're obviously different from 🇺🇸!

Canada 🇨🇦 and Jamaica 🇯🇲 have very different flags - and climates - but they both use +1.

I suspect that the website designers were expecting people to look at the flag and realise that it didn't represent their home country, and then change it. However, for the majority of +1 countries which aren't part of the United States, it looks a little crass.

My home country, the United Kingdom 🇬🇧, uses the +44 code. As do Guernsey 🇬🇬, Jersey 🇯🇪, and the Isle of Man 🇮🇲.

The UK is comprised of Scotland 🏴󠁧󠁢󠁳󠁣󠁴󠁿, England 🏴󠁧󠁢󠁥󠁮󠁧󠁿, Wales 🏴󠁧󠁢󠁷󠁬󠁳󠁿, and N.I. (with a more complicated flag status!)

People can have a complicated relationship with flags. Your glorious banner of home might be my symbol of a conquering despot.

Flags change. Afghanistan's flag has changed 4 times since the year 2000.

Some flags are not recognised by other countries.

Flags represent countries, states, territories, and pirate ships 🏴‍☠️ - but they do not represent international dialling codes!

Lingua Franca

Lots of countries speak English. But the majority of them don't have 🇬🇧 as their flag.

Indeed, lots of people in the UK don't speak English. So using a 🇬🇧 to indicate language choice may be confusing.

If you are in South Africa, there are 11 official languages. Does 🇿🇦 represent Xhosa, Zulu, Afrikaans, English…?

Flags are for golf courses ⛳, motor-sports 🏁, and for Pride 🏳️‍🌈 - not for representing languages.

Do You Have A Flag

I'm pretty sure the law requires me to share this video…