[microsound] In the Defense of Max (was: development environment)

[John Nowak <john@xxxxxxxxxxxxx>]

On Jan 27, 2005, at 11:51 AM, vze26m98 wrote:

> I think there's some debate as to whether Max/MSP/Pure Data qualifies 
> as
> a data-flow language:
>
> "The term "data-flow" is not a good description of Max except for the
> intuition. Data-flow computers and languages are based on the idea that
> (parallel) computations can be synchronized by data. For example, an
> addition operator would wait for its two operands before adding them.
> Note that this is not at all how Max works.

This is not how Max objects work by default. However, you can certainly 
implement abstractions that work this way. I have a "syncro" 
abstraction which works similar to the one in Prograph in that it waits 
until both inlets have data available, and then forwards the data 
ahead. Regardless, I'm not aware that this is critical for classifying 
something as a dataflow language.

> I will not argue that Max should work this way,

I'm quite glad it doesn't actually.

> but since it doesn't, one should not call it a
> data-flow language. I think "patch language" or "visual programming
> language" are better terms.

Unfortunately, the former will make no sense to someone who isn't 
familiar with Pd/Max, and the latter is too generalized to impart any 
real meaning.

> For the rest try:
> <http://cf.hum.uva.nl/mmm/papers/dh-93-b.txt>

I've read this before, and I feel compelled to write a "The Mins of the 
Mins of Max" paper. Many of the arguments given are just utter 
nonsense.

Here we go, briefly:

- - -

> The term "data-flow" is not a good description of Max except
for the intuition.

This is of course debatable, or at least, this list doesn't agree upon 
that.

>  I would add that, despite
statements in the manuals and documentation, Max is not an
object-oriented language.

I assume things were different before, but now Max is only referred to 
(correctly) as an object-based language. All of the nonsense attached 
to the definition OO languages is unfortunate in my opinion. I'd prefer 
a term that's less misleading, but oh well. That said, it is a good 
thing that Max is not a true OO language for a number of reasons I 
don't want to get into here.

> To me, Max seems to be an imperative language based on timed
streams of values flowing through a static network of objects.

Again, perhaps this came about after this was written, but Max does not 
require you to have a static network. Building networks that reconnect 
themselves, replace parts of themselves, etc, is entirely possible.

> Max is claimed to be a music system or musical language, but
the only idea of music that Max has is in the (unnecessarily)
low-level form of MIDI messages. It does not provide primitives
(e.g., notes, chords or ornaments), or control structures
(e.g., repeat or slow down)

Thank god.

> Computation time becomes involved in the problem of timing;
if one datum needs a bit more computation than another, it will
arrive later at the point at which they are combined. This can
break the algorithm, forcing the user to rely on the work-
arounds provided (a special re-synchronizing module).

If you program in such a way that two parts of a program are racing 
each other, this is unavoidable. And even then, output from the two 
competing processes can be easily synced later.

> "Even if an algorithm works well, a tiny change ... may break
it."

Not only do I not understand where this claim comes from, but hell, Max 
is much harder to mess up than most any textual programming language. 
Miss some whitespace in Python, and it all goes to hell. Forget a 
semicolon in C, and you're not going anywhere. Etc.

> in the Opcode version of Max, there is a potentially
confusing and dangerous mechanism that acts automatically on
ambiguities in order; graphic positioning of connections
between objects on the screen will determine the message-
passing order between these objects.

I much prefer this method to that of Pd. At least in Max, I can look 
and see exactly what will happen. In Pd, which resolves ambiguity via 
order of object creation, I haven't the slightest clue what will happen 
when looking at it. The right-to-left nature of Max often makes code 
easier to read, saves time, and if treated with the slightest bit of 
care, never causes any issues.

> But one has to keep
in mind that not all abstractions can be expressed well
graphically. Nested loops, variables, references, match
patterns, computation history, and recursion are among the
constructs with which the conversational mode, in the form of a
formal language, can deal much better.

Well of course a dataflow language (or whatever you want to call it) 
will not let you directly translate code written for a traditional 
control flow language. That said, it is still very easy to implement 
things like recursion in Max, and the segmented patch cord that loops 
back make it very easy to spot. Computations can be stored if desired. 
Even global variables are possible to emulate in a naturally reusable 
way. I have the abstractions to prove it. You simply send a message via 
a send object to a receive which talks to the variable. The message you 
send contains a pointer (yes, I'm using the term loosely) back to a 
receive where the message was sent from. The receive at the variable 
holding object (be it an int, float, whatever) sets a forward to send 
to the receive that is being pointed to, and then sends the data to the 
forward object. You can abstract it as such that you just store your 
data in a "variable" object, and then access it whenever you want via a 
"getvariable" object. Of course to change the value in the variable, 
you'd just send data to a send object with the variable name as an 
argument. The point is though, I've only had to do this once in my 
history of Max programming, and this was for a very unique situation. 
If you find yourself wanting to use variables all the time in Max, 
you're thinking in a control flow way, not a dataflow way.

> Max supports
further extensibility in the form of procedures written in the
C language, instead of the ability to abstract from the
primitives in the language itself.

This is just false -- perhaps it was different 12 years ago.

> Furthermore, because Max is advertised as a
language with an object-oriented flavor, one would expect a
versatile system of data types (classes) and polymorphic
modules (objects), which adapt their processing to the type of
incoming data and their own identity.

Max uses a system similar to prototypes, which has been proved to be 
approximately functionally equivalent to classes, except that with 
prototypes you don't have to waste your time making classes for one-off 
objects, etc. Many fully-featured textual OO languages (Self, 
Javascript, Rebol, etc) let you work just fine without any classes.
http://c2.com/cgi/wiki?PrototypeBasedProgramming

> Instead the neat old-fashioned block diagrams [e.g., of Music
V-style instruments] that we used to see in articles (e.g., in
the older ICMC proceedings), now awkward looking Max patches
are often presented-no different symbols for modules, no
different line types for different signal types, and a mess of
wires. Even if the latter can be cleaned up, users often have
to spend more time cleaning up the patch than creating it
because the graphical editor does not support state-of-the-art
consistency maintenance when moving modules, multiple moves
etc.

This is simply not true in the case of a decent Max programmer who 
understands the importance of encapsulation. While Max could use some 
things to speed graphical building (a clean up command a la Pd, a key 
command for new objects), generally the graphical nature encourages far 
more productivity than it wastes time.

> On the
negative side, as many people have mentioned, it doesn't scale
well; large programs tend to become heaps of spaghetti unless
one spends inordinate amounts of time laying them out.

Again, if you encapsulate properly, you should, generally speaking, 
never have more than 20 or so objects visible in any one patch. I 
rarely, if ever do. Hardly a mess.

> I would like to
be able to click on a "code" object and have a window with
editable C open up.

Such a thing is now possible via the js and maxlisp objects.

- - -

Alright, I realize I just provided a rebuttal for something that's 12 
year old, and things have changed since then, but if people are going 
to continue citing it then I suppose it won't hurt if I procrastinate 
my Max building and write this instead. Okay, back to work.

- John


---------------------------------------------------------------------
To unsubscribe, e-mail: microsound-unsubscribe@xxxxxxxxxxxxx
For additional commands, e-mail: microsound-help@xxxxxxxxxxxxx
website: http://www.microsound.org