Here’s an example from Satchmo, the web shopping cart software that is built on the Django framework. A bug involving MySQL was recently patched in the Satchmo code base. The bug fix itself isn’t very interesting, but the remaining code is. Here’s the post-fix code:

def payments_completed(self):
    q = self.payments.exclude(transaction_id__isnull = False, transaction_id = "PENDING")
    result = [p for p in q if p.amount]
    return result

Naturally, I have questions.

Why does the ‘result’ variable exist?

def payments_completed(self):
    q = self.payments.exclude(transaction_id__isnull = False, transaction_id = "PENDING")
    return [p for p in q if p.amount]

What are ‘p’ and ‘q’?

def payments_completed(self):
    query_set = self.payments.exclude(transaction_id__isnull = False, transaction_id = "PENDING")
    return [payment for payment in query_set if payment.amount]

Would a non-programmer understand this?

def payments_completed(self):
    payments = self.payments.exclude(transaction_id__isnull = False, transaction_id = "PENDING")
    return [payment for payment in payments if payment.amount]

Don’t we already have a ‘payments’ variable?

def payments_completed(self):
	return self.payments.exclude(transaction_id__isnull = False, transaction_id = "PENDING", amount__isnull = false)

I think that’s better. What do you think?

Wheeler is not a practical project. It is not intended as a better way forward, or as a better paradigm, or as an improvement in how we program. Wheeler’s sole purpose is to spark questions in your mind. If I am very, very lucky, Wheeler may inspire you to think a little differently about how you program.

Wheeler is a work of conceptual art. Like any art project, there is a vision, and there is also a muse. When the muse is present, things are good. Ideas flow. The path forward is clear. When the muse is absent, the path forward is blocked. I’ve tried to force it. I’ve tried to make the language reveal itself. That only made things worse.

With all of that said, there is plenty of work that can actively be done. I’ve been asked for some sort of tutorial and also for a roadmap. I’m working on both of these now. My hope is that I can accurately communicate my ideas to interested people and get some help bringing what I see in my head into reality.

Have you ever talked yourself out of applying for a job? Maybe you didn’t meet the specific requirements in the job ad. Maybe you were intimidated by the reputation of the company.

I did this.

There was a job that I kept seeing. The two strikes against it?

1. It was a Ruby shop and I wasn’t a Ruby programmer
2. The CTO was a legend

Those two things conspired to delay my application by a few months.

Around the time I was scheduling the interview with the company from Part 1, I went ahead and applied to work at this little Ruby shop. I was pretty sure that I’d get a phone interview, but I honestly didn’t think I’d get much beyond that. But it would be fun to apply, and good experience.

I did end up getting that phone interview. This was about a week after the disastrous interview at the company from Part 1. This time it was a panel interview, over the phone, for 30 minutes. After the craziness I had with the previous phone screen I could imagine almost anything. I decided to put it out of my mind and just relax. If I didn’t know the answer to things, that was just the way it was going to be.

You would think that having seven people interview you over the phone would be stressful. Surprisingly it wasn’t. From the start it was clear that these were nice people. The interview consisted of them going around the room throwing me tech questions over the speakerphone. I wasn’t asked to code anything. The technical questions were fairly general. No gotcha questions. No brainteasers. It was clear they were just sketching me out as a developer.

Things were going pretty well when suddenly the phone went dead. I was 20 minutes into a great interview and Skype had failed me. Worse, I realized that I had inadvertently closed the wrong Skype window while listening, so it was my fault. I had their office number and called it, but got their switchboard. I had no idea how to get back in touch with these people. Lucky for me, they called me back. I answered and explained what had happened. They were very understanding and we continued the interview.

About 5 minutes later I heard Skype go “bloop”. That usually means the call is over. “Aww, fuck”, I groaned. I had cut myself off mid-answer. There was no way they were going to call me back again.

“What’s wrong?”, I heard in my headset. I was still connected! They were still there, listening… and concerned! The Skype bloop was the timeout of the outbound call I had made earlier. Ice was instantly in my veins. “Oh thank god!”, I said. “I thought I’d hung up on you guys again.” Laughter. Instead of completely screwing up the interview with my random profanity, they thought it was funny.

Skype snafus aside, I felt pretty good about the interview. Sure enough, I got an email the next day asking me to come in for… a 5-hour interview. They’d buy lunch.

Fuck.

At least these guys seem fun, I thought to myself. Worst case, I’d get another sandwich. And get some more practice at this suddenly-common style of interviewing.

I started analyzing the last interview. Where was I weak? How could I do better? In this case they were a Ruby shop. I was very upfront with them: I was not well versed in Ruby and I worked mostly with Python. They were fine with that. Still I thought I should familiarize myself more with Ruby. Also, even though I’d done ok on the algorithms interview before, I knew that was still my weak spot. So with the better part of a week to go before my 5-hour interview, I spent as much time as I could manage reading about algorithms, remembering design patterns, and tinkering a bit with Ruby.

When I showed up for my interview (closed-in elevator FTW) I walked into an open-plan loft-style office with huge windows all around. Once they figured out who I was, the 5 or 6 devs in the office swarmed over to meet me as a group. It was clear I was meeting a team.

“Are you ready to get started?”, one of them asked me. I nodded and took a slight step toward the well lit, glass walled conference room where I could see a looming whiteboard.

“My desk is over here”, he said, and steered me off toward a sunny area of the office where his desk was parked.

Ah, I’m going to answer interview questions on his computer, I thought. Cool, I can type my answers!

Pretty soon it was clear that there were no interview questions. He and I were going to pair program, and I was driving. He explained that we were going to hack on a real problem that he had been working on. I don’t remember what the problem was now, and I doubt I made any real contribution. That wasn’t the point. Within minutes I had forgotten that I was in an interview, and I was at ease. No one in the office was watching or hovering – they were all off doing their jobs. It was just a chance for the two of us to work together and see what that was like. He did manage to throw in a bit of tech talk during our hour together, but I was relaxed and nothing seemed like a gotcha.

After that first pairing session it was lunch time. I was wondering what kind of sandwich they were going to give me. Suddenly the entire dev team got on their feet and headed for the door. Apparently we were having lunch out. And so we did, at a nearby restaurant. Instead of asking me tech questions they asked get-to-know-you questions. It was a little awkward at first, but after a few minutes I was once again relaxed and felt in my element, making conversation and letting some of my humor show. (In case you wonder, I had a salad, no onions. It was still a job interview!)

Back at the office I was paired with a guy who was clearly the shark on the team. He was smart and intense. He talked fast and expected you to keep up. We paired, like before, and I was in the driver’s seat. He guided. My lack of familiarity with Ruby didn’t phase him, especially once I seemed to have made it past his dipshit filter. Still this was the toughest part of the day, as he had this way of explaining things to you and then staring at your eyes to see if there was the slightest twitch of confusion or weakness. It was intimidating, but tolerable. And understandable, really. I could tell he was protecting the quality of his team and took the evaluation seriously.

At some point the CTO pulled me aside for a chat. Instead of demanding from me why I wanted to work there, he just tried to get a feel for what I was aiming for. I was pretty honest, as I had been at the previous interview. But by this point I was impressed with the team and the work environment. He said to me, “We’re a startup. None of us know where we’ll be in 5 years, and that’s ok”. I smiled. Honesty!

I spent time pairing with the other devs that day, each impressive in their own way. In the last pairing session of the day I was able to teach my pairing partner something that he didn’t know, and we put it to work in solving the problem he was tackling. That made me feel great.

Finally, at the end of the day, the whole group of devs came over to see me off. It wasn’t cheesy; they were just thanking me for coming in. It was pretty clear that the feelings were positive both ways.

Within a few days I had an offer.

(Cue the wavy screen effect as we roll back in time to the year 2009…)

I worked for many, many years as a roaming contract programmer, followed by a painful, scrappy stint with self employment. After so many years of fruitless jostling and meaningless projects, I really just wanted a home. A stable environment with a good team and a steady paycheck.

Through a friend I landed an interview with a fairly big company in the healthcare field. The phone screen was weird. It was a short 20-minute call. A few easy tech questions, although the guy interviewing me did trip me up on a time complexity question. That wasn’t so bad. The painful part was the coding task: I had to write code over the phone. No shared editor or whiteboard software, just talking over the phone. He described the problem (Fibonacci) and when I was done I was to describe what I had coded up in C#. This included voicing things like “semicolon”. I had something like 5 or 10 minutes to get it done while he waited on the line. Have you had this experience? It’s a crazy situation. You’re trying to think about how to code a solution while you’re on the phone and nothing but dead silence is coming back from the other side. I got it done in time and described a bit of code that seemed reasonable to the interviewer.

It’s often hard to tell how these things go, but I did get a follow up call scheduling me to come in for a “hands-on” interview. I was stoked, but my blood went cold when I found out that my interview would be 5 hours long. They’d provide lunch, I was assured.

After I got off the phone I pondered this. A 5-hour interview? Really? Had I been applying to Google or Microsoft, that wouldn’t have surprised me. But this was a pretty ordinary company hiring for what seemed like an ordinary position. Still, I figured the worst thing that would happen was that I’d get a free lunch.

I decided that if they were going to give me that much attention, I’d better take prepping seriously. It was stressful. What to focus on? A million things raced through my brain. I eventually settled on reviewing recent changes in the .Net platform and studying algorithms (my kryptonite). I don’t put a lot of stock in arbitrary algorithm knowledge, but I know to expect questions in that area. I can’t say I spent too much time studying, but I did throw some time at reviewing things like red & black trees and trying to imagine what the interviewers might ask me.

The big day came. I worked hard to get there early and after getting lost and running into a small obstacle (glass elevator vs. acrophobia) I managed to be just in time for my interview. Perfect!

I was shepherded to a tiny, fluorescent conference room and interviewed by the team manager. We chatted for a bit and he explained their process. Basically I would be stuck in that room all day. They’d bring me lunch at some point, and over the course of the day they’d send in people or pairs to pepper me with questions for an hour each. At the end of the day he’d be back around to wrap up.

First up was Architecture. They brought in a seasoned architect and we stood at the whiteboard for an hour talking about objects and architecture. I was a little nervous about coding at the whiteboard, but he was very nice and gave me latitude to solve problems in whatever language or platform I’d like. I chose Python since I was working pretty heavily with Django at the time. Things went fairly well, but not perfectly. I felt that he and I were on the same level technically, but he was much more of a specialist of the Enterprise Architect variety. At the end I felt like I passed but it was clear that he was the better Architect.

Next up was Algorithms. This was where I predicted it would all fall apart. A pair of very young guys came into the room, introduced themselves, and then dove right in with some general algorithm questions. To my surprise I knew the answers and could “read the pitch” of the questions they were throwing at me. I experienced a huge boost in confidence and I did much better than I expected. When they asked me to write a sort in C# on the whiteboard I stumbled a little. I had just written Python code for an hour for the previous guy so my brain was warmed up but in the wrong language. My C# was a little rusty, especially outside of Visual Studio. It can be amazingly hard to write code with your hands instead of your fingers. Happily they didn’t sweat syntax errors here and there. Once I shook off the rust and the nerves it pretty much wrote itself. My first solution was recursive so they had me rewrite it. Finally it was done; they had no more code and no more questions. I suspected that the hardest part of the interview had just wrapped. I gave myself a mental pat on the back. All down hill from here, I figured.

Not quite. By the time I was done with these guys I was getting tired. Between the the mental load and the stress I was starting to bog down. Toward the end of the hour someone was nice enough to run out and grab a sandwich for me. Pretty soon I had my sandwich and was chatting with the next pair of interviewers who quizzed me on general .Net knowledge as I ate. If I had guessed in advance which segment I would do best on, this was it. Instead I fell apart. These guys were the sharks on the team, it seemed. Their questions got very aggressive. I just continually whiffed, even with questions that I “knew”. This included one question on specifics about boxed variables that I almost certainly had asked when conducting an interview of my own just a few years before. After that round I felt absolutely worthless.

Next I had a “quick chat” with the head of the division I was applying for. And it’s here that I’m almost certain that I botched the whole interview. I don’t remember the details, but the essence of it was this: We’re this successful startup (successful yes, startup no) and you should have a super-compelling reason you want to work here. My response was essentially, “I just want a job”. This did not sit well, and in a very polite manner he made this clear. (In retrospect I would suggest they use the phone screen to weed out those pesky people who don’t dream the Cubicle Dream. I would have saved all of us a bunch of time.)

Finally I got to meet again with the team manager, my last meeting of the day. By that point I was defeated. He asked how I did. Exhausted and weary, I told him that I thought I did “okay” and that I would have liked to have done better on some bits of the technical interview. He promised to be in touch and then showed me out in to the lobby.

There in the lobby sat my friend, the glass elevator.

Much to their credit they did contact me a day or two later and let me know that they weren’t interested. This was in 2009, in an employers market, and I wouldn’t be surprised if I simply got beat out by a better candidate. So it goes.

Read more in Part 2.

The past few years of wide-ranging language interest have cast doubt on that perspective. Still, one theme that I can’t shake is that you should be able to model new features in an existing language. It might be awkward, but it should still be possible. (Especially if you’re going to implement the language!)

In that spirit, I’ve tried to express one of the core ideas in Wheeler with a library for Python called AssociativeTools. The star of the show is the Workspace class, which represents a data structure I call an Associative Network.

The word “network” is overloaded. Most often it is used to refer to computer networks. Here, I’m referring to a network or web of data. Think of a big pool of data in which nodes can be arranged into graphs of your choosing.

The Workspace lets you relate items (anything that is hashable in Python) to one another. Mostly I’m using strings and numbers. You relate items to build graphs so that later you can come back and fetch those graphs with partial information. It’s a lot like querying a database. It’s more like querying a search engine. Look:


s = Workspace()
s.associate("foo", "bar", "baz")
# Later in the code...
print(s.comprehend("foo"))


Outputs:

set(['bar', 'baz'])

Btw, the naming for all of this (AssociativeNetwork, associate, comprehend) is all flexible. Suggestions are welcome.

We work with a small but quite tangled system. The system itself is only a few years old but contains many technologies and bears the scars of several smart but inexperienced people learning how to design as they went. I won’t articulate the details of the bug we were experiencing but I will say that it is something that recently appeared and was troublesome but non-critical.

The difference in our two points of view became apparently very quickly. My desired approach was to try to pin down the bug, deconstruct it to the point of understanding, and then apply a fix. My coworker’s approach was to make a well-educated guess about the cause of the bug and apply a refactoring to our codebase that would address the anticipated problem.

His reasoning was that our codebase was too complex to spend time trying to understand it in detail, and in the worst-case scenario we would still have completed a useful refactoring that improved the quality of our codebase. I found this a bit hopeless. Is software really so complex that we as programmers now have to act like doctors – diagnosticians – making reasoned guesses about the world around us? Is there no more engineering?

10 or 15 years ago I would have considered his approach ridiculous. Now I’m honestly not sure. Modern software systems contain so much abstraction and layering that it is really hard to judge the level of effort that will be involved in addressing any one problem.

So what option did we choose? We guessed and did the refactoring. I don’t think I would have agreed to that with just any pair partner, but this particular coworker is a very productive programmer. He had a clear path forward and a clear rationale. And one thing you don’t do with a productive programmer is get in their way.

Did it work? No. I almost want to say “OF COURSE NOT!” but that would be unfair. It could very easily have worked. What did eventually work? A pair sitting down and tracing through the application stack with gdb. And even that has only located the approximate location of the error. We still haven’t solved the problem yet. But we’re much closer.

That video is about how cell membranes work. Did you notice how proteins, enzymes, etc. can only pass through the cell membrane if they are the right shape (and flavor)? That’s how values trigger transitions in Wheeler.

Transitions

If categories are the most minimal representation of state, then transitions are the most minimal representation of action. Transitions are how computation happens in Wheeler. After all, organizing data is only half the battle with programming. Once you have the data in the form you want, you have to actually do something.

You can think of transitions as being very much like an event handler. You define a transition to trigger when an interaction between one or more categories happens.

Since Wheeler is still a work in progress, transitions are not yet native. Instead, transitions are created in Python, the language Wheeler is built on.

Remember our Hello example?

Here’s the transition defined for it in Python:

def printer(category):
	for item in category:
		print item.name[1:-1],
	print
	return []

ROOT.create('print').add_handler( STRING, printer )

(I’ve omitted some unimportant details for clarity.)

What you might be able to suss out here is that there is a ROOT category that all categories live within, and I’ve created a “print” category within that. In addition, I’ve added a transition (with add_handler) which knows to watch for interactions with items in the string category. If the transition finds an interaction that matches, it executes the printer() function, which simply calls Python’s ‘print’ function.

Mutual Dispatch

When more than one transition is triggered by an expression, the transitions all execute AND – at least in concept – they all execute *at the same time*.

This is very much like the real world. If two objects collide you don’t say that one or the other of them collided first. The collision is mutual and simultaneous. In that same way, when categories interact, the interaction is mutual and simultaneous.

Here’s the final snippet of Wheeler for this introduction:

In case it’s not clear what is going on here, we have some numbers, which are in the category ‘number’, some text in the category ’string’, and some other categories (’print’, ‘+’) which give it all meaning with transitions. One transition knows to add all of the numbers in the expression when the plus sign is present. Another transition knows to print all of the strings in the expression to stdout when the ‘print’ category is present.

When presented with this jumble of categories, Wheeler figures out what to do based on the criteria of the transitions. This effectively creates a typed-dispatch mechanism. I call this simultaneous, polymorphic behavior “Mutual Dispatch”.

That sums up Wheeler as currently implemented.

There’s still a lot of work to be done. I’ve covered what Wheeler is currently capable of. There are other planned features that I didn’t cover and hope to implement soon. I will provide more info here as new features are added.

I hope you find it as oddly fascinating as I do! Feedback is not just requested, it is begged for. I also strongly encourage you to grab the code, play, and contribute.

(Thanks to Westside Programmers and #pdxfunc for letting me present on Wheeler a few times over the past year. Having the chance to present and receive feedback has firmed up the concepts in my mind and made them easier to distill into this introduction.)

Someone recently asked me if Wheeler had types. My answer was “No. Uhhh… and yes.” What a terrible answer! I’ll try to do better in this post.

Wheeler has no explicit type system. You will never declare a value to be of a certain type. You might, however, associate a value with a particular category through an interaction. In that way you’re establishing a relationship that will allow typing *behavior*.

What is a value?

Values are the imaginary, interstitial things floating between categories. When you establish a relationship between categories in Wheeler, you’re creating values.

What is a type?

I won’t attempt to answer this in general. I am not a type theorist. From the perspective of Wheeler we might say that a type is determined by a graph’s “shape” and “flavor”. Shape is the actual form of the graph we create in memory (tree, ring, object, etc.). Flavor is what specific categories are being connected by that graph.

What the hell is the difference?

Context. It’s all context. A value will trigger typing behavior when something matching that shape and flavor is being watched for. At that point it could be considered a type. The rest of the time, a value.

Layering values into types

Have you ever seen an artist paint a landscape? First they’ll paint the background… the sky, the horizon, the land. Then they start to layer on more and more detail. At what point does their work become a painting? Existential arguments aside, you might say that the work is a painting when it meets the criteria of the artist. Criteria will vary from artist to artist. Everyone has their own objectives, aesthetics, etc. In other words, everyone brings their own point of view or context to a situation. This idea is so fundamental in Wheeler that it is a core value of the language:

Context Drives Behavior

To help understand this, let’s look at a Venn diagram. (Venn diagrams are quite handy for discussing concepts in Wheeler.)

Here you see we’ve got just a category, Cars. You could think of that as a type. Let’s pile on some more specifics:

Now we’ve got all cars that are Honda Elements. That’s more specific, but it’s still more like a type than anything.

Ah, but now that we have a VIN, the unique Vehicle Identification Number. That’s so unique as to specify a particular vehicle. That seems more like a concrete value now. Yay.

Next time we’ll look at Transitions which allow computation in Wheeler. Then we’ll exercise our type and value scheme.

(You can play along at home by grabbing the latest code and running the examples. You’ll need Python 2.5 and patience.)

First, let’s fire up “bigwheel”, the Wheeler interpreter:

Here is “Hello, world” in Wheeler:

Wheeler is flexible though, so you could also say:

More on that later.

Categories

Wheeler is different from many languages you may be familiar with. All languages have abstractions. Some common examples are functions, lists, collections, stacks, pointers, and objects. In Wheeler, state is the fundamental abstraction.

State is represented by an abstraction called a Category. Categories are lightweight, atomic things. In Wheeler, everything is a category. Here are some sample categories:

• Fred
• blue
• 5.3
• “Hello, world!”
• number
• 3/15/10
• send
• 05:10:59
• AM
• PM
• true
• print

Categories express boolean state. You’re either in a category or you’re not. Here’s an example:

Do you see that? No? Good. What you do not see is ‘apple’ being put into the ‘red’ category. That is happening behind the scenes through an interaction between apple and red.

Categories aren’t containers, but from a practical standpoint they act like containers. This allows you to make statements about the world. We can pile some more attributes on “apple”:

Interactions

Interactions are expressions that combine categories to create new states. Our “Hello, world!” was an example of an interaction. Making our apple red was another interaction. Interaction is a mutual, simultaneous event where a connection (graph edge) is created between each item in the expression.

Wheeler has a “dump” command that will let you see (in GraphViz) the relationships you’ve created. Let’s dump “apple” and see the relationships:

And the relationships as diagrammed in GraphViz:

Here you can see that “apple” is related to “red”, “tasty”, and “sweet”. (You might notice that it is also related to “dump”, the category it interacted with to generate our diagram, and “metadata”, a built-in category.)

You can see that not only is ‘apple’ connected to ‘red’, but ‘red’ is also connected to ‘apple’. In Wheeler all relationships are bidirectional. This may seem odd if you’re used to typical hierarchical relationships in programming. Wheeler doesn’t think about the world that way. Wheeler has a few strongly-held beliefs, and one of these is:

Hierarchy Is Bullshit

Next time we’ll talk about composing categories into types.