Poll on Architecture and Frameworks

[drjdpowell]

7 hours ago, G-CODE said:

I'm so habituated to creating typedefs, events, and registrations for every message. Maybe there's a better way

I remember a conversation, which I can't find now, where AQ mentioned that most messages will involve multiple bits of information, but I was surprised because I think it's natural for messages to usually only having a single piece of info.  Often just a simple number, path, string. Even when the message contains a typedef cluster (or class) that typedef usually exists for reasons beyond the message.  So I might have a "Data Set" object that passes through multiple actors for different types of processing, using a generic message rather than a number of type-specific messages.

[MikaelH]

Company made version, based on Ref-based OO and active objects.

[drjdpowell]

Ah, by-ref objects, GOOP, G#, and the like. That should have been a poll option.

[Michael Aivaliotis]

I'm glad to see all these frameworks being bashed about. I like to read opinions from people who have tried the various frameworks and can compare based on real implementations. Not example code. Just came back from the US CLA summit (videos being posted to LabVIEW Wiki soon). Apparently there's YAF (Yet Another Framework) being used by Composed Systems and it was presented at the CLA summit: https://bitbucket.org/composedsystems/mva-framework/src/master/

It seems to be an actor-framework extension. Framework on top of framework? Jon argued that the complexity of a framework is secondary to the ability of a framework to allow certain programming concepts to be used during development. One being, separation of concerns. if you look at slide 4, Jon vehemently disagrees with that statement. In other words, you should not look at a complex framework and be afraid of it. Don't focus only on how easy it is to learn or get going with it.

Question to you. What is important in choosing a framework?

Here's a link to the slides: https://labviewwiki.org/w/images/2/24/Design_for_Change.pdf

[LogMAN]

15 minutes ago, Michael Aivaliotis said:

What is important in choosing a framework?

Here are my main points. Most of them are only indirectly connected to programming:

• It should be necessary; Don't use a framework just for the sake of using it.
• It should solve a problem or provide desirable features, whatever that means for your project.
• Its external complexity should be reasonable for the task.
• It should provide a way to track and fix bugs without having to depend on 3rd-parties (what do you do if they disappear?).
• If it's an essential part of your project, make sure to invest enough time to understand its limitations.

There are of course a range of quality attributes that should be taken into consideration. Which ones are important depends on the kind of project you are working on.
Of course, do whatever you want for throwaway projects.

1 hour ago, Michael Aivaliotis said:

Jon argued that the complexity of a framework is secondary to the ability of a framework to allow certain programming concepts to be used during development. One being, separation of concerns. if you look at slide 4, Jon vehemently disagrees with that statement. In other words, you should not look at a complex framework and be afraid of it. Don't focus only on how easy it is to learn or get going with it.

Of course we shouldn't be afraid to learn about new frameworks, no matter how complex or simple they may appear. Even if we decide to never use them. How else would you know if they are up for the job?
Once you know their abilities and limitations you can make them part of your architecture design. The complexity is secondary indeed.

[ShaunR]

5 hours ago, Michael Aivaliotis said:

Here's a link to the slides: https://labviewwiki.org/w/images/2/24/Design_for_Change.pdf

IMO. For the API he has the cost and benefits reversed. The interface is the benefit. The hidden functionality to achieve the interface is the cost.

Edited October 1, 2019 by ShaunR

[ThomasGutzler]

Using my company's template which is basically a JKI statemachine with OpenGDS active objects sprinkled on top which communicate via queues and/or events

[drjdpowell]

On 10/1/2019 at 6:41 AM, Michael Aivaliotis said:

I like to read opinions from people who have tried the various frameworks and can compare based on real implementations.

 

On 10/1/2019 at 8:11 AM, LogMAN said:

Of course we shouldn't be afraid to learn about new frameworks, no matter how complex or simple they may appear.

Unfortunately, there is a significant learning curve for all frameworks, so it is hard to compare them.  Here though is a GDevCon1 talk by Richard Thomas, where he discusses frameworks: 

Frameworks: An Executive Summary

[LogMAN]

2 hours ago, drjdpowell said:

Unfortunately, there is a significant learning curve for all frameworks, so it is hard to compare them.

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 😉).

3 hours ago, drjdpowell said:

Here though is a GDevCon1 talk by Richard Thomas, where he discusses frameworks

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)

[hooovahh]

SMorRES - Scalable, Modular, Reusable, Extensible, Simple.  I do like architectures and frameworks to be simple, but not at the cost of scalability, modularity, reusability, or extensibility.

[drjdpowell]

A big part of the payoff of a good framework is making large complex applications simpler. But it's hard to see this when you're on the wrong side of the learning curve.

[Albert Geven]

1. I still use a framework developed within Philips long ago. It is a qmh with good default initialization and a modified ini-file library that handles 2D data readable for excel sheets.
2. played with DQMH
3. looked only at actor framework

[Steve Watts]

Our own, LCOD based statemachine and unnamed but packaged queue.

Covers 99% of our needs, what others call actors, we tend to call services and are only employed when background stuff is needed. Each service will be based on the template above.

[jon_mcbee]

As Michael mentioned above we (Composed Systems) primarily use the MVA Framework (which is an extension of the Actor Framework).  One note is that MVA is our separation of concerns focused framework that we use for decoupling of UI and Business Logic and the messaging between them, but we also use other frameworks that are not messaging frameworks for other aspects of development.  After a few years of building up our tool chain we have MVA for messaging, a sequencing framework (Test Executive), and an event logging framework.  We use each of these frameworks in each of our projects and extend each for application specific needs.  

I had lunch with a customer last week that we have been working with for coming up on two years, and he was saying that from his point of view he doesn't program in LabVIEW anymore, he just uses our tools (frameworks).  I think this is great, I'd be curious if other people agree or are horrified by it.

[jon_mcbee]

On 10/1/2019 at 6:57 AM, ShaunR said:

IMO. For the API he has the cost and benefits reversed. The interface is the benefit. The hidden functionality to achieve the interface is the cost.

So what I was going for was that the API has a cost associated with learning and using it as a consumer of the component, while the functionality encapsulated within the component is the benefit that you get when you pay the cost to consume the API.  As a consumer of the component you don't pay a cost for the functionality hidden behind the API, I suppose that if you find yourself paying a cost for the functionality hidden behind the component you would probably stop using the component because it isn't adding any value.

[YavannaKementari]

Most of our company (if they're using any standard at all) for LabVIEW utilize templates quite similar to DQMH, that was started over a decade ago and refined/upgraded through the years. Of course, unlike the DQMH we don't have the level of documentation, scripting, and unit testing that the DQMH comes with... I did write a few examples though! 😏

[drjdpowell]

2 hours ago, jon_mcbee said:

As Michael mentioned above we (Composed Systems) primarily use the MVA Framework (which is an extension of the Actor Framework). 

How does MVA relate to your STREAM framework that you've blogged about? 

[ShaunR]

1 hour ago, jon_mcbee said:

So what I was going for was that the API has a cost associated with learning and using it as a consumer of the component, while the functionality encapsulated within the component is the benefit that you get when you pay the cost to consume the API.  As a consumer of the component you don't pay a cost for the functionality hidden behind the API, I suppose that if you find yourself paying a cost for the functionality hidden behind the component you would probably stop using the component because it isn't adding any value.

Even by that definition, learning the API interface may be the cost in a larger Venn diagram but then the API *is* the functionality and code to support that interface is still the cost (code size, memory size, load times, execution times, compile times etc). The over-arching benefit for an API is simplification of complexity and complexity always has a cost. If you are lucky, the underlying complexity cost grows linearly as the API grows. If you are unlucky it is exponential. At some point it becomes unusable either because the underlying code is too complex to warrant the cost (e.g. labview build times for classes) or the underlying code is unmanageable/unmaintainable often with side effects (e.g. the "God" Class).

So I still maintain that the API is a benefit (that being reducing interface complexity and also reducing the learning required to achieve a goal) and, the underlying code is the cost of that benefit ... even from the  consumers point of view. The ancillory benefits of an API are reuse and parallelism which can alleviate the consumers' project cost but are not guaranteed for any and all APIs and is dependent on the underlying code; usually by adding complexity (thread safety as an example).

[jon_mcbee]

44 minutes ago, drjdpowell said:

How does MVA relate to your STREAM framework that you've blogged about? 

So Stream is a mediator-ish message/data bus with transport abstraction, so two parts of the code can publish/subscribe to data/message by type and name and not be concerned with how the data/message moves.  MVA takes what Stream does and uses it to extend the Actor Framework, while also building in extension points for Views, View Management, Models, and a ViewModel (so MVVM as an extension of the AF with a built in message/data bus to help decouple Views from Models).  Over the past two and a half years we have only used MVA for project code, so it is under active development/maintenance while Stream is not and has not been used in project code.  I am working on ramping back up with the blogging, been too busy with business lately unfortunately, and MVA will be featured more prominently in the new blog entries.

[jon_mcbee]

51 minutes ago, ShaunR said:

Even by that definition, learning the API interface may be the cost in a larger Venn diagram but then the API *is* the functionality and code to support that interface is still the cost (code size, memory size, load times, execution times, compile times etc). The over-arching benefit for an API is simplification of complexity and complexity always has a cost. If you are lucky, the underlying complexity cost grows linearly as the API grows. If you are unlucky it is exponential. At some point it becomes unusable either because the underlying code is too complex to warrant the cost (e.g. labview build times for classes) or the underlying code is unmanageable/unmaintainable often with side effects (e.g. the "God" Class).

So I still maintain that the API is a benefit (that being reducing interface complexity and also reducing the learning required to achieve a goal) and, the underlying code is the cost of that benefit ... even from the  consumers point of view. The ancillory benefits of an API are reuse and parallelism which can alleviate the consumers' project cost but are not guaranteed for any and all APIs and is dependent on the underlying code; usually by adding complexity (thread safety as an example).

I think that we are saying pretty similar things.  The only reason you would ever chose to consume a package is that the API hides complexity in a way that simplifies your application.  If the cost of consuming the API is high then you probably will decide not to consume it.  If the cost of the implementation behind the API is high you definitely will decide not to consume it (because what is the point?).  That said I suppose I should update the slides to explicitly show that cost/benefit is a sliding scale, something with low cost probably has high benefit, and something with high cost probably has low benefit, and that is true for both the API and the functionality behind it.

[Daklu]

I chose, "Other publicly available message-passing-style 'framework,'" though I could have also chosen "Your own or your company's internal framework or templates" or "Other (please post, this includes architecting each application from scratch)" since outside of a few templates I typically write each app more or less from scratch.  (I will yank modules used in previous apps and modify as needed, but I don't typically bother making them into reuse packages.)

Predictably, I use LapDog, and I'm glad you put "framework" in quotes as messaging libraries aren't frameworks. 

 

[Edit - BTW, thanks for posting this poll.  I was going to ask the same question at my CLA presentation but had to cancel my trip at the last minute.]

Edited October 15, 2019 by Daklu

[Aristos Queue]

On 9/27/2019 at 4:22 PM, MarkCG said:

There has to be a better way, were Actors , state machines, tags vs command vs streaming data, and easily handling thousands of I/Os are fundamental concepts of the language.

Y'all sometimes ask me, "AQ, why are you so eager for LabVIEW NXG?" Language extension is the biggest answer. The code layers of NXG are far more amenable to language extensions. I've got an 80-slide PPTX on actors as first-class citizens: no queue management, no classes for messages but retaining type safety, no weird error codes, easy handling of parallel loops without custom stop signals, direct execution testing, debug monitoring... but I just don't see it happening in LabVIEW. The compiler simply isn't sophisticated enough to take a high-level diagram and generate the code implied by it -- not enough separation between source model and execution model. NXG retains the existing execution model and builds a separate source model, which means the transforms possible in the compiler are waaaay more extensive.

And mine is not the only proposal on the table. I work with a team full of people who have alternate diagrams that bring the actor model more directly in line with data flow, or introduce various other types of dataflow. Did you see the Multi-Rate Diagram that was in LabVIEW Comms when it released? Sadly discontinued for various reasons, but it provided a totally different set of rules for how an upstream node triggers a downstream node. Likewise, Rebar is a different model of computation that can compile in the NXG compiler.    You've seen what we can do with channel wires already in LabVIEW... we can go sooooooooo much further in LabVIEW NXG.

PS: I was torn in the poll... "Do I choose 'Actor Framework' or do I choose 'my own framework'?" 🙂

Edited October 15, 2019 by Aristos Queue

[Daklu]

On 9/27/2019 at 2:14 AM, drjdpowell said:

I, in using Messenger Library, seem to spend almost no time bothered by problems caused run-time type mismatches, so I am not much impressed by the edit-time type safety if it comes with the negative trade offs of requiring large scripting tools to work productively. 

I have experienced the exact same thing using LapDog over the past 10 years.  There are very few (if any?) times when I have to have to write lengthy boiler-plate code that could be made more efficient with scripting.

[Daklu]

17 minutes ago, Aristos Queue said:

I've got an 80-slide PPTX on actors as first-class citizens...

Is this restricted to AF actors specifically, or would our own actors also be first-class citizens?

[Daklu]

On 10/14/2019 at 9:33 AM, ShaunR said:

If you are lucky, the underlying complexity cost grows linearly as the API grows. If you are unlucky it is exponential.

Funny you mention this.  Here's a slide from the most recent version of my Fundamentals of AOP presentation.

Edited October 15, 2019 by Daklu