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 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.



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, , 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 | Leave a 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


This post is a response to a question on twitter from M Eifler
What real [experience] do you have with the puppets?
I’m a complete amateur, trying to teach myself puppetry.
I’ve done some voice practice, something I find rather unnatural.
I even found it really awkward when I reassigned decades ago.
I’ve learned the basics of animating the puppet, but am probably terrible at it.
If I were learning guitar, I’d be at the stairway to heaven stage.
So, my real robotics experience is mired in the place much robotics research is –
whatever you want to be doing, you spend most of your time actually working on stripped gears.
I’m building a robotic snail, Pomatia. They’ll be the primary platorm for all this.
I expect to have Pomatia in a state to start using them later this year.
Right now they’re missing a head and some innerds pieces.
Stand by for news.
In the past, I worked on the R-25 robot for RoboKind. We developed curriculum around the robot.
Sensory limitations really limited what we could do with it. I’ve made sure Pomatia has a rich sensor suite.
I’ve spent some time studying puppeteers. One interesting conclusion is that they
get a lot of expression from the often limited morphology of the puppets. This has
influenced me to not try to cram dozens of axes in for social response.
I’m excited by Topo Gigo, and by some of the Jim Henson work. The former because the motion so much defines the character, and because Topo Gigo works so much outside the proscenium arch, and the latter because they get so much character from puppets that actually have quite rigid morphology.
On a larger scale, I’ve found material made for teachers using puppets in the classroom quite useful. Some local grade school teachers have been helpful. One uses puppets in her classroom.
My process is like a tuba made of macaroni and felt. We have the capability to make nearly anything on the robot in house, so, while there’s a considerable amount of planning in something this complex, it’s not as pre-planned as if we were shopping things out.
 So, that’s where I am. Stay tuned for more snailish fun.
Posted in Uncategorized | Leave a comment

Why Enthusiasm is a Bad Thing in a CTO

Bob, a property owner, is talking to Sally, a woman he’s just hired as a gardener.

So, just keep the grass mowed and watered and the lawn edged and that’s it.

There’s usually cold cokes in the fridge, we’ve got a brand new lawn mower. If you get hot, feel free to use the patio or come inside for breaks.

“Hmm”, thinks Sally, “This guy’s not too bad.”

Sally gets to work. She’s mowing away when Bob comes out to get the mail. As he’s going past, he stops to ask how it’s going. As he leaves he points at a strip along the street and comments that they used to have tulips, and maybe they’ll put some in again.

Later on he runs a short errand. As he’s walking out to his car, he stops to compliment her on the nice looking job, and says some day he’d like to put in a hedge. He’s got a nosy neighbor.

When he comes back, he’s thoughtfully brought her a cold coke. He also stopped off and bought a couple hedges.  Can Sally put those in for him?

The trip to the nursery gave him a great idea – what if they took out the gravel along the walk and put in a vegetable garden?

Sally finishes the mowing and is edging when Bob comes out with an article he’s printed out on xericulture. Maybe they should be ecological and replace the grass with….

But he’s talking to the wind. Sally’s long gone.

Scope creep.  We all know about it, we’d never do that, right?

Bert’s CTO of XyzzyCo.  He’s just sent out an all company email about how cool FizzyFoo is. Yesterday he sent out one about TireFyre. Last week he announced a plan to change the company database to NumNum. The week before that… Oh, I don’t remember.

Bert really enjoys learning about new technologies. He thinks it’s the most enjoyable part of his job – a real relief from the day to day grind. Speaking of which, he’s due in that meeting about why the team’s not advancing on it’s roadmap. Probably there’s going to be grumbling – there always is.

Maybe he can cheer them up by telling them about the new methodology he read about in a magazine and wants to implement.

Scope creep by enthusiasm. Insidious version of this.

This can particularly be a problem in AI-ish circles, where power often does come from several weaker systems. Instead of making what we have work, we add Tensorflow or Watson or Flubbycalc without  actually thinking the problem through.

And ‘enthusiasts’ are often drawn to such things.

Additionally, it’s difficult to prove that we don’t need XYZWord in our NLP project. But wiring XYZWord into the project is probably not where we need to be. Improving testing and validation, and then improving ability to meet tests in a thoughtful manner that handles many cases is the road to salvation.

The problem isn’t choosing cool technologies, t’s changing them. If you choose new and “cool” technologies at the beginning of the project, fine, if you keep using them and not try to replace them with something “cooler”.

Methodologies can become ‘enthusiasms’.

A friend tells me he was working on a project where they had a comprehensive set of format rules, and enforced them strictly.

During the project, the team kept arguing about the rules and changing them. Whenever there was a change, they’d reformat (by hand!) all the code.

Code format and conventions were strongly emphasized over functionality.

Of course the project went nowhere, and eventually my friend left.

So it’s not just change. It’s also being more interested in the tech than in the problem.

In summary, some ways enthusiasm is dangerous:

  • Scope Creep – seeing the cool project without seeing the cost
  • Technology enthusiasm – being more interested in playing with the technology than in getting to ship.
  • Faddishness – changing technology horses mid stream
  • Artistic sensibility – being more interested in your api design, code conventions, methodology, cool language, theoretical advance, or vaunted expertise than in shipping useful stuff.

Thanks to RLa who provided a lot of thoughtful discussion of this article.







Posted in Uncategorized | Leave a comment