[im_down_w_otp]

I'm curious if you've tried Simulink? Because my experience with visual programming tools maps largely to yours. Especially the RAD tools of the late-90's and early-00's. Eventually you get to a place where the "simple" thing is a dizzying array of radio buttons and check boxes to manage that are all hidden away in their own little silos that you can only get to by drilling down through the visual hierarchy.

This becomes a huge problem with your "pivot" for changing things is plumbing up and down, up and down, up and down the hierarchy. Instead of being able to flip the whole thing on its head and seeing all the settings/flags/options for whole classes & categories of similar things and changing them from that perspective.

It's like there's a transition point where you know enough about how things are all put together that being forced to interact with multiple things at once only through the top of their individual silos starts to fall apart pretty dramatically.

The reason I ask about Simulink, is that it's very common in the toolchain of our customers (I'm CEO of https://www.auxon.io) and we're building an integration to it for our product. For the most part it seems to do a much better job of being an IDE for more complicated models/programs compared to the bevy of RAD tools I've used in the past. I have certainly encountered limitations reminiscent of those old RAD ways, but I can also see how much better a job it seems to do before you hit those snags.

[w_t_payne]

I've used Simulink a lot in the past, and the things that it gives you (as well as it's limitations) are a big driver for my attempts to build tools in this space (I think I'm trying to do a similar thing to you -- causal reasoning using data flow information and other graph-structured engineering data such as requirements traces).

[im_down_w_otp]

Yeah, that's the first half of our stack. Ultimately it exists in service of the second half of our stack which is for automatically stressing and analyzing system behavior to localize root causes, uncover emergent properties, and auto-optimize system parameters.

On the way toward building everything we needed for the analysis we wanted to do we realized we had a distributed tracing system suitable for continuous system lifecycles & embedded systems (as opposed to transactional lifecycles & IT systems) and a spec/query mechanism over what amounts to a logic model derived from system executions. That sort of thing tends to be valuable to folks who aren't as far along in their development or use case maturity to need bleeding out all the corner cases & "unknown unknowns" from their systems, so we exposed many of our building blocks as features themselves.

Somewhat ironically, given the thread this is all related to, everything we build today is for CLI consumption on Linux and Windows. We will build out a kind of IDE/Workbench UI this year to fulfill some of our vision around the category of CAE tools we're angling toward, and to access additional kinds of customers, but predominantly folks have preferred CLI shaped tooling because it's easier for them to bake our continuous verification & validation capabilities into their existing processes when we don't force them into a siloed GUI.

[w_t_payne]

I'd love to have a chat at some point. I'm trying to (slowly) bootstrap some tools for the embedded space, and we're trying to get a grasp on (a) what our MVP should look like, and (b) how to go about approaching customer #1.

[im_down_w_otp]

Happy to chat sometime. Any preferred way to connect?