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.

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.

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

Giving the talk was a blast. There was a lot more prep to do than I expected, and we had so many ideas that only a fraction made it into the talk. That’s a little disappointing, but the audience was entertained and engaged and I think that’s what really matters.

One unexpected result of prepping for the talk is that my “hackitude” shot up tremendously. Our talk revolved around many code samples in several different languages, and we ended up using only a fraction of the code we created. So the bottom line is that we wrote a lot of code in a fairly short amount of time. Not only that, but the code really just flowed. It wasn’t effortless, but it was definitely satisfying and productive.

This is exactly the kind of increase in capability that I was aiming for with my 30-in-30 project. I think the difference here was that I was doing the code purely for the fun of it. A lot of our code examples were gags and language hacks that elicited both deep thought and chuckles from us as we worked on them. Having a collaborator was also a huge win. We sent a lot of code back and forth to each other over the past few weeks and that increased our velocity quite a bit.

A couple of people blogged about our talk here and here.

The code and slides are both available.

Audio was recorded from the talk (although we forgot to repeat questions and sometimes I was off-mike). When that’s available I’ll post a link.

I’m still a functional programming n00b. Which is funny to think about, because I probably know more about FP at this point than I knew about OOP many years ago when I was a junior programmer and considered myself something of an OO expert.

FP newbie or not, I’m still an experienced programmer with my own aesthetic sense of what qualifies as good code. One of the things that has always annoyed me about LISPs is their antiquated use of car and cdr as function names. Certainly once you’ve seen them enough you know exactly what they are and what they do. But as far as skimming code goes, they are awful. They aren’t clear or intuitive to new or casual readers. Even pronouncing cdr annoys me. (I want it to be ‘cedar’. Instead it is ‘could-er’ which sounds like a character from the Dukes of Hazzard.) I feel compelled to wrap them in my own functions just to make friendlier names like ‘first’ and ‘rest’, or ‘head’ and ‘tail’.

Other languages do use the head and tail metaphor directly. Erlang, which I enjoy programming with quite a bit, has an idiom where the head and tail metaphor shows up in the naming convention but not directly in syntax or function names. Instead of extracting the first item in a list with car and the rest of the items with cdr, you unpack the list with a pattern:

Eshell V5.5.5  (abort with ^G)
1> [H|T]=[1, 2, 3].
[1,2,3]
2> H.
1
3> T.
[2,3]

(Btw, Erlang’s pattern matching is far more powerful than I’m letting on here, and it makes this simple head/tail stuff look like child’s play.)

By convention it is understood that H stands for Head, and T for Tail. And that’s fine, but what this idiom often means is that you end up declaring two or three variables for what essentially are views on a list. For example, during the SICP study group we solved a “change making” problem from Ch. 1. Here’s the code I wrote in Erlang. I opted to replace H and T with domain-specific names:

-module(change3).
-export([find_variations/2]).
-export([count_change/1]).

find_variations(0, _) -> 1;		% No amount given.
find_variations(_, []) -> 0;	% No coins given.
find_variations(Amount, _) 		% Amount is impossible.
	when Amount < 0 -> 0;

find_variations(Amount, [Coin|Rest]=Coins) ->
	find_variations(Amount, Rest) + find_variations( (Amount - Coin),  Coins).

count_change(Amount) ->
		find_variations(Amount, [50, 25, 10, 5, 1]).

The spot of interest here is the find_variations method matching [Coin|Rest]=Coins. This creates 3 variables which are, respectively, the first item from the list, the remaining list, and the original list itself. All of which get used in the function.

While I *looooove* the pattern matching in Erlang which allows these fairly clear variables to exist, I wonder if there might be a symbolic way to decorate the list variable to yield a particular view instead of requiring three separate variables to deal with. I came up with a few ideas, but I’m not sure I like any of these. Feedback is appreciated.

Idea 1 – Graphically show head and tail

Head: << List
Tail: List <<

Idea 2 - Borrow from Regex Anchors

Head: ^List
Tail: List$

Idea 3 - Misappropriate Perl's sigils

Head: $List (since the head is basically a scalar)
Tail: @List (since the tail is a list)

All of these suck in their own way, but I think I like Idea #3 the best because it gives you the opportunity to treat a list in reverse without having to reverse it first:

Last item in list: List$
All items in list except last: List@

If Erlang had a syntax like this (and thank god it doesn't), here's what that earlier function would look like, rewritten using syntax #3:

find_variations(Amount, Coins) ->
	find_variations(Amount, @Coins) + find_variations( (Amount - $Coins),  Coins).

I'd like to know what others think about this.

In closing, I'd like to note that Python, my day-to-day language, already has this flexibility using list slices:

def find_variations(amount, coins):
	return find_variations(amount, coins[1:]) + find_variations( (amount - coins[0]),  coins)

Unfortunately, Python is designed to discourage recursion so this is sort of misleading. You wouldn't write a real solution this way in Python.

Fortran would be Greco-Roman wrestling. You have to wear tights and there are a lot of lame rules. But if you’re good at it you can certainly pin a dude.

Lisp would be Aikido. It is philosophical. It is elegant. It breaks things down to their essential components. It is dripping with the Tao. Unfortunately the schools are splintered and the focus seems to be more on finding The Way than kicking some dude’s ass in the parking lot.

C would be plain old Karate.

C++ is Judo. It looks a lot like Karate until it throws you over its shoulder onto your head and your arm pops out of its socket.

VB would be Western boxing. It can walk right up to a problem and punch it in the face. Of course there will be some mandatory bobbing and weaving and some fancy footwork for no apparent reason. And it’s all over if it gets taken to the ground.

Perl would be Jujitsu. It isn’t as clear-cut as Karate or as elegant as Aikido, but it’s good on a battlefield when you run out of ammo. And it isn’t opposed to you using a rifle butt instead of your fist.

Java would be Tai Chi. Everything is very slow and very formal and OMG after you’ve used it a little bit your muscles hurt like hell. So you’d never actually use it in a fight. But the payoff comes later with how light you feel when you’re kicking ass in any other language.

Javascript would be Krav Maga. It isn’t just going to fuck you up, it’s going to kill you. It isn’t too particular about how and it knows a lot of ways to do it. Unfortunately it can only fight within 50 yards of its house because it’s on probation and has an ankle monitor.

PHP would be Tae Kwon Do. It’s that shit you learn at the strip mall when you’re 6 years old. You know, the place that puts the flag on your gi and their dojo name in huge letters on your back? Sure, you can kick someone’s ass with it – if they hold still and don’t fight back too hard. It is not a deadly killing system – but you can do a spinning back-kick like no one’s business!

Ruby would be Brazillian Jujitsu. It acknowledges that most real fights are messy and end up going to the ground, so why not specialize in winning that way?

Erlang would be Wing Chun kung fu. It has a pragmatic fighting philosophy and is very effective, especially against multiple opponents. There are some restrictions on how you strike and move, and there are fewer moves than with other styles. Eventually you realize that is for the best.

Haskell would be White Crane kung fu. There’s a lot of weird shit going on and no one seems to know it, but you just know that dude can fucking kill you with his death touch or whatever.

Please feel free to leave suggestions or to correct me in the comments.

Typically I develop software for clients over time instead of in one big shot. After an initial release the client will come back with feature requests which will lead to new versions of the software. To make a new version of an app I code up all of the feature requests on top of the current version. In other words, given version A, I add features B and emit version C.

What I’d really like to do is to have control over each feature I add to the software. Certainly I could carefully track my development and create patches after ever feature is implemented. Then each feature would be separately controllable to some degree. But that doesn’t really accomplish much aside from allowing a bundle of features to be deployed. Each feature would still be linearly bound to other features and there would be no intelligence about dependencies.

If my client calls me up and says “feature B.3 isn’t as useful as we thought, pull it”, I’d like to be able to do that easily and on the fly, in production. In a perfect world I would do this from a config file or control panel somewhere. And if feature B.3 is required for features B.5 and B.42? Then those get turned off too, probably after a confirmation.

Like I said, I don’t really see how it would work. Real software is complicated and only gets more so as time goes on and features are added (or removed). Even the concept of what is or is not part of a given feature is subjective and could change over the life of the app. Features could and likely would cross boundaries of classes, functions, database tables, etc.

All of which sounds a lot like AOP.

PHP was pretty easy to blow off when I first came across it back in 2000. It looked like the inbred bastard love child of ASP and Perl. (I think that is still an accurate assessment btw.) Back then I was already shifting from doing web apps in C++ or Perl to doing them with JSP or ASP. I didn’t need to learn yet another way to do the same stuff.

I did give PHP a try a few years later, around 2003. I installed a Slashdot-style app written in PHP which I planned to customize. I didn’t get far. The app turned out to have security issues. Major, major security issues which took out my fancy-schmancy leased server. This was during a time when I was trying to bootstrap a one-man startup. I recovered most of my data and I had backups for the most important things, but I lost my development velocity completely. Losing velocity can be death to any startup, but it was certain death to an under-funded one-man show like mine. I ran out of cash shortly after I was hacked. My attitude about PHP didn’t improve. Fair or not, I decided that PHP was for morons and it didn’t have the maturity required for real apps.

Time passed. Old wounds healed, and I finally started to get curious about PHP again. Last fall I went book shopping. I picked up a book on Erlang, one on Python, and one on PHP. It look me a while to get around to reading it, but when I did I was impressed. PHP can do all sorts of wonderful things.

Things that are good about PHP:

• The culture values simplicity and efficiency.
• It fills the gap left by classic ASP and it fulfills the same code-in-template need that ASP satisfied.
• You can run it from the command line. That makes it very test-friendly.
• It provides many features you’d want from an app server but it is still low level.
• It is fast.
• It’s available on a huge number of web servers in the world.

Of course PHP isn’t all puppies and kittens. Here are some things that are bad about PHP:

• It’s a screwy improvised language which tries to look like Perl but works more like C but also sometimes like Python.
• Its tag scheme sucks.
• There are many gotchas and not everything works as advertised.
• The learning curve is non-linear and downright rocky in places.

While I certainly do NOT miss Visual Basic or VBScript, I really, really miss doing apps in classic ASP. I used to be dead-set against systems that mixed programmatic code and HTML together in the same file. But after many, many years of doing it several different ways I have to say that I prefer the ASP way in many – if not most – common situations. Mixed systems like ASP or PHP require discipline to use effectively but they also offer great power and flexibility.

So I now respect the hell out of PHP. But there’s just no way in hell I’m going to use it for many projects.

Why? Because those many items on the “good” list don’t make up for those few items on the “bad” list. PHP can be fairly simple to work with, but when you least expect it PHP can be a fucking bear. Just the other day I spent 4 hours fighting with PHP to get a simple filter working with my blog posts. Wordpress is written in PHP and it lets you create custom filters. All I needed was some regex love in my filter. In Perl it would have taken me no more than 25-30 minutes. (And that’s because my Perl is rusty. If my Perl skizillz were current I would have been done in about 90 seconds. Seriously. It was a small task.) But I could never get it working the way I wanted it to in PHP. I eventually gave up and fell back to manual split/substr style filtering like I used to do when I was a newbie programmer and didn’t know any better. I’m almost as pissed about the inelegant solution as I am about losing 3-4 hours for no good reason.

This doesn’t mean I’m done with PHP though. I’ve been thinking about this for a while now, and I’ve come to the conclusion that PHP can be to the web what C is to Unix. Think of it as a portable assembler for the web. PHP runs everywhere and it’s fairly straightforward and also fairly low level. PHP also has some added mojo because it is naturally parallizable. PHP would make a wonderful target language for a “little language” compiler. Especially for a distributed solution.

I know that there is already Fogcreek’s Wasabi. But that’s not exactly what I’m talking about. Joel and Co. have solved only their own product problems and it sounds more like language translation than compilation. Wasabi (near as I can tell since it isn’t publicly available) doesn’t go all the way with the idea. I’m saying, GO ALL THE WAY. Make your own compiler that spits out PHP. I’m not saying compile Ruby to PHP so you can run Rails on it. That’s kind of nuts. (But hey, no one is stopping you.) Instead, I’m saying that you can take that custom DSL you created in Blub and implement it as your own little language. Have it output PHP and see what happens. That’s what I’m going to do. I think it’ll be a lot of fun.