A Tool For All Seasons

This device hailed as the "mother of all Swiss Army knives" has gone on display - featuring more than 100 tools including a GUN. See SWNS story SWSWISS; The incredible multi-tool boasts everything from a piano tuner to a .22-caliber revolver. Owned by the Smithsonian Institution and on display at the Buffalo Bill Centre of the West in Wyoming, USA, the 'handy pocket knife' is just the tool for the typical 19th century gentleman. It includes a serrated blade, two dagger blades, several different types of shears and scissors, a corkscrew, two saws, a lancet, button hook, cigar cutter, tuning fork, pens and a mechanical pencil, mirror, straight razor, a cheese fork and a butter knife.
(Source: the Daily Mail)

When I was young, every boy wanted a Swiss Army Knife. You could have hours of fun just opening each of the tools one by one and figuring what they could possibly be for. Only a privileged few, however, could dream of owning such a thing; the cost was way too high. The rest of us made do with regular single or dual bladed models, covered in dents and chipped paintwork.

But looking back now, I recall that it was the cheap knives that got to do all the work. Because a Swiss Army Knife, though artistically beautiful and superbly put together by craftsmen, couldn't possibly be used for any real work, partly for fear of spoiling its pristine beauty but also because it was just too damned cumbersome. It was the idea of using the thing that sold it, not the likelihood of it ever being pressed into service.

Fast forward a few decades. Swiss Army Knives still exist and they have their counterpart in software, the most impressive example being JavaScript and its multitudinous frameworks. You get everything, including the .22 revolver so handy for shooting yourself in the foot (yes, check the photo). But when you come to actually use it you spend more time wondering what each feature is for than actually doing something useful with it.

Something else changed in the last couple of decades. A new breed of supermarket arrived, with a limited range of products but low, low prices. You know who they are. And one idea they brought with them keeps customers trooping in faithfully every week; its the section that has non-grocery items where the stock is different every week. It can be anything; today it was a big column Bluetooth loudspeaker and a compressor with a pile of accessories, while the rival supermarket up the road had table-top ovens and strange multi-cookers. It's one of the highlights of the week, to go in and see what goodies I might be tempted to buy if I had space to keep them all. (Don't tell me to get a life - this is my life.)

These random special offers sometimes include something that's actually useful. Most of my favorite tools came from one of the UK's two main budget supermarkets and I'm rarely disappointed. An electric sharpener for chain-saw chains (that's hard to even say), the above-mentioned oven (a great plate warmer if nothing else), electric drills, routers, an electronic balance, torches, a super-soft bed for the dog etc. etc.

What I'm leading up to is the contrast between these items, most of which do just one job, and the venerable Swiss Army Knife, which looks like it can do almost anything but which doesn't quite achieve it.

Let's leave knives and supermarkets behind and focus on software. There are two kinds of programming language; general-purpose (GPL) and domain specific (DSL). GPLs like C, Java, Python and JavaScript can do anything, but using them carries a cost, that the parts you aren't using often get in the way of the ones you are. Just like the Swiss Army Knife, in fact. DSLs, on the other hand, are built to do one job and do it well, and they are hopeless at doing anything else, like painting your house with a toothbrush. The best-known DSL is SQL but there are many more of them, largely unknown to all but specialists.

When you look at it you can see the world itself is not general-purpose; it's composed of domains. Thousands of them, each with its own variant of language and a bounded scope. GPLs can be used for all of them and a lot of very clever people do use them for everything, so the conventional wisdom is they must be used for everything. That's what we're taught in school - the right way to do things. If you do things the right way you'll be able to apply for all those positions that ask for Node.js, React, Angular and Vue experience, so if your livelihood depends on landing a well-paid programming job you'd better cram those courses.

Trouble, is, it's getting harder. We're on an accelerating curve of product obsolescence. No sooner have you learned the current technology than another one comes along and everyone starts shouting about how it's so much better than the one you just invested a couple years in. And now you don't have time to learn the new technology because you're up to your ears in a project using the old one, and it's really a full-time job just learning enough about these things not to sound like a complete numpty.

And that just us programmers. How about the poor customer, trying to decide - with so little to go on - which technology to ask for in the hope it won't be obsolete during the life of her new website, because hiring help after that will be so expensive she may as well start again.

People for whom SQL is the answer don't have these problems. They just use SQL, which everyone understands whether they are programmers or database managers. 'Understand' at different levels, of course, but you can still hold intelligent conversations about it. When was the last time you talked your client through an important aspect of your React solution without seeing his/her eyes glaze over?

I don't understand what there is about any website that is so complex it needs the whole of JavaScript and React to handle it. I really don't. A website presents HTML and responds to user clicks - that's about it. Modern ones might be single-page, so you can add in a bit of JSON and REST, and some have special components like a Google Map, but apart from that the logic is simple enough to express in English. So why do we code it in a way nobody - not even our future selves - is ever going to be able to understand?

OK, so your website might present lots of different kinds of block, all doing different things under the management of some central controller, but to me that doesn't suggest the need for a huge monolithic edifice of code. To me it suggests a number of independent code modules that are loaded as needed and which communicate by sending JSON messages to each other. If your programming language can't do that cleanly you're using the wrong programming language. I don't care if it's the world leader - it's just plain wrong, not fit for the purpose you're putting it to.

So that's why Here On The Map exists; to provide evidence I'm not just promoting unicorns. It's single-page, 100% front-end code driven and there isn't a line of JavaScript nor any HTML in the whole thing apart from one DIV to hang the entire structure on. The site shows a live Google Map and lets you put pins on the map that when clicked display articles about the location in question. Anyone can use it - you have to register and log in to be able to create pins so there's a user management module, a rich text editor for the text and a file manager for uploading and managing images. Not all of these are my own code - the map is obviously from Google and the text editor is CKEditor - but these are just standard JavaScript libraries and all I'm interested in is their APIs. Everything else is done in DSL script that looks like simple English commands, with no special symbols, so you can actually read the code out loud without sounding like an idiot. There's a small PHP REST module on the server to handle database access and the compiler/runtime engine is another standard JS module.

Here On The Map runs on WordPress and it includes information pages with annotated listings of each of its component scripts. It took less than a week to get it up and running and another week to tidy it up to be presentable. If anyone thinks they could do it with React in less time and can produce code that will be understood by a non-programmer, I will be most impressed.