M4L Tutorial: Beginning Max 1 1/2 - Message Ordering

Actually, when I teach Max one of my first pieces of instruction is never to rely on message ordering: always use [trigger] objects to enforce firing order so that a patcher is impervious to rearrangement of its contents.

Yeah... I agree. But, If people do not understand this it could hurt them in the end. I agree with triggering though.

Does anyone knows what were the reasons (usability, historical etc) to choose the rtl-btt message ordering behavior in Max/MSP?

what is ergonomically right for people used to english and similar languages, is reading left-to-right top-to-bottom.

someone should ask to Miller Puckette, AFAIK also when he went open source with PureData, the order hasn't changed.

Other data-flow languages/environments like LabView, Quartz Composer, vvvv execute the graph differently.

I don't know about LabView or Quartz but this is one of the 'bullets' in "differences between PD and MAX":
- Pd does not conform to the right-to-left ordering of output messages. Instead, outputs will happen in the order they were created. It is expected that users will make use of the trigger object to disambiguate message ordering.

Independently from what the differences between Max and PD are, like Cassiel said one of the first things to remember is:
"never rely on message ordering".
Sure it's really important to know about message ordering anyway, because together with triggers and object behaviors related to the receiving inlets, that's what is needed to read the flow in the patch.

Apart from data-flow, one of the things that it's really never considered in documentation and lessons about Max is how the data-flow programming it's related and/or different to other forms of programming. I have used Max for years but I have to say that I've never managed to do something big with it. Sure you can encapsulate things in patches but this seems like using simple subroutines. I never really grasped how to transport/write a semi-complex object oriented architecture I had in mind inside Max.
It's insane to start making patches and just incapsulate bits and pieces of them when they get too big or when they are used too many times. There must be, like for Object oriented programming, some kind of approach to have an idea of how the architecture will be before starting to deal with bricks and concrete.
I guess that to do something meaningful in M4L devices someone should start talking about the design process.

I definitely think that a Architecture and design tutorial would be great. The problem is that there is no, one way, to work within Max. I like to plan out the architecture of an application. Even when i am programming apps adhoc, I think about what can be encapsulated and used in future programs. I definitely believe in using a lot of sub-patchers in order to create a Max application. I try to modularize everything and encapsulate areas in logical ways. To me, everything is about being able to analyze the flow easily. In large programs I try and make the main patch like a flow chart that just shows the sub-patchers within it.

Tips and tricks in creating legible and organized programs, might be a good tutorial.

Mike