I was reading a bit about the usefulness of keeping your class diagrams hand-drawn, and the idea really appealed to me. But for purposes of this post, hand-drawn diagrams aren’t nearly as interesting as the fact that I like hand-drawn diagrams.
You may have noticed I’m sort of a software hippie. I want us to all draw, brainstorm, think, talk, break free from various shackles and sit in a circle weaving software out of reeds.
I have this hope that by challenging some assumptions about software engineering we can make it easier to do, more creative, natural, etc.
Which of these assumptions are simply unchallengeable though? Which are just inherent to software? How about the fact that we need to create compile-able code? After all, if we don’t create code, is it still software engineering? Is it still programming? If we say we should let people translate our source code into assembly, we still have people making code, we’ve just moved it down a notch. If we try to say that we should write instructions to people, who will wizard-of-Oz some standard components around the screen, we’re really just designing a service or process, one which happens to interface through a computer; we’re not really programming anymore. So lets call that one insurmountable – we need to create compile-able code.
That may be an obvious assumption, but to me it is a bit of a sobering one. The fact is, no matter what you put in between, people need to create something that a machine knows how to turn into a program. That implies that no matter how creative and free spirited we want to be throughout the process, eventually we have to play by the machine’s rules.
I want to know what other assumptions really truly hold about the way we do software though. What is inescapable, and what is just really deep-seated. The later stuff might be worth challenging. So today I want to look at deterministic compiling.
Given my assumption about, it’s definately a machine we’re talking to. What does that imply? Well a major difference between machines and people is that the former is predictable. In fact, barring a nano-level anomoly, we can usually consider the work of electronic machines to be deterministic. A goes in, B comes out. Therefore, whenever A goes in, B will come out. The same code will always compile into the same exact program. Is this an ironclad assumption though? Is this something that is always, but always, true?
Maybe not. Could we have a fuzzy compiler, where you would give it some code and it would take a stab at what you wanted, with some amount of guesswork in between? And each time you compiled it, it would have a slightly different take on your code. Perhaps you would give it feedback on how you liked your code compiled, or genetically work your way towards certain builds by selecting among alternatives. It might be possible to tweak individual decisions run-time, so that you throw down a code skeleton, look at it, and push and pull things into place. Every time it was compiled, your code would hash out a build ID that you could use, along with the source code, to get that build again.
This might be useful to divergently test a wide variety of approaches to an interface, or to an algorithm. It might simply be used to write prototypes of basic principles with a minimum of lines of code. It might be used to happen upon interesting configurations in games?
In some ways, it’s a terrible idea. It sounds like a hassle. I have no idea if the technology to do this satisfactorily will ever exist. It’s totally impractical to have such a tenuous link between the code and the result – as if this connection wasn’t opaque enough (see my last post!)! How are we supposed to test our software if every time we compile it we are intentionally introducing uncertainty. These reasons and countless others are among the reasons we aren’t doing this as programmers.
But am I willing to concede as a fundamental assumption that code must be compiled deterministically into a program? Not yet. And that is an assumption I think a lot of people take for granted. Not sure what challenging it will ever accomplish, but I think its helpful to recognize, in your own mind, what assumptions about software engineering you consider to be ironclad, and which have cracks through which ideas might slip.
