Cubegeek

Closures in Go + Some Memories

Blah Abstract
So displaying my ignorance to the world, I am taking the chance that some of this will be useful as notes in the future. Being wordy, explaining things to myself is how it works. So, sorry to bore you if you already understand closures. Having a good teacher makes all the difference and right now my teacher is Mark McGranaghan.  I learned about Go about 7 years ago when I first left enterprise computing and started with open source. I was hanging out in East Culver City behind See's with dudes whom I should find again. Anyway. One of those dudes was excitedly talking about what golang was good for, and primarily it was about Google finding a way to stop declaring headers etc as they had been doing with C and C++. It made execution of everything 20% faster (at least). Since I always loved Pascal and static typing, I was inspired by that feature of Go. It wasn't baked at the time. In the meantime, even though all of the utilities of Vertica were written in Python, my fearless leader chose Ruby for our cloud-native development. I liked Ruby (then) over Python, PHP, JavaScript and all the other minor languages. I never liked Java, and I never had enough use for C or C++. So while it took a while to learn enough Ruby gems to be dangerous, I loved the elegance of the language, even though it was desperately difficult for me to distinguigh its regular syntax to the DSL that my boss was inserting into the code. As I started writing Ruby, I fell under the spell of building classes into an elegant (so I thought) higher level syntax. Others on my team made it very top down like scripting with no frills. While I was happy about using pry  for interactive debugging, I eventually consigned myself to needing JRuby to speed the bastard up. And of course by the time Spark came around and more 'data scientists' (one day I'll be more gracious) started sprouting wings, I had to defend Ruby against Python more often. 

While I heard this and that over the years about Haskell and Clojure, I tried to stay disinterested. But I definitely liked the idea of functional programming. I haven't really thought much about polymorphism or inheritance since the 80s. Funny, people still respect Smalltalk. While our engineering team was mastering Scala en masse, I was happy doing more stuff with JRuby and andvanced SQL in Vertica, not to mention the cool orchestration stuff I could do with Docker (now that we were done with Chef and Veewee and VirtualBox) and Terraform. Not that I needed to get into those weeds. We had dedicated heads for that. I remained focused on replication of complex business rules and workflows in the data governance domain. 

Now I'm rather sick of everything. So I'm doing Go for my own whatever purposes. I'm going to Go into the ground, like it was Java and C++ and C all put together. Which it is, as far as I'm concerned. Which means for the 3rd time, I'm going to recast all of my stuff into a better language. Hopefully for the last time. I will expect that everything will eventually have a Go translation, even Apache Beam which I care about.

Lede
Closures were easy to understand because I have had several situations where I was unable to articulate my need for exactly what they do and I wanted to do it. I can't remember precisely, but it was definitely a situation in which I didn't want to use globals but I felt stuck. Maybe when I see the old Ruby code I'll remember. I never got into passing blocks and yielding and whatnot, although I might have if it weren't for expedience and the convenient transom of my boss. But I understand closures now. Thanks Mark. 

Code
// p.15 closures

// a closure is a first class function that allows the use of free variables. You
// use a closure to keep track of a set of variables that are declared within an
// outer function. such that subsequent calls to the function can operate on that
// set of retained variables as if they were globals. They are not, however. They
// are local to the closure even after it has finished executing. The variable
// space is retained in the definition space of the closure.

package main

import "fmt"

func say_hello(msg string) {
fmt.Println(msg)

}

func return_anon_func() func(string) {
// return anonymous function
return func(msg string) {
fmt.Println(msg)
}
}

func int_seq() func() int {
i := 0
return func() int {
i++
return i
}
}

func main() {

say_hello("Hello")

func(msg string){
fmt.Println(msg)
}("Hello Anonymous")

print_func := return_anon_func()
print_func("Hellow returned from Anon")

next_int := int_seq()
fmt.Println(next_int())
fmt.Println(next_int())

next_int2 := int_seq()
fmt.Println(next_int2())

}

That pretty much nailed it for me. I will conform my language to the formality in due time. But I get it. Happy Happy. Joy Joy. 

A New Leaf

So today I decided to stop playing videogames. I may or may not go cold turkey, but I basically need to liberate more time in my life to do what I want to do technically which is to build stuff for myself. The secondary consequence is that I will stop reading literature. I may or may not go cold turkey, but this is a slightly easier decision. I simply have no more great desire to learn in the dimension of wisdom. So let's get on with it shall we?

Into those slots of personal entertainment and literacy I will require golang. So my aim is to immerse myself in this particular language and build up a library of data wrangling and data engineering tools. So I'm most likely to go and recode everything I've coded and move on from there. I simply aim to master the language, and be wordy in doing so. I'm happy to commit to it. 

That means a big deal for Cubegeek. It means I'll be switching a lot more attention to this blog and its subjects than that of Cobb. It will also mean things for my github repo. 

I expect to get all Apache, from scratchy and take the short term hit with a dearth of Python. And I probably won't do anything further in Ruby. Which of course kills me because I've been doing everything with Ruby for the past 8 years. What a pain. So as Joe Rogan would say, I'm eating that punch. 

It has been a while since I've been hermetic, but that's the plan. I will work for myself. I'm going to stop expecting other people to give me interesting things to do.

Three Years Later...Kafka

So it looks like I'm going to go back to heads down. That's a good thing, I suppose. The reason is that I get to learn something new. Yay. The thing I will be learning is Kafka streaming and all that I need to know about how to do Fast Data. And the good thing is that this will be very new - and I have to tell you that I never liked writing logic for commits and rollbacks in SQL. It just wasn't languagey enough. So I expect that within a few months I will be dangerous, and within a year I'll be first rate if not world class. My secret is my nose. I have a good nose for the pure flavor as well as strategic import. What I don't have are years to sit down in a fulltime gig and wait for my boss to ask me to do something interesting. Anyway. I need to write this preface in order to jumpstart the emotional part of this memory as I go forward so one day when I look back on my learning process I can say "Oh yeah I remember how shit I felt not getting that F job because they wanted somebody who was better than me at saying 'I live transactions'". 

Anyway, in order to add to this frustration. Here is me mumbling about Kinesis and Kafka in May of 2016 (wow that was a long time ago). 

At the time, I was very enthused about transaction processing. Here I wrote Dreaming about Streaming. 

A couple weeks ago I presented a webinar in which I discussed one of our realtime apps which is attached to online gaming. On the back end of this architecture we are processing about 30,000 transactions per minute with a small two shard cluster of VoltDB. This setup hardly makes a peep over 25% CPU utilization running 24/7 with no downtime in two years. Cool enough, but then you realize that is handling more mobile transactions per year than PayPal. I did the math. And oh what fun it is to do this kind of math and realize what's computable for the kind of analytic data frameworks we build.

And Transactions, The Final Frontier

I am newly aware of the idea of immutable data, but I have yet to work with such a designed data set. What I have seen are transaction systems that generate records that are overwritten to 'the latest state'. Consider the following idea. I have a plan. The plan meets my boss. I change my plan. The plan meets the enemy. I change my plan again. The plan meets resource constraints and a series of unknown unknowns and it changes yet again. It is finally set. Now comes the implementation, and something else entirely changes. This is a chain of events that are almost never conceived of in the design of the system expressed to generate the transactions. And yet we are called to audit and analyze such strings of transactions all of the time in our analytical applications.  Most likely thing that happens? Add an adhoc field to the end of the transaction and have humans interpret that at the end of the day. There have been seven alterations of the planned activity, but you only have three records. The initial plan, the final plan, the actual transaction. 

It is on this last point that I was particularly trying to express, recently, the idea that I had to go back and build window functions that created a new semantic layer in to post-processed transaction data and then output that to a user queryable exhibit. It would have been nicer, of course, to put that layer ahead of my DW consumer, neh? So now I should get the chance as we will be, as I said, 'cloudifying a mainframe'. In otherwords re-engineering an IBM MQ based message system with Kafka. This is actually something I've been wanting to do since.. NARDW. (for further reference, put date here.) NARDW was build in 2005? And it's when I scratch-built the workflow for 17 data marts in an ERP integration with IBM guys. 

So I've run some basics. I put together and then tore down AWS MSK and a client machine. I also put together a console producer and consumer for a test topic on a new machine in my home setup.  Now I've got a couple books to read. See ya. 

The Logos Project

For about 20 years I have been saying that I have 2 or 3 original ideas. Today I'm going to share them in one giant tarball. I'm going to call it the Logos Project. The reason I'm calling it the Logos Project is because of Jordan Peterson's big book Maps of Meaning. It was a very rambly book but it was one that lay behind all of my most profound interests. In one way you could say it represented a reconciliation between faith and reason, which is ultimately the combination of religion and science. What could be more fundamental to the prospects of Western civilization? The one Bible piece I've been able to quote was the beginning of the Book of John. In the beginning was the word. And it seems that many of us have abandoned the word, and that needs to be addressed. Social media falls short. We need to build logical media. We need to transform our computer mediated communications into something that serves the purpose of social maintenance of the commons. This is a management problem which is poorly served by the faint number of actions that social media spaces allow us to perform. We are trapped in Twitter because of what Twitter is, and because we have given it over to the builders of Twitter to be the masters of Twitter, Twitter doesn't belong to the people. Anyway, there are a lot of problems like this and the aim of the Logos Project is to solve each and every one of them.

 

This is something I'm ready to contribute to for the rest of my career. And at this moment I am particularly excited about the Intellectual Dark Web, in that they are finally doing what I've been hoping would be done. Of course I've been creating all kinds of content but I couldn't quit my day job. Now is about that time to see if I can integrate all I've been building and thinking into something both concrete and sticky. I'm sure I'll need others to help me pour the concrete, and this teaser is the sticky part. So please do check it out and put in your comments and criticism. 

Deep Variances in Essbase

(from the archives - Fall 1996)

In my travels, I have just come upon a neat trick. I've never seen it posted anywhere and it solves a problem I remember being unable to solve a few years ago.

Consider a simple model with a geographic dimension 5 levels deep, a measures dimension of sales, and a scenario dimension with actual, plan and variance. How can I get the model to indicate 'deep variances' without having to drill down to them if my high level variances are within spec?

Create 'red flag' and '%red flags' in the scenario dimension.

Let's say that I have a 10% absolute value variance tolerance set.

The member formula for redflag would be

if (@abs(variance%>=10)
    redflag = 1;
else
    redflag = 0;
endif

Create a 'neutral flag' member in the variance dimension and hardcode the member formula to be 1;

redflag% = redflag % neutralflag; (two pass)

geo	actual	plan	variance	variance%	redflag	redflag%
NY	100	115	(15)	(15%)	1	100%
NJ	100	97	3	3%	0	0%
CT	100	85	15	15%	1	100%
East	300	297	3	1%	2	67%

Notice that even though your high level variance is only 1%, 67% of your lower level forecasts are out of bounds with two red flags.

simple, neat.

What Should IBM Do With Red Hat?

Q: How does the Red Hat acquisition improve the IBM hybrid cloud offering?

A: I don’t think it particularly does. Not by itself. It’s very late for IBM to be trying something like this with one big fat caveat and that is that IBM strive to dominate the mid-market. That is to say that everything IBM has ever done with AS/400 has to die, right now, at IBM’s command. They need to stop supporting that operating system and make RHEL run on all IBM iron.

Then they need to reorient itself in the market and stop trying to make money on high end hardware until they can price it like clouds. In other words, they need to be able to sell two big IBM mainframes that run in a skanky environment and say that it can run 1000 containers simultaneously. That way you don’t have to go to the cloud until you outgrow that - and that path would be seamless. IBM mainframes therefore have to be drop dead rugged and shipped overnight in a container to any location with enough electricity. That’s attractive. That’s something nobody else will do. And that’s something that can be facilitated by a company the size of IBM. Why? Because IBM will finance the whole thing.

What IBM must do, in the end, is beat Salesforce.com. If it cannot beat Salesforce, then it has no business in the cloud. Because it cannot and will not beat AWS, GCP or Azure. IBM needs to master the downmarket as I said before[1].

Everything IBM must do with RedHat is make RHEL administrators and software devs feel like they have an inside track to a comprehensive set of cloud management APIs that give them a reason to stick with IBM for 5 years. That means whatever the IBM cloud looks like today, it had better port over to RHEL in short order and the RedHat people need to be really excited about that.

I don’t think IBM management is so courageous, and I do believe that the RedHat people are just going to be very happy with their stock premiums. I’d bet the best of them are ready to ride off into the sunset and that this purchase is their last hurrah. The alternative is that IBM provide an exciting vision that encompasses cloud, mid-market, devOps and big rugged IBM hardware.

IBM vision? Let’s wait and see, but if I see another animation of an MRI brain scan coming from IBM marketing, I’ll know they’ve run out of ideas.

 

 

The Carl's Jr Story

I actually have a story here. Let’s see if I wrote it down. Nope. OK So I’m long past the restrictions of the NDA. Here goes.

Some long time ago, we put up an analytic database feed against the POS transactions of several stores of Carl’s Jr. It was kind of surprising that nobody had ever done it before. But they were basically wanting to know who bought what food and when. When they finally did analysis on it, it not only told them what was their most popular items for sale but it gave them a very good idea about their daily traffic.

Prior to this, they only had daily summary data. We broke it down to 15 minute intervals during a day. Since the average store was open 16 hours a day, that obviously that produced about 64 times as much data as they ever analyzed before.

Now here’s where the magic happened. They used to hire people to work 8 hour shifts if they were full time and 4 hour shifts if they were part time. So you’d have a manager come in at 5 to open and work until 1 or 2. Then there would be a part-timer working from 5 to 9, then another 9 to 1, etc. The night manager would close the store at 10 and work till 11. Hard work. Until we did inter-day analysis on the bigger data set, we had no objective way to see what the managers and part-timers could kind of see, which was:

1. People wanted breakfast food past 10AM
2. People wanted lunch food before 10AM
3. People started eating lunch around 11, not just after noon.
4. Sometimes people were changing shifts during periods of high activity.

The last point was huge. Think about it. You’re standing in line to order and suddenly when there were two people at registers, one of them closes and it’s like sorry, time for me to go home. They fixed that right away.

Basically Carl’s ended up not only changing what food was served, but also hiring people for shorter periods. We proved that a store could be more efficient and profitable by having three managers in shifts that overlapped when foot traffic and drive-thru traffic peaked, which was not around the traditional times expected.

Remember also that entry level people working the morning shift were not necessarily trained to cook lunch or dinner food. Big difference. So essentially we changed the definition of ‘breakfast’ and found a much more efficient way to schedule work, that resulted in part-time staff getting cross-trained for multiple shifts which gave them more flexibility.

Carl’s went on to do other IT stuff too. They were a lot earlier than McDonald’s in allowing customers to swipe their own debit cards at the register. And if you know Carl’s, their menu includes all kinds of crazy burgers and Mexican food too. So training their cook staff to be flexible paid off. Their menu is a lot more flexible than others.

Human Memory is not Computer Storage

Steven Pinker is my go to authority in this. He explains something I now understand about how memory is ‘retrieved’. Part of intelligence is the way you organize information in your mind. The better you organize it, the easier it is for you to remember.

In fact, ‘memory’ is not memory, it is the active re-creation of ideas and events based on the way they were organized in the first place.

This has a great advantage so that you can abstract ideas and events and then deal with them as somewhat different versions of a basic concept. So if you become, say, a baseball play by play announcer, you don’t have to remember the path of every ball from the mound to the plate (which might take a ‘gigabyte’ of visual storage), you just say the pitch was a ball or a strike. I can say ‘baseball game’ and immediately (if you understand baseball) you have the context for a class of events. When you’re watching baseball and you don’t understand the game, you have to store a lot more information. When you understand baseball, it’s easy.

Another example is you are talking to a stranger vs you are talking to a friend. With a friend you have context, therefore less storage required. This is why two people who were at the exact same party will remember the same conversation differently. They hear the same words and sentences, but they make different assumptions about what the person speaking was trying to say. So you could have a third person describe motivations and then suddenly have an aha moment, “Oh that’s why they said that, I thought they meant..” People remember differently because interpret and organize context differently, and thus they re-create events differently.

The more associations you give a particular event or idea, the more ways it is accessed in your mind. If you associate songs, or smells or how your body was feeling, you remember better. If you have an experience with a framework of theories, you remember better. If somebody keeps telling you the same story and you can hear their voice telling you, you remember better.This is (simplistically) the way that the mind works with the brain being the apparatus. If an old person has a healthy brain, then nothing changes. But if they have a disorganized way of creating memories, it won’t make sense coming out.

So it’s really not about how much storage, but how efficiently ideas and events can be re-created based on their intelligent way of contextualizing such ideas and events. This is why intelligent people seem to have better memories or *more* memory even though their brains are the same size. Their context for performance of certain things is better, they can get ‘in the zone’ quicker. And scatterbrained people remember crazy stuff all the time. Same ‘memory’ different organization, different re-creation.

 

The New Driver's Ed

In the news is a story of a driverless fatality in Tempe, Arizona. In the dark of night, a woman walking a bicycle across two lanes of traffic was struck and killed by one of Uber's new autonomous vehicles. Behind the wheel was a driver who was momentarily distracted, probably by a tablet in his hands, while the autopilot of the car cruised along at just under 40 miles per hour and ran the poor woman down. The article I read about the story quoted at least two experts who said that the lidar equipped machine should have easily seen the pedestrian and avoided the accident. I was most interested in the final paragraphs. 

Raj Rajkumar, a Carnegie Mellon University professor and founder of an autonomous-vehicle software company that he later sold, suggested the laser sensor may have had a blind spot around the vehicle because of its position mounted on the roof. Still, he said, he would have expected the software to have reacted.

“Legally speaking, the pedestrian may be at fault,” Mr. Rajkumar said. “But mature, reliable self-driving vehicle technology would have done better by slowing down or changing lanes, and this major incident would have been prevented.”

I have been in the IT industry for decades and one of the most fabulously successful products ever was the iPhone. I've been using mine for 7 years. My mother has been using hers for 2 months and she gets lost all the time. She is computer literate, but a lot less so than I. The distance between what I can digest as a professional at this stage in my career and what ordinary folks can understand is the gap into which a great deal of VC money is thrown in expectation of aggregating many multiples of that in consumer spending. Yes, I have a very new, very advanced, very capable iPhone device in my pocket and I use it all of the time. It works exceedingly well for me because I am highly discriminating in my consumption of applications, and I know how application designers think when they are building for the iPhone. In that way I am immune to bad apps, and I don't get lost. Half of all wisdom is knowing what to throw away. Simple works best.

So while journalists will have ready access to founders and professors who will state what might be professionally obvious, pedestrians and the rest of the world are puzzled as to exactly what went wrong. I suspect as the story of autonomous vehicles grows, we will all find out sooner or later, most likely later. It has always been my opinion that as cars learn to pace themselves in traffic that we humans are going to have the hardest time understanding their protocols. Indeed the future of driver education will not focus so much on skills of the drivers as to understanding how cars have been programmed to think about themselves and about traffic. That's a long, dark and narrow road for all of us to travel. 

What's legal today ought to be perfectly obvious. We have had crosswalks for generations. We have had crosswalks in law for generations. These things are perfectly obvious because we've had a very long time to learn the legal and physical truth about crosswalks. Lidar? Not so much. There will not be human and animal analogs for the way lidar perceives or the way cars will communicate with each other. We will have to learn new concepts and adapt. Or we will simply have to drive. 

What is it like to drive in traffic with cars that don't have human drivers? We are going to have to change our perception. We know 'idiot drivers' and are quick to identify their idiosyncrasies on the road, because we understand human inattention. He's weaving like a drunk. She's obviously on her cellphone. He's obliviously blasting beats. She's a student driver.  He's an old man. But Tempe offers a perfect example of a driver unable to recognize his own vehicle's inattention. 

 I've been a gearhead all my life and am probably unusually attracted to and informed about cars given my inexperience in actually repairing them. So I am fairly geeky into racing and the skills associated with demanding driving. I will trust autonomous driving machines when they start winning rally races and drifting competitions. Analogously, when computers were only reliable in playing an excellent game of tic-tac-toe, the mastery of chess was the benchmark for intelligence. I think that's were autonomous cars are now, four squares of tic tac toe rather than just three, with three being mere cruise control and lane alerts. It ain't chess, and it's far from go. 

Here's the thing though. When machine learning figures driving out, it's still going to think like a machine and not like a human. That means there will be hacks and vulnerabilities machines will have navigating 3d spaces that we humans will have to study very diligently to understand. I expect a lot of that diligent conceptualization to happen at Carnegie Mellon, but not in DMV parking lots. We can only hope that traffic law changes very slowly. 

Dehumanizing AI On My Mind

Last week I was in Bogota again. It was less interesting than IAH. In Houston's new terminal I was accosted by the 'Stacked' business model. Stacked is a restaurant chain that got started here in Southern California several years ago. Their idea changed the way people were served. A hostess would direct you to a table at which a custom iPad had the menu. You ordered custom burgers, shakes and fries. You had no dedicated server, but a swarm of people would bring food and take empty plates away according to the instructions you pushed out of your tablet. You could order any time and add to your bill which you also paid for from the iPad.  At Houston, there were literally hundreds of custom iPads at bar seats and tables inside and outside of themed restaurants. The swarm of servers went 50 yards in all directions.

It was disturbing to me that this form of automation was replacing one of the most intimate human jobs there are, then again, airport food. But what was really annoying was the fact that the idle screen on each iPad had dozens of casino-style video games with their own currency you got from ordering food or could pay for with frequent flyer miles. Clever, I know, but sucking all of the society out of a transportation hub felt quite crass and dehumanizing.

I've recently written about where data mining fits in my scope of business decision making and it's very interesting. I like AI and machine learning, but I haven't gotten to the point at which I'm comfortable saying 'ML'. Most of my experience with AI comes from old theory (backwards chaining and forwards chaining), my understanding of Markov and years of experience in video game playing. These days I'm completing another romp through the giant world of Skyrim as a maxed out conjurer. I spawn AI companions in all of my battles, especially dramora lords. But let me recap where in the world of business computing AI / machine learning lives from my perspective.

So first let me recap that my interest is in augmenting the decision making capabilities of individuals and organizations. I think that in a large set of domains, there are data available that can be captured and processed into knowledge and actionable intelligence.  In the context of business, these are data-centric applications and in the context of business process management and transformation my aim is to enable 'data driven business'. In other words, after Peter Drucker, I am catalyzing the professionalization of business management by taking the seat of the pants guesswork out of much of it. Nevertheless, I recognize and respect how business leaders generate insights and visions of their business operations. So sometimes a good decision support system merely disciplines the accurate communication of performance indicators already known to the principals.  In the context of AI and machine learning, we can generalize that there are two kinds of data driven businesses.

A. Data driven businesses whose leadership knows what works and seeks to discipline processes.

B. Data driven businesses whose leadership is unclear on what works and needs to build or re-engineer processes.

Somewhere in the middle there is generally a margin for improvement. But those operating in relative data darkness closer to B, are more vulnerable to outsized claims about the possibilities provided by AI.

So without getting into a mountain of details, the most important thing that determines the quality of AI is the amount of data it has access to, and the size of the domain it is expected to perform in. What's changing, therefore about the nature of what AIs do is the scale of data that cloud native architectures are able to deliver. For example, speech recognition at Google is superior to that at Apple, especially when it comes to the context of asking for navigation directions. Apple famously kicked Google Maps out of its IOS offerings several years ago. Consequently Siri has some shortcomings when it comes to recognizing spoken street and city names as compared to Google's voice recognition.

When customers and prospects ask about AI in the cloud, I tend to push back. The first thing I want to know about their possible application is how well their data is managed in the first place. From my perspective, if you don't have a serious structured data lake up and running, you are probably not going to get a lot of value training your AIs. We are at the very beginning of AI, and those things that we have AIs for, we tend not to think of them as frightfully scary AIs. For example, probably the most mature AI in existence today is speech recognition. Think of all of the millions of people who have iPhones who have been speaking to Siri for years. And yet every Siri user finds its comprehension inferior to that of a 12 year old. That's billions and billions of transactions and Siri still can't recognize the name of the avenue just down the block. 'Del Amo' simply doesn't work in Siri, which thinks I'm saying 'The lommel'. What the heck is a lommel?

AIs can best be thought of as business models, and their capitalization is the data behind it. If you're going to have a sophisticated AI model, you need to throw a lot of data at it over time and you're going to have to know how to validate what it does.

There is an ugly undercurrent I perceive in the idea of replacing low wage workers with AIs. And I think it is instructive to think of 12 year old children in this regard as well. For there are dimensions of satisfaction and delight that people can take in the performance of young people that would be completely absent from a machine doing the same thing. So I guess I'll conclude with the following story.

In 2000, I went to the Sydney Olympic Games and sat in the at my apartment watching the long jump competition. As the competition began, we were treated to a short documentary about the introduction of an automatic pit machine that sat on rails at the far end of the sand pit. It's job was to level the sand after each jump. This had traditionally been done by volunteers in every Olympics past, but we were regaled by the story of the dogged determination of the engineer who poured his life savings into the project. After years of testing, he finally got his design right. Then came the problem negotiating with the Olympic officials to have it trialed. Finally he got the approval, here it was, ladies and gentlemen. In the afternoon of the first day of competition it rained. The 500 pound machine broke and required four people to detach it from the rails and retire it causing a 45 minute delay in the competition. Now the officials had to find somebody with rakes and sand, something a 12 year old boy would be honored for life to do.

People ought to be wary of the machinations of clever engineers in their ability to take honor out of work and give tasks to machines, especially when it is something that uses poor substitutes for human intelligence. When we take human beings out of what could be honorable work we depopulate social spaces and make them sterile and mechanistic. There are appropriate places for AI, but the best use of AI is to augment human capability not to replace it. This is an old lesson, but one that bears repeating. If you don't know what you're doing, don't put an AI in to figure it out for you. If you do know what you're doing let the AIs be additional eyes and ears. Let them amplify your own senses, not replace them.  Either way, you're going to have to get the data in first.