Imperative (Code)

Code is dead. Long live code.

And keep it simple 😉

Coming soon, from somewhere: A user-friendly gui for simplified mapping, visualization, description, and implementation of complex data flow systems.

Find #1: Now here’s a cool project that takes things in the general direction I’m thinking of. They’re IoT focused, which is neat.

Find #2: These folks also have the right idea, but on a very different track. It’s more architectural and geared for serious coders. Still, that can be changed with a little UI work.

Find #3: And finally, more of a closer fit. Category Theory! Not sure how user-friendly this stack will be though.

Of course, if buy isn’t an option… there’s always build.

The general idea is to give people a new-ish sort of intuitive flow-mapping tool that can be used to handily describe everyday flow problems and quickly design solutions for them.

In other words, I want to see if it’s possible to build a software toolkit that requires way less arbitrary memorization of syntax and notation while making it easier to see and undo any mistakes after the fact.

If someone gets that just right, we should be able to raise up a new generation of developers that were previously barred from the field due to steep learning curves and massive education barriers. And I suppose it should also help organizations generally in their ability to churn out working software.

You would want to make it functionally pure and type safe. It should be UI-driven, even at the level of syntax. It would also need to be diagrammatic, making it easy for people to pick up and play. It should also have a few other neat tricks built-in (such as mathematically consistent data transformations and an OOTB unit test framework), and plenty of extensibility, of course.

It will make coffee. And espresso.

It will also make ice cream.

And naturally, coffee- and esspresso-flavored ice cream. Plus some other core flavors, since not everyone likes coffee as much as some of us.

But who knows, really… we’ll find out when we get there 😉

It’s all highly speculative and I’m generally pretty hit or miss on this stuff.

If the base toolkit works and things don’t get all scooped up – both big ifs – the plan is… well honestly I’m not sure what the plan is.

We could probably just start from some kind of implementation of the job shop scheduling problem that applies directly to business flow software. After all, start from where you are. Plus, that should do a pretty decent job of highlighting all the tradeoffs of this kind of approach (vs. the existing competitors).

(Unlike the base framework, a business flow app might actually interest my employer, too. Which… could be helpful, since I have no plans on quitting my day job. I’ve got a pretty good gig.)

Update: Recently I’ve been thinking it works best as an abstraction layer for back-end development and microservice architecture.

Regardless, I’m pretty sure this trajectory leads somewhere fascinating.

I just hope it’s useful.

“Soon” := Give me a few years, yeesh. Slow down with all the questions.

Create a website or blog at

Up ↑

%d bloggers like this: