Writing Code Should be More Like Circuit Design

7476.png

Previously, I’ve written about FlowSharpCode and Visual Assisted Programming / Organizational Representation (V.A.P.O.R.)  Here’s a simple example of what I mean by this concept.

My first technology passion was actually hardware, but it was expensive (a 7476 flip flop in the 70’s cost $4.50 from Radio Shack, if I remember correctly.)  So I started goofing around with software — BASIC on a PDP/11, HP calculators, BASIC on a Commodore PET, etc.

But software was always missing something for me – a visual way of describing what the software does.  You see, software and hardware are very similar — they are both essentially a circuit.  With hardware, the lines describe the paths of electrons (signals) and the components describe how those signals are manipulated, (their voltages and current) like in this simple circuit that produces a tone you can vary using a 555 timer chip, a speaker, and some discrete components:

555-2.png

(By the way, the history of the 555 timer is quite amazing.)  “Camenzind spent nearly a year testing breadboard prototypes, drawing the circuit components on paper, and cutting sheets of Rubylitha masking film. “It was all done by hand, no computer,” he says. His final design had 23 transistors, 16 resistors, and 2 diodes.”

If we want to write a simple WinForm C# app to do the same thing (more or less):

winform.png

we need about 142 lines of code, which you can view on this Gist.

The Play button acts like B1 in the schematic, the trackbar is the variable resistor in RV1, and the code implements the 555 timer (generates a sine wave in this case) and speaker is actually a call to System.Media.SoundPlayer

So What’s the Problem?

Someone was said to me that they would never use an editor that didn’t have outlining capability.  And you can sort of see why — even 142 lines of code is a lot to look at to glean what is going.  Outlining helps:

outline.png

because at least it shows you what the top level methods are, so you can see what the programmer had in mind for overall structure.

If the programmer wrote the code with a sufficient fine level of granularity.  That’s a big “if.”  In fact, I refactored my original code (which was originally just Main and Play, so that there was something more to show here in the outline.

A good IDE also provides some useful information – here is what Visual Studio tells you about the file:

vsinfo.png

In both cases, what is lost is what was expressed so nicely in the hardware schematic:

555-2.png

the flow of signal!  A list of classes, fields, properties, and methods is like getting a bag of wires, chips, and discrete components:

grabbag.jpg

you still have no idea of how the program wires it all up!  To figure that out, you have to read the code and create, for yourself, a mental map (or maybe even some pen & paper flowcharting) of what the code is doing.  For the sound player, that’s trivial.  For thousands (or hundreds of thousands or millions of lines) of code, that is anything but trivial.

But We’ve Been Here, Done That

Or have we?  It’s ironic to me that hardware engineers are always using visual tools (software nowadays) to design, implement, and simulate their hardware, yet we have nothing like that for software.  Sure, there’s been numerous attempts, and of course we have various tools that create diagrams for us or even let us work in a diagramming mode.  Some of these tools will generate code stubs, some will reverse engineer code into diagram (the most sophisticated of which can actually parse your code.)

A few visual tools that have been tried, some with limited success, are:

UML

umlactor.png

BPEL and WWF

bpel.png

Schema Diagramming

db.png

Lego-like Programming (like Scratch)

scratch.png

Do These Tools Work?

For what they’re designed to do, yes, but I find these tools do very little to help me express visually the day-to-day work of writing code.  They are either too high level, too abstract, or too low level, too childish, or don’t work with the languages that I use, and, most importantly, limit me in how I want to express concepts, at the granularity that I think is appropriate.

V.A.P.O.R – Visual Assisted Programming / Organic Representation

You may notice I changed that “O” to Organic (it used to be Organizational.)

This is one way to express what the tone player “circuit” look like using FlowSharpCode (the thing that implements V.A.P.O.R):

soundPlayer.png

This should give you a moment of pause.

Notice:

  1. Yes, this is a working, running, application.
  2. The UI is on the same surface as the implementing code.
  3. The surface is visual, annotated representation of the program.
  4. A simple workflow is demonstrated, which helps to visualize the individual steps of a particular process.
  5. Arbitrary shapes and groups can be used for code fragments.

Where’s the Code?

That’s the beauty if it.  The code is embedded in each shape.  The shape can be anything–in fact, the speaker is actually a grouped rectangle and a triangle with appropriate z-ordering.  The code-behind is in the group box containing those two shapes!

IC’s

We can even package code into re-usable “integrated circuits”, implemented either as separate assemblies (dll’s) or simply by grouping them into logical and re-usable compositions:

  • The Waveform Generator group is like the 555 timer.
  • The speaker is, well, a speaker.
  • The Play button is like the button in the schematic.
  • The TrackBar control is like the variable resistor that changes the frequency.

If I want to re-use an IC (or even just a code fragment), I just copy and paste the desired shapes to my own application surface, and I get the shapes, the annotations, and the code-behind.

Now, granted, there’s three “IC’s” to make this all work that I haven’t shown in the picture above, consisting of:

  1. A bootstrapper to handle UI events (and internal events, but there aren’t any in this application.)
  2. A simple server that provides the communication channel to interface between the UI events and the application.  Why?  Because the UI events are actually generated from services running in the FlowSharpCode application, and we need to inform the SoundPlayer application of those events.
  3. A mechanism for updating the UI (which is hosted in FlowSharpCode) when state changes, in this case, Play and Stop.

More on all this later!

Is this concept limited to C# code?

Certainly not.  While I’m using C# for this demonstration and the SharpDevelop code editor, the code editor, compiler, etc, are services that are plugged in to FlowSharpCode.  Other services, supporting Java, Javascript, Node, Ruby, Python, along with syntax highlighting editors, etc., can be plugged in to FlowSharpCode as well.  In fact, one of the goals is to write FlowSharpCode as a web application, where your code, in whatever language you like, is built on a server, and you’re actually building web apps.

Can Coding be More Like Circuit Layout?

I certainly think so, and besides this simple demonstration, I’ve used this same process for writing an implementation of my favorite “prove the technology” game, Hunt The Wumpus.  I’ll be writing more about that soon!

Adding Services to FlowSharp

overview.png

I’ve been reworking FlowSharp into a “Service Oriented Architecture.”  As the above overview diagram illustrates, there are now three major service blocks:

  1. Docking services – The toolbar and property grid are now dockable, and canvases are treated as dockable documents, so you can have multiple documents in one application.
  2. The various controllers and functions of FlowSharp have been converted to services (see below)
  3. As a result, I’ve been able to add the “shapes as code” in the FlowSharpCode project that I wrote about earlier.  The beauty of this is, adding the FlowSharpCode services “simply” requires defining the services in modules.xml and the additional shapes in plugins.txt.

The architecture relies on The Clifton Method discussed previously.

Here’s a full blown gloriosky architecture diagram:

architecture-small.png

Find FlowSharp on GitHub!

At the time of this writing, there’s still a few critical bugs to update the Code Project article, but I hope to get them resolved soon!

V.A.P.O.R.ware – Visual Assisted Programming / Organizational Representation

vapor2.png

Actually the name of the application is FlowSharpCode, but VAPORware sounds more fun!

Article here.

Excerpt:

This is purely a concept piece.  It’s intended to either inspire or cause an eye rolling “what a crazy idea” reaction.  It is crazy, in my opinion, but in a sense it’s crazy because in my limited use cases so far, it works.  And because it’s so crazy, the majority of this article will not be written, it’ll be screenshots of the application in use. The problem with this approach is that it ends up sort of looking like a PowerPoint presentation, which is hard to avoid!

Why I Closed my PayPal Account

paypal.png

It’s quite simple.  In whatever ways that I can, I refuse to support people / businesses that support Donald Trump.

On October 15, 2016, Thiel announced a $1.25 million donation in support of Donald Trump’s Presidential campaign.

And quite frankly, if you want to do something to truly protest the nomination of Trump, I suggest we make a collective and concerted effort to identify and withdraw our support from the businesses and politicians that support Trump, where it hurts them the most – their wallet.