This post originated from an RSS feed registered with Agile Buzz by James Robertson. Original Post: Down with source code! Feed Title: Michael Lucas-Smith Feed URL: http://www.michaellucassmith.com/site.atom Feed Description: Smalltalk and my misinterpretations of life Latest Agile Buzz Posts Latest Agile Buzz Posts by James Robertson Latest Posts From Michael Lucas-Smith

Why is it we religiously place textual source code in code repositories and keep .pst files around on our disk drives?

Let's take a nice looking method:

nextPut: aCharacter on: aStream 
	"Encode aCharacter and write it to encoded stream."

	aCharacter = Character space ifTrue: [^aStream nextPutAll: ' '].
	(aCharacter isAlphaNumeric or: [aCharacter == $_]) not
		ifTrue:
			[aStream nextPut: $%.
			aCharacter asInteger
				printOn: aStream
				base: 16
				digitsToPad: 2
				highDigit: 2.
			^self].
	aStream nextPut: aCharacter

I chose this method because it looks slightly ugly, yet has some parameters. It's a shame it doesn't have some temp's as well, but we can't have everything when we're randomly looking for code examples.

This is the same method decompiled:

nextPut: t1 on: t2
	t1 = Character space ifTrue: [^t2 nextPutAll: ' '].
	(t1 isAlphaNumeric or: [t1 == $_]) not
		ifTrue:
			[t2 nextPut: $%.
			t1 asInteger
 
				printOn: t2
				base: 16
				digitsToPad: 2
				highDigit: 2.
			^self].
	t2 nextPut: t1.
	^self

If we rename the variables back to what they were originally, we end up with the exact same code as the original, except that there's an extra ^self on the end - which could be excluded by a decompiler any way.

To me, this says we should stop bothering to keep our smalltalk code around and just keep the bytecodes + some metadata about variable names. They're smaller and you can do more with them.

Textual representation should be a transient thing for us clumsey humans.

... of course, there is one drawback. For some reason you cannot put breakpoints in decompiled code? Why is this? a breakpoint should be -on- a bytecode anyway, so what has the sourcecode to do with it?

Comments: These are easy. The majority of comments are actually method comments, so they don't belong in the parse tree at all, so they are metadata. But hey, a comment that is in the parse tree can also be metadata, just linked to a position in the parse tree. Not a worry there.

Formatting: Oh yes, this lovely argument. There are two sides to this argument and I'll get to them both. First off, you can make the formatter in your image format your code however you like. But that's only half the argument apparently.

On the Squeak mailing list there was a big argument about being able to see -other- peoples formatting to see their coding style. Well, Kent Beck did write "Best Practiced Patterns" for a reason... flame me if you want, but I don't agree, just keep it consistent. if you want to know who wrote the code, stick their name in a version history or against the method name or something. Sheesh.