I've enjoyed the Smalltalk world of 'file-less' programming for many years now. It's great, pure and simple. Putting source code in to files seems so antiquated these days. Or as some famous person once said "Source code in files? How quaint".

So today I figured I'd take that a little further. One thing that I want to do with Smalltalk and any language I work on is to dump source code.. completely. So to retool the quote "Source code? Don't make me laugh."

What the heck am I talking about? Well, when we transport code around we generally do it as either bytecode or compiled code. Most modern languages transport the code around using bytecodes and then JIT them at runtime (or load time) to make them fast on the machine you're using.

But then you also have this 'source code' stuff that's meant to describe how to make the bytecode. Why? The bytecode already knows how to be itself - it may not know names for things, but it is what it is. The source code, essentially, is a parse tree with some extra metadata like comments, whitespace, etc. Parse trees are essentially bytecode without a platform assumption (ie: stack based) and with names for things.

So, why not keep a little extra information around. Remember the names of things in your bytecode. In Smalltalk we have a bytecode decompiler that will recreate the source for you. Unfortunately, since it doesn't know names, you end up with names like "temp1" "arg2" etc. If it knew the names, your code would come back almost always exactly the same as you left it.

This plays in to the land of code formatting. Formatting only matters if the environment you're in lets you keep it. This environment wouldn't let you keep it(many C programs always run a lint and tidy filter on committed source code any way).

So now we can transport our program around and within it is the real representation of what a human wrote too. The extra information is minuscule and can be stripped out if required, but in essence, we've dumped source code completely. The image is leaner, the source code repository is leaner, the transportation of code is simpler. The benefits are huge.

Best yet, the developer sees the code how they want to see it. Formatted how they want to format it, in the syntax they like the most and it has no effect on how the program actually works.

There's only one big hurdle stopping me from implementing this in Visual Works. The debugger cannot add breakpoints to decompiled methods :/