Use of an abstract Message class to remove the "To More Specific Class" boiler-plate code in Message Class's Do.vi

[AristosQueue (NI)]

Intaris wrote:

Perhaps "niggling" would have been better.  A niggling flaw.

Darn. I was hoping you had a known existing solution. 🙂

[Daklu]

Intaris wrote:

Perhaps "niggling" would have been better.  A niggling flaw.

I'll suggest "flaw" isn't the correct word at all.  Few people have been as vocal as I have when it comes to challenging AQ's design of the AF, but at the end of the day what he has created is what he intended to create.  As it turns out, the decisions he has made for the AF have consequences that make it unsuitable for my customers and my workflow.  That doesn't mean it is flawed; it just means it doesn't work for me.

Type safety can be very useful, but when taken too far it makes the code hard to work on.  The trick is to find a balance between safety and flexibility that works for your development team and your project.  It's possible to create unique queue types for each actor to ensure it cannot ever be sent a message not meant for it, but for me the overhead isn't worth it.

[AristosQueue (NI)]

Since my goal is to build a single framework that works for all customers, I'll accept Intaris' term of "flaw". Probably my goal is an unachievable utopia, but it's my goal. Certainly if I could make it so that it was impossible to write code that sent a message to the wrong type of actor, I'd call that an improvement. 🙂

[Daklu]

AristosQueue wrote:

Certainly if I could make it so that it was impossible to write code that sent a message to the wrong type of actor, I'd call that an improvement. 🙂

No you wouldn't--otherwise you would have already done it.  I think what you mean to say is, "If I could make it so it was impossible to write code that sent a message to the wrong actor without throwing away all these other things I think are valuable, I'd call that an improvement."

AristosQueue wrote:

Since my goal is to build a single framework that works for all customers, I'll accept Intaris' term of "flaw". Probably my goal is an unachievable utopia, but it's my goal.

Not only is your goal an unachievable utopia, but I'd argue (and hope you'll forgive me for saying so) it's not a good goal to aim for, and it may not even be your real goal.  (I'm assuming "building a single framework that works for all customers" means the AF is the best solution for them.)

First, as I and a few other people have pointed out, some of the basic design decisions have consequences that immediately exclude the AF from being considered in our projects.  The AF will never "work" for us unless you change those decisions, and you can't do that without sacrificing some of your original goals for it.  You've said you're not going to revisit those decisions, so "all customers" has already been reduced to "all customers except those who share Daklu's concerns."

Second, among all the remaining customers there is a huge amount of variation in the developer's skill level, business requirements, project requirements, etc.  I don't think it is possible to build a single framework that works well across all combinations of those variables.  Without a clearly defined audience, there is no foundation for making decisions that involve tradeoffs.  By targeting all users, you risk diluting those features that are valuable to a specific subset of users, and that weakens the product overall. 

The most obvious example is the dichotomy between beginning users and advanced users.  Beginning users want something easy to understand and use.  Simplicity is the key.  Advanced users want the ability to control every detail so they can customize it to fit their project's requirements.  They want features.  Adding features to the API also adds complexity--there is no way around that.  Every feature you add will gain some number of advanced developers for which the AF now satisfies their needs.  You will also lose some number of beginning developers for which the AF is now too complicated.  (It's possible to minimize the increase in complexity by using advanced palettes, etc., but you can't eliminate it entirely.)

I may be completely off base, but based on what you've said over the years it appears to me your goal is to "build a single framework that works for the greatest number of customers."  That's a more precise goal and one that I think is achievable.

[AristosQueue (NI)]

Daklu wrote:

Advanced users want the ability to control every detail so they can customize it to fit their project's requirements.

Not true. Such users often find that they need the ability to control every detail because the framework is insufficiently intelligent to do it for them to the degree they need it done. That is NOT the same as saying they want to have to set all those details. My goal is and remains getting the framework to the point where the contemplation of how a message gets from point A to point B is entirely not something the programmer worries about because -- like the vast majority of compiler optimization these days -- the framework has more expert experience programmed into it than any single developer is able to bring to the table.

I stand by my previous post.

[Daklu]

AristosQueue wrote:

Such users often find that they need the ability to control every detail because the framework is insufficiently intelligent to do it for them to the degree they need it done. That is NOT the same as saying they want to have to set all those details.

Fair enough--they need to set every detail because their project requirements push the boundaries of the framework in some respect.  Maybe the requirement is performance related, maybe it is business related.  It doesn't really matter.  But if you want the framework to be intelligent enough to make all those decisions that developers and architects normally make, then you'll have to provide inputs for all factors that go into making that decision, and you'll have to provide some way to instruct the framework as to the relative importance of each of those inputs.

Here's a (perhaps overly) simple example--setting the size of the message queue on RT systems.  Suppose a beginning user wants to create actors to control LED blink rates so he can show off his contraption at the town fair.  The application is small and simple, messages are sent infrequently, and the user is an inexperienced programmer.  In this situation exposing the ability to set queue size is unnecessary complexity.  We understand he can leave the queue unbounded and his application will almost certainly run just fine.  Unfortunately *he* doesn't know that, and when he sees the option to set the size he needs to take time to research it and figure out if it's something he should be worried about.

Compare that with an RT code ninja who is able to eke every last drop of performance out of a system, and routinely writes applications that push the limits of code size, cpu/memory consuption, etc., and where random reboots are not acceptable.  This developer is going to want the ability to set the queue size so he has more direct control over memory consumption, and he'll have to write his app in a way that recovers from full queues without taking down the entire system.

So as the API designer, what do you do?  Do you prohibit setting queue size in favor of the beginning developer, or do you support the advanced developer by allowing him to set queue size and just accept the added complexity?

Or do you take the third path and try to make the AF smart enough to decide on its own what size the queue should be?  If that's the case, what information is the AF going to use to make the decision?  How will the AF know what an actor should do when it attempts to send a message and the queue is full?  How are you going to include this intelligent capability without adding complexity to the API?

[komorbela]

Hi Daklu,

You have written that:

... The AF will never "work" for us unless you change those decisions, and you can't do that without sacrificing some of your original goals for it.  You've said you're not going to revisit those decisions, so "all customers" has already been reduced to "all customers except those who share Daklu's concerns."

Could you please show me a place where your and other people's reasonable concerns are summarized? In case it doesn't exist could you shortly summarize those in a post? I personally don't have all concerns in mind (and maybe I am not the only one). It would be really great to have a collection of concerns to let everyone quickly review those, whenever needed. For example someone new to AF could quickly check whether to use it for a new project or not.

[Daklu]

Short answer

Actually, I'd rather not.

Long answer

"Concerns" may not be the correct word.  It's more of a "reasons why we don't use the AF."  Unfortunately there isn't a single place where these reasons are summarized--they're kind of scattered around this forum and LAVA--and I don't think it's appropriate for me to start a thread here listing the reasons why the AF doesn't work for us.  (Yep, there are lines even *I* won't cross.)

In previous threads the discussions about these reasons have arisen naturally from whatever we were talking about, and I wanted to make sure AQ understood why the AF doesn't work for us.  We've been though it enough times that I'm pretty sure he understands our reasons by now.  I don't know if he is going to address our reasons in future versions of the AF; he hasn't shared his plans with me.  But he said he wants the framework to work for all customers, so maybe he does.  *shrug*

I will say this though...  In my opinion there are certain types of projects and environments where the actor framework is particularly well suited.  For example, projects which, a) have an experienced architect leading a team of junior developers, b) has a firm set of requirements that will not change, and c) does a lot of detailed design up front, could get a lot of value from using the actor framework.  That's not to say projects that don't have those characteristics can't or shouldn't use the AF.  It's just that those characteristics coincide nicely with the strengths of the AF.

[AristosQueue (NI)]

Daklu wrote:

I don't know if he is going to address our reasons in future versions of the AF; he hasn't shared his plans with me.  But he said he wants the framework to work for all customers, so maybe he does.  *shrug*

If I ever figure out how to unify them, yes. At the moment, and for the foreseeable future, it remains an area of research with no specific plans.

[justACS]

Daklu wrote:

I will say this though...  In my opinion there are certain types of projects and environments where the actor framework is particularly well suited.  For example, projects which, a) have an experienced architect leading a team of junior developers, b) has a firm set of requirements that will not change, and c) does a lot of detailed design up front, could get a lot of value from using the actor framework.  That's not to say projects that don't have those characteristics can't or shouldn't use the AF.  It's just that those characteristics coincide nicely with the strengths of the AF.

See, that's odd to me.  I'll conced point a), given what I do and the role I take on teams.  But I've never known b) to be true on a project, and I'm generally opposed to extensive up-front requirements gathering anyway.  I have also never been much for Big Design Up Front, which run contrary to assertion c.  I'll agree that AF pushes you to do more design, but so far, I've been able to do just fine without extensive pre-design.