Leaderboard

Allow me to introduce you to implied spaces. When I build a two-story house, I consciously add a staircase between the zeroth and first floors. I add handrails for safety, optimize the height of the steps for average human legs, etc. I spend a lot of time designing the staircase. What I don't spend a lot of time designing is the room under the stairs. I put a door on it and turn it into a closet, a storage place for the people who live in the house. Now, the people who live in the house start using that storage space -- exactly as intended. But after a while, they are complaining that frequently, they need something at the back of the storage space, so they have to take everything out to get it and then put everything back in. You ask me, "Didn't you put other closets in the house?! Why aren't they storing more things in the other closets?" I did add other closets: I wasn't that short-sighted. But it turns out that this staircase closet is taller than any of the others, so it holds things nothing else holds... wasn't intended, just happens to work because it is under a two-story staircase. Also, this is central in the house, so it is closer than the other closets, so the users think that the time needed to pull everything out to get to something at the back isn't *so* bad. The users of the space made it work, but there is accidental complexity in how they have evolved to use it. I didn't do anything wrong in the design, they didn't do anything wrong in giving me their requirements. It just happened with no one at fault. With this new understanding of my users, I refactor the house and add a second door on the short end of the stairs so people can pull from either end. Suddenly the under-the-stairs closet is not an implied space but an intended space. It doesn't matter how much you refine a design, there are always places that are implied within the design that are not spec'd out. It's a macroscopic aspect of Godel's Incompleteness Theorem. Some things aren't designed; they just work the way they work because they're near the things that are designed. And when users start relying upon that implied functionality, that is accidental complexity. Inspiration for this post from the novel Implied Spaces by Walter Jon Williams and Whit by Ian Banks, two science fiction novels that happened to give me good advice on software design. Accidentally... I think.

Does this mean the Actor Framework functionality will now be represented graphically in NXG, as apposed to a list of hundreds of class VIs in a tree in the project?

You are right, frameworks do have significant learning curves. Still, if a framework can (potentially) satisfy your needs, even if it looks very complex, you shouldn't be afraid to take a closer look. You can probably filter out most of the frameworks by reading the readme. No need to learn and compare all of them (unless you are scientifically interested of course 😉). Very interesting, thanks for sharing! Among other things, he lists quite a few frameworks, some of which haven't been mentioned yet (see timestamp 19:32). I couldn't find the slides, so here is my attempt to restore the links: Composed System STREAM (bitbucket) Dave Snyder Lap Dog API (GitHub) Delacor DQMH (product page) James Powell Messenger Library (bitbucket) JKI State Machine Object (built on JKI State Machine) (GitHub) Mark Balla Message Routing Architecture (LAVA) NI Actor Framework (part of LabVIEW) NI Distributed Control and Automation Framework (DCAF) (product page) S5 ALOHA Application Framework (product page) Event Source Actor Package (NI forums)