Why Learn Prolog Now.

SWI-Prolog is holding a MOOC promising to bring students from zero to competency in logic programming in 8 weeks.

Here’s the signup link.

Do this.

In the 40+ years I’ve been programming, I’ve rarely predicted future trends publicly. I’m predicting now: Prolog’s time has finally come.

Prolog has historically been a language of abstract CS research.  The most cutting edge ideas in programming languages often are first implemented as ‘this weird variant of Prolog’.

The industry has finally woken up to, as Kurt Lewin put it, “There is nothing as practical as a good theory”. Formal verification is an in-demand skill (partly because of the cryptocurrency boom). Being a type weenie has become a

I’ve tried to organize a course like this several times. It’s varied from a small affair with a few students to no interest. Now I have over 300 students.

A few years ago it was impossible to get a job as a Prolog programmer. Now there’s actually a small shortage of good Prolog programmers.

The swi-Prolog site usage shows a hockey stick.

Incidentally, if you need a Prolog programmer, I’m looking for work. Drop me a line at annie@theelginworks.com


Posted in Uncategorized | Leave a comment

Choo Choo’s, Protective Shells, and layered architecture

Train crashes are bad things.

So the railroads, early on, introduced systems for deconflicting trains. This started with putting the whole railroad in a critical region (one train in steam) and progressed through an increasingly sophisticated system that depended on dividing the railroad into blocks and allocating each block to only one train at a time.

It’s a fascinating subject, but not the one I want to tell here. I want to talk about the other part, what happens when the trains came to a junction or station with more-or-less complex track.

Trains switch track on switches. If the switch isn’t set correctly, the train can run the ‘wrong way through the switch.

Here’s a switch. Trains go to the right because the ‘points’ (the sharp, pointy rails pointing at us – the moving parts) are over to the left. Move the points to the right (they’re tied together with the small bar in foreground) and the trains go left.

But, what about a train coming at us from the left track?  It will derail.

So it’s important that the switches are set properly.

And if you have something like this, it’s also important that the direction the switches are set doesn’t run the train onto a track where it can crash into another train.

Finally, you can only run trains through tracks at certain speeds. Image result for passing siding

(image courtesy Blair Kooistra)

Here’s a switch where the curve on the left side has to be travelled a lot slower than the mainline right side.

But wait – there are also signals – we need to control entry of trains onto sections of track, we use signals.

And having a car roll onto the main line from a siding can cause a bad wreck.

So, wherever this can happen we add a ‘derail’, a steel casting that clamps over the rail and derails anything going over it. Swing it away to permit passage. Those need controlled too.

The original control scheme involved a “signalman” (many were women, often running a rural station was a couple job) pulling levers that pulled on lengths of pipe running on rollers on the ground.

(courtesy Wm. K. Walthers)

Here’s a model of a typical signal tower. The signalman was upstairs and had good visibility  down the track. In fron of the station is some of the bell crank and pipe apparatus.

This worked, but depended on the variable skill and thoughtfulness of someone doing a boring job. The consequences of mistakes could be terrible. So the railroads began implementing logic they called ‘interlocking’.

Here’s the inside, with the levers. Notice that the levers have a small grip on the side. To move the big lever, you squeeze the small lever, that unlocks the big one.

At the base, there’s a mechanism that locks the other small levers when one is squeezed. So only one large lever can be moved at a time. Critical region.

If you look back at the model picture, in front of the switch tower is a flat black box. Inside is the interlocking frame, a mechanical logic circuit with bars that slide, a layer of vertical sliding bars, and a layer of horizontal sliding bars under them.

The vertical bars connect to the levers. Notice the notches in bars and ‘bumps’

The bumps are attached to the horizontal bar underneath. Moving a vertical bar A causes the horizontal bar to slide as the bump moves out of the notch.

But if another bump on the same bar is against a vertical bar B whose notch is out of position, the horizontal bar can’t move, so vertical A is locked.

Related image

(diagram courtesy Clive Feather)

On the left the upper horizontal is forced left by vertical 3. This locks vertical 1. The lower horizontal is free to slide. 2 and 3 are free to move.

Now we move 3. This unlocks the upper horizontal, and locks the lower one. We can no longer move 2, but can now move 1.

So we have a strange logic, where we we establish an allowed initial state, and then prohibit transitions to states we don’t want.

And this works, but maintaining all the moving pipes and frames and such is a nightmare. The mechanical frames are eventually replaced by relays.

But the engineers are very conservative. They want to retain the one good quality of the frame system – that it acts not as intelligence, but as ‘don’t do that stupid’. So they retain the signalman and the levers, but replace the frame itself with these relays.

Eventually, this tech also becomes obsolete. In the 1980’s we still had the same expensive employee, the crazy Frankenstein movie relays, and people were saying “replace it with a microcontroller”.

Still being conservative, the engineers replaced, not the relays, but the levers. The microcontroller throws levers just like a human, and in turn it’s logic is checked by the relay circuit.

And to this day that’s how interlocking’s done on the railroad. With two layers – one to implement the business logic, and another to protect the system from business logic errors.

Incidentally, found this great dissertation while researching this post.










Posted in Uncategorized | Leave a comment

Maddening sticky bit

Ever have a maddening situation where you can’t read a file you should be able to?

See if the sticky bit is on. ls -al and if text is blue and background is green, oops

might be in an enclosing directory.

if you can’t reset it, it’s probably because you have a tool that’s got some file locked – writing this because it just happened with some data files, I had one opened in open desktop spreadsheet.

First, ls -l has a stupid problem. Other writable directories show as black text on green background by default, and sticky bit directories show as blue text on green background, and anything on green background gets interpreted as sticky bit.

Fixable by adding this to your .bashrc

# change other writeable to something besides green background so it doesn't make think it's sticky
LS_COLORS=$LS_COLORS:'ow=1;35:' ; export LS_COLORS

Now other writable dirs are purple text on the normal background.

Suppose you really do have a file, foo, with a sticky bit set.

lslocks |grep foo

to find out who’se locking it





Posted in Uncategorized | Leave a comment

Labor Going Away? Not any time soon

I keep reading that “automation is going to make labor go away”.

It’s not happening any time soon.

First, my qualifications to say this.

I’m someone who owns a factory.  I’m half owner of The Elgin Works, a small factory we established precisely to experiment with a ‘different’ way of manufacturing. We have more of the flavor of a maker space, and my partner and I are both from tech.

Second, since the factory doesn’t support me yet, I have a day job working in AI. I work as a logic programmer in Prolog for Simularity, Inc, http://simularity.com/ , doing anomalometry.

Third, I’m at least somewhat well read in robotics, I’ve built many robots, and am building more now. I was once employed working on a social robot for RoboKind.

So, IMHO, we humans are going to be working for some time to come. I can see several reasons for this, but I propose a more compelling argument.

I’m going to look at a whole bunch of people in my life, what they do for a living, and what barriers there are to automating their job.

I’ll start with Abigail, who’se the superintendent of the local school district. Some of her job is paperwork,  but much of it is not – it’s a mix of administrator, manager, HR department, and paperwork. And with Bobbi, her admin assistant.

Now, It’s fairly obvious we can’t replace Abigail with a robot. We could replace a few of her paperwork functions with some computer system, but not that many. Her job’s simply too unstructured – give the contractor a tour of the building damaged last winter and get a bid, placate an irate parent, plan a special field trip with a teacher, organize a program for dyslexic students, participate in school board meetings, call law makers to explain the impact of a new law on school funding, … the list goes on.

Now, Bobbi could probably be helped by more automation. Much of her day is spent at a computer, filling out transfer forms, and I’m sure there’s lost motion in all of that. But making a web application more suited to her needs really doesn’t require any new technology – it’s a simple matter of programming. And since no one’s doing it, I’m going to assume the market’s being wise and that it’s not something profitable to do.

Now, yes, advances in software development should drop the constant dollar cost of making what she needs – but not that dramatically.

Further, Bobbi does a lot of other things. She’s the chair of the school board meetings, she knows where the Christmas decorations are kept, she did the initial calling around to get bids for contractors, she went shopping last week for a used truck to replace the one the district had that’s beyond repair. She monitors a class occasionally in an emergency, and proctors make up exams. And pretty much none of these can be automated.

Now we turn to my hippy dippy friend Charlene, who makes herbal potions and does healing massage and herbal therapy. Her herbal concoctions are made by pretty low capital methods, and I’m surprised she sells as much as she does, but I can’t see any sense in automating that process.

As for her massage, I’m sorry, I’m not letting a robot give me a massage. Human contact is part of her job.

Dexter’s responsible for keeping a large e-commerce site up, as a DBA and NOC team leader. His job can’t be automated because it already IS as automated as they can make it.

Ernie’s a sculptor and metal caster. While there are ways to automate metal casting, they come with increasing ‘set up’ time – the time between when he starts working and when the first part comes out.  For a special one-off sculpture of the city founder, that’s not an advantage.

Now, we could replace the whole process with some 3D printing advancement. But I don’t think people want a 3d printed bust of the city founder. They want a rich bronze statue. And the 3D print would require a 3D model. But Ernie’s skills are in clay and metal, not in 3D modeling.

There are people who are skilled in 3D modelling, but Ernie brings other skills to his work. He can make the old man look stern, determined, or, if he’s less skilled, tired or wooden. This is why we call Ernie an artist.

Fallon’s in high school, and her dad thinks it’s better to find jobs kids can do for pocket money than to give them an allowance. So she does some small tasks around the factory. Sometimes the only point to the tasks is so her dad can give her some money.

Glenda’s a minister. She’s assured me that it doesn’t count to have the Eucharist celebrated by a robot.


Harry works at the plywood mill. It’s a large quantity operation, and highly automated. But he spends his time doing things like repairing lights, repainting the office, looking for nails in incoming tree trunks, directing drivers, and helping to repair the machines when they break down.

Iggy runs the town gas station. I suppose we could make a robot to pump the gas, but Iggy’s pretty much got to be there to take the money and do small repairs. Oregon’s got a law that a human employee has to pump gas. In theory that’s just for safety, but it’s also a way to make jobs.

Josephine writes ficton. You ever read computer generated fiction? That one’s got a ways to go yet.

Kelly tends bar. Listening’s part of the job. Somehow, a row of soda machines putting out beers wouldn’t be the same. He’s alone there, so he’s the bouncer too.

I think you see my point. People are going to be doing people work for a long long time.



Posted in Uncategorized | Leave a comment

How To Do Ageism

Ageism is Easy!

I just love ads like “seeking recent college grad”. “Bright young engineer wanted”.  Exactly HOW is this different from “seeking white guy”, “Bright white engineer wanted”?

One day looking through the resumes HR’s forwarded us, I find one that looks interesting. Show my boss, he says “look at the graduation date”. It’s 10 years before. He’s been doing challenging stuff for 10 years. Boss frowns, shakes head.

I was first paid money to program in 1975. My resume, even excluding short contracts, paginates to 7 pages. I’m always advised to only carry it back 10 years or so.

But some of you seem to believe there’s no such thing as ageism. So, for you all, I’m writing a little guide to being ageist.

Believe that Good Programmers are Young

One year Strange Loop was held in the same hotel as a sports convention.   Both conventions attracted far more men than women.

It was striking that you could tell which convention people were attending by their age.

A great trick for getting a crude measure of popular perception of some group. Type it into Google images. Try typing ‘senior engineer’ – you get a page of photos of white men in hard hats. Now try typing ‘senior programmer’ in – you get a strikingly younger group.

I’ll admit, it’s often true that people are at their most ‘clever’ when they’re in their 20’s. But that’s rarely what’s most needed in programming. Good software engineers are willing to develop a good practice, exercise good judgement, have good work habits, have a breadth of understanding of the world, wide experience of software development in many environments, and have written a crap ton of code.

Think in terms of career track.

Anyone 22 is an intern. If you’re in a large corporation, anyone in their 50’s is the CEO or an underperformer. Remember, by looking at someone you immediately know their age, and hence know where they should be on the career track.

Uh, no. If you spent the last 8 years getting out of a refugee camp, or raising a child, or overcoming an illness, or caring for a sick spouse, you might be entering a career at any age.

I know an artist who was once college faculty, who has a child, etc. She started making kinetic, interactive art, realized she needed to program, learned to program, enjoyed it, and ended up working as a programmer for a company that does Kinect based kiosks. She’s definitely still a ‘junior programmer’, but rapidly learning. She fits none of the models of ‘bright young programmer’, but is the perfect person for the job.

Assume that everyone wants a more complex, demanding job than the one they had before. After all, that’s almost universal for 22 year olds who may have only worked at McDonalds before. I’ve routinely been turned down for jobs just because they were less technically demanding than the last job I held.

Give out awards for ‘best researcher under 35’.

I found this on twitter within a few hours of writing this post.

I see a few of these each week.

Pigeonhole People


Assume that the older person is the boss. Well, until they’re too old, then assume they’re a loser who’se working because they can’t get by on social security.

Assume you can give orders or be paternalistic to anybody younger than you. Assume you know more too. Even if the young person’s a PhD you brought in as a consultant on the subject of their thesis.

This is especially fun with older women. Young woman in a programming pen – must be the new engineer. Late middle aged woman in a programming pen – must be the marketing person or secretary.

Walk into a meeting with a UX designer, a hardware engineer, a front end programmer, and a manager from another company.  Sitting at the table are an older white guy in a shirt and tie, a young white hipster-y looking woman, a white woman in her late 30’s or early 40’s wearing a suit, and a young black man in a T shirt.

I’m sorry, in real life almost none of us wouldn’t immediately start making assumptions about who’se who. And be really ‘suprised’ (we actually mean ‘disturbed’) to discover the young guy’s the manager or the older woman’s the hardware engineer.

Judge people based on how they dress or how ‘cool’ they are. After all, it’s a software development environment, and that’s important.

Promote Culture Fit

Make sure everyone the interviewee meets is the right age to be friends – with their son.

Take the engineering team snowboarding as a team building exercise. Many people in their late 60’s find snowboarding exhilarating.

Have a foosball table or other reaction time based game in the office. Having a game based on a physical characteristic that usually gets worse with age is a good way to communicate to the entire team that everyone is valued.

As an aside, you can make women on your team feel included by having a secluded corner where everyone marks the highest spot they can pee on. Or just make them go down 3 flights of stairs to use the bathroom.

Speaking of stairs, rent a cool loft office space in a fifth floor walkup. The extra exercise is good for people, and promotes meritocracy.

Hold a hackathon as a recruiting tool. Give people 72 hours, make it competitive, don’t have a ‘must go home/not work at night’ rule. After all, most people in their 20’s can pull overnighters, and almost no one else can. And people with families probably can’t do a whole weekend anyway.

Serve greasy pizza. Older people will handle that really well. Extend invitations to interview to the winners.

Frequently make last minute announcements of meetings and all-hands events at times outside normal work hours. This will make sure anyone who’s a parent is excluded.

Speaking of which – pay lip service to ‘work-life balance’ but reward putting in 16 hour days. That not only discourages the old farts, but makes sure women get out of the industry when they start a family.

Hire women based on their appearance. That way they’ll get into the industry, then wonder what went wrong as they get into their thirties.

Act like being out sick is a personal failing. After all, you and your twenty-something friends are all healthy most of the time.

Ask people to solve complex riddles or speed code during interviews.  Avoid asking questions that test actual engineering judgement.

Hire based on whether people would be fun to hang out and drink beer with.

Emphasize knowledge of all the latest frameworks. Don’t ask questions about engineering fundamentals.

Have an open-plan office. Maybe play music sometimes. Something light like Vanilla Ice. After all, playing music by a black man like Kanye West will make everyone feel like you value diversity.


If you have some engineering that absolutely, positively has to work, for goodness sakes, do not give it to the middle aged engineer who came over from the aerospace industry. Because, you know, airplanes are something where ‘fail fast’ is a good motto.

You probably don’t have engineering like that. Because shipping $3 million worth of big screen TV’s to a scammer in the Ukraine or being able to change the root password on the production server from your site’s login dialog aren’t big deals.

If you discriminate against anybody who isn’t a young, white, straight, cis, male in hiring, you dramatically reduce the pool of competition for your job. And you can spend easy work time complaining about how hard it is to hire good engineers.

Remember, anybody who has been in the industry for 25 years probably just wasn’t cut out to be a programmer.

Remember that 75% of specific technologies older engineers have learned is now obsolete. Of course that leaves the 25% that are aren’t. And those are more likely foundational. I think I’m on my 11th source code control system. I’ve got definite opinions on source control.

But do older engineers know the ‘new’ stuff? Well, by definition, nobody has more than a year’s experience with wizzyzam that came out last year. And yes, it’s tech – everybody learns stuff every day. (for the record, today I learned how to add a ‘skill’ to Alexa, and some stuff I didn’t know about I2C).

Sometimes they also know how things got the way they are (I recently used my knowledge of the Hayes modem instructions) isn’t important. After all, linux was invented in, what, 2005? I mean, ok, that’s old, but it’s not old old.

You like doing things your way – and your buddies like it the same. If you hire somebody older, they might disrupt your world view by suggesting, I dunno, that we load test the system before going live or some crap like that. Who needs that?

Your users aren’t you. So screw’em. Maybe the middle aged woman with the funny accent will remember that  not everyone lives on a 50Mbit low latency internet connection, or that your ironic use of the hammer and sickle seems less cute if you’ve lived under Bolshevism. Maybe she’ll be able to explain why your ad campaign targeting ‘gamers’ isn’t working for your family games site. That kind of thing usually leads to lots of boring work reducing bandwidth requirements, and can really harsh your vibe.

Beware of experience. You hire some old fogey, they’re going to point out that visual programming systems of the flow based boxes and arrows variety usually end up with problems as programs scale. If you’re clever, you’ll have a bunch of PL theory you can blather away at them why your system is different. Then at the next job, they’ll have watched six such systems fail instead of five.

So, don’t hire your mom to write monads! Even if your mom is an algebraic topologist.

Posted in Uncategorized | 1 Comment

Punch Card Game

I once wrote a multiplayer strategy game for the Honeywell 66/60 mainframe. Unsure of the date, but roughly 1983

It was played using 80 column Hollerith cards, on batch.

Seems like as good an excuse as any to explain how batch worked.

You’d use a keypunch, a pretty much non-electronic machine, to punch holes in an 80 column card. Each column was one character.

You’d then take these cards as a ‘deck’, and give them to an operator. He or she would put them in a card reader that would read them in. Usually it would be a few cards of instructions to a “job control program”, then your source code, then your data.

The computer would compile and run your program, which read the data and produced output.

Output could be in two forms. Human readable output came from the line printer – green and white barred wide paper with holes at the edges, fan folded.  Computer readable output was another deck of cards, punched.

All this would come back, after a period that started at over an hour, and decreased to where it was limited by the humans.

It had some aspects of a tangible interface. Cards were physical. For example, when you submitted your job you were handed the torn off end of a card, called a snumb, with a number on it.

When your cards came back, they had a card with the same number, in large ‘ascii graphics’ letters, punched into it on the front.  The printout’s front ‘banner page’ had the number. and if you had a punched deck, that did too.

Now, the game.

The game was a strategic simulation. One side played the US army air corps and RAF, the other the Luftwaffe. Each turn was a day.

At the start of the game you’d have certain resources – airfields, with some number of available planes and pilots of different types in squadrons. These were represented as a ‘situation’ deck.

You could assign any of these planes to training, to attacks, or to defense (plane takes off when incoming planes sighted) or CAP (plane circles waiting to catch something). Unassigned planes were maintained.

Each day the allied player would get a list of targets, and points for each. They’d plan out attacks by punching an order card for each squadron, with squadron, # of aircraft, time of takeoff, mission type, route as a series of waypoints on a map grid.

The German player did the same.

The players would put their situation decks, then their order decks behind the program, and submit the job.

A few minutes later the job would come back, with a printout for the allies and then one for the Germans. The Allied player would flip through the pages until they saw the German player’s ‘banner’ page, and tear the printout off. Hand the printout to the German player. Each player also got their order deck back.

There was a new situation deck for each player as well.

The Germans had more units to move around, but often didn’t need to move them, so they could just reuse the previous evening’s order card.

There was effectively a third player, weather – a weather deck got punched, and a current weather map printed out.


Posted in Uncategorized | Leave a comment

Ways of making a DSL

Someone asked on Quora how one did the equivalent of Lisp’s ‘dialects’ in Prolog.

My answer got long, so I’ve turned it into a blog post.

The ‘whole point’ of Prolog is not actually that it’s a logic language. The biggest thing Prolog does is to make it easy to modify the system so you can make it do what you want, not what some language designer decided.

Those changes can be roughly categorized as syntactic changes (why do I have to keep typing this?) and semantic changes (this would be easier if I could make cells, like Excel!).

Here’s some ways to make syntactic changes:

Declaratives – When code is consulted, any term that starts with neck (the :- operator) is executed at compile time. This means you can insert code that alters the compilation from that point on.

term expansion – If you find yourself typing boilerplate, have Prolog do it.

term_expansion/2 goal_expansion/2


Operators   – You can often make code a lot more readable by making an operator.  Often, you can implement a whole DSL by clever use of operators.


Parsing – If you really want to implement a full language, just write a parser. That’s easy to do in Prolog.

Using Definite Clause Grammars in SWI-Prolog

Quasiquotes – Quasiquotes let you say ‘and now for a little JSON/Python/Cobol/etc’ and change languages. The quasiquoter outputs some Prolog instead that gets inserted in the stream.

Here’s some examples of semantic changes:

And here’s some examples of radically changing the semantics to implement a DSL, sometimes only slightly varying the actual language syntax.  These are built using the syntactic tools above, but more radically warp the language.

Despite using the word ‘radical’ above, you shouldn’t be afraid of using them. They’re the right solution sometimes.

xpce – SWI-Prolog’s GUI lib is built atop an OO extension, pce


the SWI-Prolog native GUI library

You add a declarative that says, in effect, ‘this is pce code’, and a term_expansion that converts the pce code to Prolog. When it encounters another declarative, it removes the term_expansion.

cplint – adds probablistic logic to Prolog, a system for answering not only ‘what are the solutions to this?’, but ‘how likely are they?’ – I hear hoofbeats, it’s probably horses, but might be zebras.

cplint on SWISH — Probabilistic Logic Programming

(and there are a couple cplint related videos on playing with prolog – map making and Prolog goes to the movies)

constraint programming

CLP(FD) Constraint Logic Programming over Finite Domains

Some other examples: CQL, the R interface, there are a number of CLP(_) libs,

Code is data, so for example the web framework uses html//1 to embed a DSL to describe web pages for generated HTML.

CHR –  Despite the name, little to do with clp(fd). CHR is a way of writing productions in Prolog – ‘if this condition is true, this other predicate exists’.

KU Leuven’s page on CHR

SWI manual CHR section

Implementing Semantic Changes

Your basic strategies when implementing semantic changes are compiling and interpreting.

You can insert yourself in the the consultation stream and spit out prolog. That’s compiling. This strategy works best for things like ‘if someone opens a db query in a predicate, auto-close it if they leave that predicate’, or ‘look for this common incorrect pattern and fix it’.

You can meta-interpret. Write an interpreter for your language in Prolog, and run it.

Often you want to combine strategies. At consult time, make a term that’s easy for the interpreter to interpret, and insert interpret(MyTerm), then have interpret/1 do the needful.

Language features for semantics

There are two languages feature in SWI-Prolog that important for making semantic changes.

One is attributes. You can attach metadata to terms. This is how cplint and constraint programming work

The other is that Prolog is ‘hooky’. For example, when writing a library it’s best practice to print error messages by sending a semantic message, and installing a hook to print it. That way, if I’m using your library in my robot that speaks error messages in Japanese I can show your error message in “my” way without you distorting your API.

Printing Messages in SWI-Prolog

many things in the system can be hooked – Hook Overview

And there’s almost too many applications of hooks to mention – I’ve given out the advice that when finishing up some code, doing the usual deleting cruft, adding pldoc comments , etc. one should always look for places where behavior can be hooked.

All system activities can be hooked – so if you want to know when something is compiled so you can run some external process, or whatever, you can hook that.

And finally, sometimes structured comments are a good way to communicate design intent. Since the pldoc (prolog equiv. of javadoc) generation is done at compile time (the docs are served, not static web pages), the structured comment info can be interrogated. The pack mavis “mavis” pack for SWI-Prolog provides types this way.


Posted in Uncategorized | Leave a comment