Someone posted a follow-up question to my earlier post on Quora (my last post here):
How do you see the process changing so programmers can be more productive?
It’s what I said in that last sentence of my earlier post: “I’m not sure what, but I bet it’s going to be a highly visual process that looks more like digital circuit design than programming.”
The first integrated circuits involved someone sitting down and drawing lines. They were literally etching multiple layers into a silicon substrate, similar to how photographic lithography is done. (It was, in fact, a photolithographic process.) That’s how they did it for a LONG time. It’s analogous to how we program today, by writing lines of code, line by line.
But at some point it was realized that there’s no way they can continue to use that approach if they wanted to continue to add increasingly complex circuitry with wider data paths to silicon. Tools were created that let them stop dealing with individual lines, data paths, and simple logic circuits; they were able to draw one line that represented an entire data bus, add single blocks that represented buffers and latches for all of the wires in that data bus, and basically get away from having to deal with “wires” and instead deal with “logic” and “flow”.
We don’t do that in programming. Sure, we’ve got “objects” and “interfaces” and all of that good stuff. But they only increase the number of lines of code we need to write around the edges in order to reduce the complexity in the middle somewhat.
Then you pause and take a step back, look things over, and discover a whole bunch of redundancies you never noticed. Refactoring fixes that, but it’s not a profitable activity. You choose to incur what’s called “technical debt” and you pay the “interest” on it every time you have to modify any of that duplicate code in dozens or hundreds of places, one line at a time.
If each of those little chunks of code were a logic block, you’d change the block once and everywhere it was used would be updated. Similar to what we call “macros”.
We kind of do that today, but it’s up to each individual developer to recognize what’s in each of those little blocks. Unfortunately, too often we don’t see them until we’ve created a half-dozen or more of them that we can only see when we stand back and survey the landscape. At that point, we might see some, and miss others, possibly more than we find.
When the next person comes along to do some work, they have no idea there are all of these little pockets of duplicate code. So they fix a bug in one and it starts showing up elsewhere. It’s like whack-a-mole, and it drives your support costs through the roof.
It happens because as human beings we programmers (well, a lot of us, but not all) have the ability to look at our code and abstract out logical “chunks” in spite of localized variations of the details (different variable names, slightly varied syntax, maybe different ordering of lines, etc.) It’s not possible today for software to perform this kind of abstract pattern “discovery”.
We need to get away from programming in “statements” and “blocks” and programming instead in “chunks”. It’s possible today using procedures and functions, except it will lead to an explosion of such things, and we’d need the programming environment to do a far better job managing the exploding inventory of such “chunks” for us. Right now, you pretty much have to know what’s there, or what someone (hopefully) called something if you ever hope to find a function that does something specific. Again, we need better abstraction mechanisms to assist us in finding things that may already be in inventory, as well as things that “come close” to what we need.
This mechanism also needs the ability to “replicate”, or “generalize”, so if you make a logic block that works for one thing, and you need one that does the same thing for five of the same things, rather than putting down five blocks, the block needs to “expand” to deal with five “channels” of itself, even though each one might be slightly different.
This is the kind of stuff programmers spend a HUGE amount of time dealing with every day, although we don’t particularly notice — it’s like breathing: we can’t live (or make progress) without it.