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.

Note: This is the conclusion of a two-part entry in my ongoing “Road to Wheeler” series.

In my last post I covered some of the popular type schemes used in programming today. I continued a little past where most discussions of type go when I pulled in pattern matching.

Deconstructing Types

Imagine that you are using a language with no data types and you want to implement some of the typing behavior that I showed in my last post. One way you might do it is with a record used to associate type information with a value.

A C-style int might look something like this:

x = (int, 5)

That’s pretty simple. We’re storing our value along with it’s type. Using that same scheme we can also represent a typical object instance:

vendor = (Vendor, FirstName, LastName)

“Vendor” here is the classname, but it could also be an interface name. Or the record could contain a list of interfaces supported. Or, a list of methods implemented.

The pattern matching example from last time is already in record format. We’ll just change the Erlang braces to parentheses for continuity with the other examples:

(customer, FirstName, LastName)

Let’s list all of these records together to compare them:

(int, 5)
(Vendor, FirstName, LastName)
(customer, FirstName, LastName)

See the similarity? The types are from different methodologies, but they boil down to equivalent concepts.

Our Own Imaginary Type Implementation

I could easily define a function in my imaginary typeless language to properly handle any of these records:

def display(record):

	type = record[0] # Key off first item in the record.

	if type == int:
		print_int(record)

	elif type == Vendor:
		print_vendor(record)

	elif type == customer:
		print_customer(record)

Is pattern matching a typing scheme? Do typing schemes devolve to pattern matching?

One thing I left out of my pattern matching example from last time: Patterns can match concrete values, such as specific numbers. In this example I’m expecting to find out just how overdue a customer’s account is:

bill_with_msg({customer, 0}) -> send_bill("Here's your new bill.");
bill_with_msg({customer, DaysOverdue}) -> send_bill("Your bill is ~p days overdue.", DaysOverdue).

The first pattern matches on the atom “customer” and the specific value of 0 for the number of days overdue.

If we rewrote this in our typeless language with records it might look something like this:

def bill_with_msg(record):

	type = record[0]
	days_overdue = record[1]

	if days_overdue == 0:
		send_bill("Here's your new bill")
	else:
		send_bill("You're bill is $days_overdue days overdue.")

Guards Point The Way

Have you seen guards? They’re pretty handy. Here’s an example of guards in Erlang:

bill_with_msg({customer, 0}) -> send_bill("New bill.");
bill_with_msg({customer, DaysOverdue}) when DaysOverdue <= 30 -> send_bill("Your bill is overdue.");
bill_with_msg({customer, DaysOverdue}) when DaysOverdue > 30 -> send_bill("YOUR BILL IS SERIOUSLY OVERDUE. PLEASE PAY NOW.").

Those “when” clauses are guards. And they’re pretty nice. In a fairly concise and clear way we’ve expressed our desire to do several things with relatively little code. In the process we’ve managed to unlock a new dimension to typing. If you accept that typing is essentially pattern matching you can see that the guards are actually adding extra dimension to our types by letting us do very specific pattern matching.

The trouble with guards is that they are bound to a function. What if you want to capture a certain type of customer (one who has spent more than $10k this year) so you can target them directly? You might find yourself with functions like this:

bill_customer(customer, spent) when spent > 10000 -> preferred_billing().

find_shipping_options(customer, spent) when spent > 10000 -> preferred_shipping().

lookup_special_offers(customer, spent) when spent > 10000 -> offer_preferred_promos().

That’s a lot of repetition; a code smell. If you’re an OO type of person you might break that kind of customer out into it’s own class, generated by a factory. Or perhaps you might decorate your customer objects with particular account classes. And of course there might be many other strategies.

This might also be a good place for a macro if you’re a Lisper.

Another way might be to declare a type with the guard built-in. Here’s one way this might work with some made-up syntax:

typedef Customer = Customer when spent < 10000
typedef GoldCustomer = Customer when spent >= 10000 and spend < 10000
typedef PlatinumCustomer = Customer when spent >= 100000

Here we’re creating some concise types on top of an existing type. Instead of subtyping or aggregating classes, we’re taking a class or data structure (Customer) and describing some situations where we’d like it to be treated specially. Now we can have polymorphic behavior on anything – types, values, or ranges of values.

This scheme will stretch a little farther:

typedef Spam = String when contains "viagra"

def proc_mail(Spam msg):
	mark_and_toss()

def proc_mail(String msg):
	deliver(msg)

Of course you can only do this with lazy type evaluation, so there’s some runtime cost. I’m ok with that. Laziness has its virtues.

What I’ve presented so far is interesting but still rather flat. We can go farther. What if we can look at the shape of things too? After all, an interface represents a sort of shape. What if you just want to support objects that have a “Text” property? What if you only want to deal with Customers who have blue items in their RecentPurchases collection? Or more abstractly, what if we only want to deal with objects that expose a hashtable containing other hashtables?

Sound weird? It shouldn’t. It happens all the time, it just depends on the environment you work and code in. See also: jQuery, LINQ, RSpec, Hamcrest, etc., etc..

This Way To The Egress

I haven’t seen a type system that does exactly what I describe. Maybe you have. If so I hope you’ll tell me about it. Haskell’s type system is pretty nice (and I’m still learning), but seems to stop short of the dynamic behavior I’m looking for. Wheeler, the language I’m working on, aims (at least in part) for something very much like this.

Note: This is the first of a two-part entry in my ongoing “Road to Wheeler” series.

In the C language, where I was first introduced to the concept of “type”, types are metadata associated with some bytes. Here’s some C code:

int x = 5;

int z = x + 3;

Here x, z, 5, and 3 are all understood to be ‘int’s. What’s an int? The computer doesn’t really care. It just knows that an int is going to be a certain number of bytes in memory.

If She’s Lucky, I’ll Show Her My OO Face

In a common OO language like C++ or Java, we start to think of types in more abstract terms. We’re no longer thinking solely in terms of memory footprint. Now we’re thinking in terms of interface. Also, the concept of “type” becomes very closely bound with the notion of polymorphism: We expect that a function with two different implementations will “automagically” catch the proper value that gets thrown at it:

// Imagine a few classes, which I won't bother to fill out:
class Person;
class Customer : Person;
class Vendor : Person;

public void Display(Customer thingy)
{
	// Do something customer-specific here.
}

public void Display(Vendor thingy)
{
	// Do something vendor-specific here.
}

That’s about as far as a lot of programmers in the Java, C# and C++ worlds seem to go in terms of thinking about types. That’s too bad, because there’s more going on.

Quack Quack

Duck typing is the big thing outside of most of the static typing world. Essentially duck typing depends purely on behavior – if an implicit interface is available, things work. By “implicit interface”, I mean if the functions and properties on a class which are expected actually exist. “If it walks like a duck and quacks like a duck, it must be a duck.”

Duck typing doesn’t require a lot of formality, but it’s still a type strategy. You’ll find duck typing in languages like Python, Ruby, and Perl.

Btw, not to be outdone, C# 4.0 offers “dynamic types” – essentially some syntax and internal support to allow duck typing in C# code. It ain’t pretty, but it is equivalent. (Accordingly, look for it in Java in 5 years and C++ in about 14. /snark)

Hey! Here’s some code to ponder:

# More hand-waving classes. You get the idea.
class Person
	def show

class Robot
	def show

class Customer < Person
class Vendor < Robot

def display(whatever)
	#do something with a Customer or Vendor. Or Robot or Person. Or whatever has a show method.
	whatever.show
end

This works because both classes, though unrelated, have the same method which is expected (show). So duck typing is still interface typing, but without any guarantee. “Jump and the net will appear” it one way to look at it. (Most of the time it does!)

Pattern Matching and Awesomesauce

Here’s where I’m going to take a detour from the norm and talk about pattern matching. Pattern matching is a nifty feature in a number of different languages which lets you capture data and use it polymophically. Most often this is used to isolate a specific piece of data or to differentiate partial functions. It is in that last sense that I’m most interested in pattern matching as a typing scheme. Here’s an example in Erlang:

display({customer, FirstName, LastName}) ->
	show_customer(FirstName, LastName);
display({vendor, FirstName, LastName}) ->
	show_vendor(FirstName, LastName).

Just as in the OO example, here we have two overloaded functions and one of them will be selected based on the first argument. What is different here is that we’re not switching on types, we’re switching on values. The “customer” atom is a value that is being matched. If I had passed in some other atom, like “vendor”, that wouldn’t have matched “customer” in the first function signature, so the computer would look at the next function to see if that matches. Luckily in this case I’ve defined my second function to match “vendor”, so it finds a match. Note that I could also have used an underscore (wildcard) in place of “vendor”, and matched on anything that had made it that far. Effectively that would have meant “not a customer”.

Like with duck typing, we’re not dealing with an explicit type, but we still have typing behavior. It’s a different kind of type.

This has turned into a two-parter. I’ll recap: I’ve reviewed some common type schemes and bent the concept of “type” a little bit. In the next installment I’m going to bend the idea of “type” just a little more. Be sure to come back and see if I break anything.

From Vonnegut’s “Slaughterhouse Five”:

Billy couldn’t read Tralfamadorian, of course, but he could at least see how the books were laid out – in brief clumps of symbols separated by stars. Billy commented that the clumps might be telegrams.

“Exactly,” said the voice.

“They are telegrams?”

“There are no telegrams on Tralfamadore. But you’re right: each clump of symbols is a brief, urgent message – describing a situation, a scene. We Tralfamadorians read them all at once, not one after the other. There isn’t any particular relationship between all the messages, except that the author has chosen them carefully, so that, when seen all at once, they produce an image of life that is beautiful and surprising and deep. There is no beginning, no middle, no end, no suspense, no moral, no causes, no effects. What we love in our books are the depths of the many marvelous moments seen all at one time.”

http://virtlib.builtsoftware.com

Have you ever noticed how your local library doesn’t stock a great selection of technical books? They would if they could, but they can’t. It would just be too expensive. Technical books are a niche, and worse, they are a constantly changing niche. Libraries can’t get a good return on investment from a book like “Agile Web Development with Rails“. It’ll be useless in 3 or 4 years when the technology changes. A copy of “Jane Eyre” could still be providing constant value 20 years from now. And far more people will read Jane Eyre than will ever hear of Ruby. The mainstream rules.

Because of this geek-gap at the library, technical folks are forced to go off to the book store or places like Amazon or Alibris to get our books. And it ain’t cheap! Then, after we buy our book, we read it and set it aside. If it was good, we hang on to it for reference later. We end up with shelves full of books that other people could be using.

Why not let them?

That’s what the Virtual Library is all about: Sharing with your local tech community. And it’s pretty easy. You sign up for an account, and then start adding the books you want to share. You type in Title, Author, and ISBN and that’s about it. Then others can request your books. And you can request their books too! You decide along with the other person how you’re going to meet up to get the book. Local user group meetings are a great time for this, but you can meet when and wherever you’re both willing.

The Virtual Library is still in the early stages of development, and it is only available in the greater Portland Metro area, but if people find it useful I’ll be expanding it to other tech-minded areas. If you live somewhere outside of Portland and you’d like to have a Virtual Library, contact me.

If you’re in the Portland area and you’ve got any kind of technical books (not just programming… even medical, legal, musical, architectural, etc.) that you would like to share, go sign up for an account and add them in. You’ll be doing yourself and your local geek community a great favor.

Go sign up!

Well, I guess we have to pretend that it does to some extent. But we certainly don’t have to pretend that it exists in some absolute, immutable way.

Take files, for example. What are files, really? If you think about this long and hard enough you realize no, files aren’t just chains of bytes. Files are flattened data structures. And more than that, they are flattened out ideas. But let’s stick with the data structure thing. Every document, every file, everything ever has some kind of structure.

Files haven’t always existed in computers. There was a time with computers and gasp, no files. The file metaphor appeared fairly early in computing. So why do we stick with that same metaphor now?

Files are crap. They’ve forced us to flatten out our data. That business plan that you’re writing in 15 parts, with three sub parts each? It really wants to be a tree with 15 nodes, each with 3 nodes. Or something. It most certainly does NOT want to be flattened down into a file, where every part of the file is on the same footing with every other part of the file. That just doesn’t make sense.

So here we are, as programmers, and we have all of this data and structure floating around in our programs, and we have to store things in a file. Blech! How are you going to store a graph (object graph, data tree, what have you) in a flat file and have that make any damned sense at all?

You’re not. No, do NOT say XML! That is not the answer either. Don’t get me wrong… XML heads in the right direction, but it’s still flattening things out terribly. And it’s also kind of stupid. To be fair that’s mostly an implementation detail.

I know, I know, you want me to explain why XML is stupid, because otherwise I’m just making spurious accusations, and programmers hate that shit. Or at least pretend to, so they can poke at other programmers when they disagree with them. Whatever. I hold these truths to be self-evident, that files are fucking bullshit and that cramming data into flat files is a god damned waste of time. And yes, I mean “god damned”. Even if you don’t believe in a God or a god or an FSM or what have you, it’s clear that we only have so much time on this spinning ball of mud and how much of it will we spend bruising, battering, and smearing out our data to fit into some ridiculous flat file system?

Thank god for relational databases, right?

Fuck you. Have you listened to a god damned word I’ve been saying? I’m talking about taking our data, packing it up into ridiculous shapes and sizes, spackling on meta data to make it all make sense, and then shoving it off to some other place to live. Does that in any way make you think that relational databases are getting off the hook here? Fuck-to-the-N-O. What’s that? I have to mash my data up into chunks that fit into little square tables? And then if I want my data to connect to other data I have to create more little meta tables to show how everything connects? And it’s all ok, because there’s MATH behind it all, right? God damned MATH will save the fucking day.

No.

Maybe you’re catching on now. Now you’re thinking about those nifty key/value databases that have come back around lately, aren’t you? And the document stores? The hierarchical databases? Surely something here will save the day, right? Rubbish. But maybe. I don’t know.

Here’s what I know: I have data, and I want to look at my data my way. You have data, and some of it is probably some of the same data that I have. And that’s cool… I remember kindergarten. I like to share. But why in the hell do I have to share with you on YOUR terms? Don’t get me wrong, I don’t see why you should have to share with me on my terms either. Things should be flexible and bendy and still make sense. Is that too much to ask?

Probably, yes.

[hat[cat] if cat in hat else cat for cat in cats]