Re: [Haskell-cafe] I miss OO

Nice. It would be fantastic to have a little practical real-world challenge (like building a simple music system, or a simple multi-channel sound mixer), and work this out in an imperative language, an object-oriented language, a functional language, and maybe other languages too, like logic languages or constraint languages (does the latter exist?) When OO is about constructing a "machine" and talking about objects, and FP is about making little algebraic languages, what would C or Pascal be like? In these languages, you don't think about objects, but you don't think about an algebra either? It's been a very long time since I worked with these languages, but as far as I recall, I started thinking about data structures and procedures operating on these data structures, which sounds a look like making ADTs and functions/operations on these... So this sounds odd, because it would mean that C and Pascal are in a sense closer to FP than OO is? Also Luke Palmer talked a couple of times about "co-algebraic" approaches, but not being a computer scientist, I never really understood what that meant ("just reverse all the arrows"?) On Thu, Nov 26, 2009 at 3:49 PM, Gregg Reynolds wrote:

On Thu, Nov 26, 2009 at 6:44 AM, Stephen Tetley wrote:

...

2009/11/26 Gregg Reynolds :

...

Modeling musical stuff could provide an excellent illustration of the difference between OO and the Haskell way; it's the difference between metaphysical engineering and constructive mathematics.

Hmm, Stephen Travis Pope's SmOKe - a design that has been the basis of various state-of-the-art Smalltalk music systems - seems pretty concrete to me rather than metaphysical.

http://heaveneverywhere.com/stp/PostScript/icmc.94.mode.pdf

Looks interesting, but what I was trying to get at - ``metaphysical engineering'' just popped into my head and sounded kinda cool so I went with it - is that these are two radically different ways of thinking about what we're doing when we write programs.

For example, Pope talks about music in terms of properties, but then says "[t]hese properties may be music-specific _objects_ (such as pitches or spatial positions)..." (emphasis added).  This is standard OO-speak; there's nothing wrong with it, the point is just that the domain of interest is viewed as a collection of ``objects'' and their behaviors, where ``object'' is the word we use for lack of a better term to refer to things that exist - hence metaphysics.  Are there _really_ any objects involved, especially where properties are concerned?  Not for me, though others may differ.  In any case, the overall picture is that programs are combinations of such objects, so the program is viewed as the description of a kind of machine - hence engineering.  In order to describe music, the programmer describes a machine.

By contrast, a ``purely functional'' approach (I prefer ``algebraic'' as more accurate or at least more revealing) might construe such properties in terms of  types and operations on values of the types, which capture the notion of property directly without implicating objects in any way.  A music library would be viewed in terms of a language (algebra), with customized names for domain-specific types and operations, that the programmer can use to describe music instead of describing a machine that produces music.  Which makes the programmer a litterateur rather than a constructor of machines, among other things.

Cheers,

Gregg _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe