I am writing a dissertation on DMI design, but I come from a music background and have limited understanding of computing so I could use some help to clarify this point. Sorry if any of this sounds naive or uses inaccurate terminology (please tell me if it does!).

Can Max be considered an object-oriented visual programming environment or is it more appropriate to call it an application that mimics certain aspects of object-oriented programming (encapsulation, inheritance, modularity) because externals are classes built upon classes from a lower-level language? In other words, can an external be considered an object under the accepted definition of object-oriented programming?

The reason I ask this question is that I came across the following observations (all from Lazzarini, V. E. P., 2000. “The SndObj Sound Object Library.” Organised Sound, Volume 5 Issue 1. Cambridge: Cambridge Univesity Press.)

>The definition of object oriented programming is not very clear cut

>the concepts it involves are [THESE SEEM TO FIT MAX PERFECTLY]:

•    DATA ABSTRACTION: the principle by which new data types can be designed to behave similarly to built-in ones (Stroustrup 1995). They can include a full set of operations that can be used to manipulate that particular data type. An abstract data type can be considered as a kind of a black box which can model a real-life object. Some elements that compose the characteristics of an object can be hidden, in what is called encapsulation, allowing easier and safer handling of information and processes.

•    INHERITANCE allows abstract data types to pass on their characteristics (and operations) to other types which extend/refine the definition of that type. The inheritance concept allows for trees of objects.

•    REUSE SHARING AND MAINTENANCE. The design of a system using the object-oriented paradigm is based on decomposition and composition processes, recognition of likeness and behaviour of objects. Software based on object-oriented concepts is directed towards the reuse of algorithms and data structures.

>Four basic techniques can be defined for object-oriented design:

•    COMPOSITION is basically the reuse of existing classes as instance variables of new classes, composing a new object out of other objects it should contain [I relate this to bpatchers, sub-patchers in Max and poly~ in MSP].

•    REFINEMENT is the use of inheritance to create a new class which has specialized characteristics but is basically similar to its parent class [is this like counter 0 1 10 into * 10 to obtain a different increment?].

[I can't directly relate the next two to my experience with Max]

•    FACTORIZATION is the description of a class in terms of a hierarchy of aspects, using the inheritance mechanism. Instead of defining a class complete with all its concrete attributes, a hierarchy of class can be defined, which will factorise the characteristics and behaviour of the original class.

•    ABSTRACTION uses the idea of finding commonalities between concrete objects and defining an abstract class which embodies these common characteristics. This class will then serve as the base from which the others are created.

>Object-oriented programming packages can be grouped into two main categories, according to their use: toolkits and frameworks.

•    Toolkits are based on reuse by direct reference and composition. Users will basically employ the existing code by declaring instances of classes and using them to perform the wanted actions.

•    Frameworks are used, in general, by refinement and composition of existing classes. They are based on class hierarchies created by factorization and abstraction.

[under this definition max would be a toolkit then?]

I would be thrilled if anyone found any of this interesting enough to give me an opinion.

***************************
Short version:
Can Max be considered an object-oriented visual programming environment or is it more appropriate to call it an application that mimics certain aspects of object-oriented programming (encapsulation, inheritance, modularity) because externals are classes built upon classes from a lower-level language? In other words, can an external be considered an object under the accepted definition of object-oriented programming?
***************************

***************************
Long version:
The reason I ask this question is that I came across the following observations (all from Lazzarini, V. E. P., 2000. “The SndObj Sound Object Library.” Organised Sound, Volume 5 Issue 1. Cambridge: Cambridge Univesity Press.)

>the concepts it involves are [THESE SEEM TO FIT MAX PERFECTLY]:
•	DATA ABSTRACTION: the principle by which new data types can be designed to behave similarly to built-in ones (Stroustrup 1995). They can include a full set of operations that can be used to manipulate that particular data type. An abstract data type can be considered as a kind of a black box which can model a real-life object. Some elements that compose the characteristics of an object can be hidden, in what is called encapsulation, allowing easier and safer handling of information and processes.
•	INHERITANCE allows abstract data types to pass on their characteristics (and operations) to other types which extend/refine the definition of that type. The inheritance concept allows for trees of objects.
•	REUSE SHARING AND MAINTENANCE. The design of a system using the object-oriented paradigm is based on decomposition and composition processes, recognition of likeness and behaviour of objects. Software based on object-oriented concepts is directed towards the reuse of algorithms and data structures.

>Four basic techniques can be defined for object-oriented design:
•	COMPOSITION is basically the reuse of existing classes as instance variables of new classes, composing a new object out of other objects it should contain [I relate this to bpatchers, sub-patchers in Max and poly~ in MSP].
•	REFINEMENT is the use of inheritance to create a new class which has specialized characteristics but is basically similar to its parent class [is this like counter 0 1 10 into * 10 to obtain a different increment?].
[I can't directly relate the next two to my experience with Max]
•	FACTORIZATION is the description of a class in terms of a hierarchy of aspects, using the inheritance mechanism. Instead of defining a class complete with all its concrete attributes, a hierarchy of class can be defined, which will factorise the characteristics and behaviour of the original class.
•	ABSTRACTION uses the idea of finding commonalities between concrete objects and defining an abstract class which embodies these common characteristics. This class will then serve as the base from which the others are created.

>Object-oriented programming packages can be grouped into two main categories, according to their use: toolkits and frameworks.
•	Toolkits are based on reuse by direct reference and composition. Users will basically employ the existing code by declaring instances of classes and using them to perform the wanted actions.
•	Frameworks are used, in general, by refinement and composition of existing classes. They are based on class hierarchies created by factorization and abstraction.
[under this definition max would be a toolkit then?]

I  would be thrilled if anyone found any of this interesting enough to give me an opinion.
***************************

can-max-be-classed-as-an-object-oriented-visual-programming-environment

I know it's not really what you're looking for but here is a discussion about using OOP principles in max:

https://cycling74.com/forums/index.php?t=msg&th=34212&prevloaded=1&rid=7622&S=d53e0032872e2d3e133e7d047e215c7b&start=0

It contains links to some OO externals which I haven't tried but recommend you having a look at if you want to see what max is capable of in this department.

I think I understand now: Max is not OOP, but it can implement it; I would attempt to describe Max as a high-level visual programming environment?

The product-overview page states that Max is a "graphical programming environment":

https://cycling74.com/products/mmjoverview

The product-overview page states that Max is a "graphical programming environment":
https://cycling74.com/products/mmjoverview

Quote: Memory9 wrote on Sun, 04 January 2009 03:13

----------------------------------------------------

> I think I understand now: Max is not OOP,

However, before you can answer your question, you need to define OOP (actually, OOPL).

I work with the following definition: An object-oriented programming language (OOPL) is a language that uses _objects_ [primarily or exclusively].

Now we just need a working definition for 'object'. Ecco: An object is a data abstraction with state and behavior.

Nota bene: Nowhere, I repeat: *nowhere*, in this definition is there a requirement for implementing 'inheritance'. It is a fundamental misconception that OOPLs require inheritance. Inheritance is a nifty notion, but it is not a sine qua non.

Now to Max: Max has objects (built-ins, externs, abstractions), which in turn have state and behavior. Ergo, Max is an OOPL.

The Wikipedia article on OOP is worth reading. A definition quoted therein disagrees with mine, but the article adds "Attempts to find a consensus definition or theory behind objects have not proven very successful... and often diverge widely."

At least you will find widespread (but probably not universal) agreement on the notion that Max is a graphic (or visual) programming language.

Quote: Memory9 wrote on Sun, 04 January 2009 03:13
----------------------------------------------------
> I think I understand now: Max is not OOP,
----------------------------------------------------

The Wikipedia article on OOP  is worth reading. A definition quoted therein disagrees with mine, but the article adds "Attempts to find a consensus definition or theory behind objects have not proven very successful... and often diverge widely."

At least you will find widespread (but probably not universal) agreement on the notion that Max is a graphic (or visual) programming language.


I know that some people would argue that Max is not an OOPL because of the level of abstraction and complexity of both objects and graphical interface. I also gather that the definition of OOP is vague enough that Max may or may not be included under its umbrella depending on the interpretation of the commonly accepted basic features. So it would be my guess that it's more a cognitive question than one directly and uniquely dependent on the nature of the beast.

I personally don't have a strong opinion about this, but I am interested in what the user community of Max thinks of this issue.

visual *object-based* programming environment

http://en.wikipedia.org/wiki/Object-based

Quote: Memory9 wrote on Sun, 04 January 2009 11:44

> visual *object-based* programming environment

I think that is a good label for Max. Makes a lot of sense.

Quote: Memory9 wrote on Sun, 04 January 2009 11:44
----------------------------------------------------
> a friend just suggested the following:
>
> visual *object-based* programming environment
>
> see:
>
> http://en.wikipedia.org/wiki/Object-based
----------------------------------------------------

I think that is a good label for Max. Makes a lot of sense.


Quote: jeanfrancois.charles wrote on Tue, 06 January 2009 02:57

> Not clear what a "class" would be in Max.

I think the closest we're likely to get to a class declaration and implementation is "an abstraction saved to disk", though you could perhaps also think of an unsaved (editable) subpatcher as a singleton class instance that is also its own class definition.

Mattijs and I have discussed some ideas about implementing class inheritance that may appear in a future version of our oo-objects.

Quote: jeanfrancois.charles wrote on Tue, 06 January 2009 02:57
----------------------------------------------------
> Not clear what a "class" would be in Max.

Mattijs and I have discussed some ideas about implementing class inheritance that may appear in a future version of our oo-objects.


https://cycling74.com/twiki/bin/view/Share/MattijsKneppers

I'm curious how you would place these in the discussion of object oriented-ness of Max.

Quote: Joerg.Spix wrote on Wed, 07 January 2009 12:27

---------------------------------------------------- 

> I wouldn't have passed my practical CS examination if I have dropped 

> inheritance from the required concepts for an object oriented 

Paul Simon had something to say about this in "Kodachrome".

Sadly, I have experienced a number of teachers and professors who had a bee in their bonnet about some presumptive factoid or another, and if you wanted to pass the course you were well-advised to be able to regurgitate what they wanted to hear. That, alone, is neither proof nor disproof of an assertion.

If I stood by unquestioningly to everything I heard at uni, I'd be telling you that 64-bit processors were impossible and that the unit of entropy rate was [bit] rather than [bit/symbol]. And my all-time favorite: "Herr Castine, Informatik hat mit Musik _nichts_ zu tun!"

Quote: Joerg.Spix wrote on Wed, 07 January 2009 12:27
---------------------------------------------------- 
> I wouldn't have passed my practical CS examination if I have dropped 
> inheritance from the required concepts for an object oriented 
> language. 
----------------------------------------------------

If I stood by unquestioningly to everything I heard at uni, I'd be telling you that 64-bit processors were impossible and that the unit of entropy rate was [bit] rather than [bit/symbol]. And my all-time favorite: "Herr Castine, Informatik hat mit Musik _nichts_ zu tun!"


Jorg, I think you pretty much nailed things there.

I think I must mention that I noticed before that Stefan talks a lot about OO programming without having done any OO projects, now and then resulting in some blatantly incorrect statements (with all respect, Stefan).

The way I summarized this discussion on my user page:

Object Oriented (OO) design principles are very common in today's software development. They are essential to keep a complex program manageable. The Max paradigm of objects and connecting patch cords compares to a subset of these principles, including the basic concept of scope. But when patches get complex, 'wireless' connections (such as send/receive pairs) become indispensable. Unfortunately, Max currently doesn't support the notion of scope in its wireless connections, making it difficult to extend OO principles to large patches, where they are needed the most. The OO Objects for Max aim to overcome this limitation.

Jorg, I think you pretty much nailed things there. 

Object Oriented (OO) design principles are very common in today's software development. They are essential to keep a complex program manageable. The Max paradigm of objects and connecting patch cords compares to a subset of these principles, including the basic concept of scope. But when patches get complex, 'wireless' connections (such as send/receive pairs) become indispensable. Unfortunately, Max currently doesn't support the notion of scope in its wireless connections, making it difficult to extend OO principles to large patches, where they are needed the most. The OO Objects for Max aim to overcome this limitation.  

Quote: stefantiedje wrote on Tue, 13 January 2009 12:21

> Scope is a concept in procedural languages as well, and has 

> not so much to do with object orientation as far as I know.

What the oo-objects do uniquely address is the idea of access control, whereby a scope's (class's) internal member variables or methods can be public or private. Private members are not accessible from outside, and really help tighten up the interface to your class/patcher, so you can't stupidly break your own rules later - ie when you've forgotten that method X was intended for patcher-internal use only and its implementation might change radically, thus breaking anything external that accesses it directly. If it's private and can't be accessed externally, no problem.

Currently the pattr system includes no notion of private members, everything is public (like javascript). And there's no way to use a patcher as a simple organizing container without creating a new scope - ie pattrforward paths become long or you must introduce a path shortcut that pollutes the global namespace (pattrmarker). There's also a lack of any facility to pattrforward a message to some object and get a return message back to the calling pattrforward object (your pet wish, no?).

I do get the feeling that the pattr system was really intended to handle state save/recall/interpolate chores (improving on the old [preset] object), whereas its later use as a general-purpose messaging/scoping/namespace system exposes some shortcomings.

My opinion is that these differing requirements should be handled by separate object families.

Quote: stefantiedje wrote on Tue, 13 January 2009 12:21
----------------------------------------------------
> Scope is a concept in procedural languages as well, and has 
> not so much to do with object orientation as far as I know.

I do get the feeling that the pattr system was really intended to handle state save/recall/interpolate chores (improving on the old [preset] object), whereas its later use as a general-purpose messaging/scoping/namespace system exposes some shortcomings. 

Quote: stefantiedje wrote on Tue, 13 January 2009 00:21

> like that, I'll pull out some more stupid and false statements to keep

It's certainly a good thing to keep this discussion going and your contribution to that is much appreciated. ;)

> This missing notion of scope is a real limitation in the basic design of 

I wouldn't go so far as to declare that it is a shortcoming in the basic design of Max, I would rather say this is a feature that is not yet supported.

But we reached a bit of consensus there. We agree that we need scope in wireless connections, somehow, apart from whether it will be used in an attempt to reproduce OO or not. I have the feeling we might agree on access control too, as John mentioned. And how about the call-return system?

It could be true that we might actually gain something by taking these features for organizing big patches out of the context of OO. They could rather be -inspired by- OO. Thing is, a solution for organizing big patches in Max will have to be very consistent and can't just be a smart hack. That's why I think it is essential to hold it against the light of the techniques and insights of the so much larger common software development community. We have to fully understand those first before going off and flinging together something new from a limited perspective.

Quote: stefantiedje wrote on Tue, 13 January 2009 00:21
----------------------------------------------------
 We probably need some more discussions
> like that, I'll pull out some more stupid and false statements to keep
> it going... ;-)

> This missing notion of scope is a real limitation in the basic design of 
> Max. 

Can Max be classed as an object-oriented visual programming environment?