[Gridflow-dev] ping (fwd)

[Mathieu Bouchard]

On Wed, 15 Sep 2004, Tom Schouten wrote:
> On Wed, Sep 15, 2004 at 01:03:58AM -0400, Mathieu Bouchard wrote:
> > On Tue, 14 Sep 2004, Tom Schouten wrote:
> i'm still quite puzzled by the syntax actually.

My ascii art skills prolly aren't good enough.

You may look at this patch (frac.pd), which demonstrates [@remap_image] in
a nontrivial case.

> > Maybe the examples weren't complex enough for you?
> more like the other way around.. i'm trying to find the real added
> value translated to how i would do things.

How would you do frac.pd using PDP ?

> his position was that the audio SHOULD have a separate thread.
> i think not.

Well, the audio DSP isn't even following the rules of message-passing at
all, so I don't see what would be lost using a thread for that. IIRC, in
MAX (at least in MacOS classic) the DSP doesn't use a thread nor an event
loop, it uses something on the level of IRQ's and UNIX signals. That does
not have the ability that a thread has to stop and resume while passing
control to another thread, but it still has preemption, which means that
DSP can compute while anything is happening in the message-system, which
means you have to do all kinds of threadlike locking and mutexes... and
AFAIK they have less dropouts like that.

> so, regarding orthogonality as something that can
> be measured by the interior product of 2 vectors:
> > Besides there's a critical difference
> > between orthogonal (90 deg apart) and opposed (180 deg apart) but without
> > even an idea of the structure of space and of the angle measurement
> > process, it's difficult to say "orthogonal".
> yeah, i was talking about electrons..

Oh, but contradistinctively to the astronomical scale, which is locally
Euclidean although not globally so, when you go towards the atomic scale
the space becomes gradually nonEuclidean as the spacetime fabric
3-manifold strays away from being a diffeomorphism due to discretisation
of the potential of Gaussian force fields near the Planck energy scale.
Therefore if you even dare suggest that at the electron level any kind of
Hilbertian space may be useful, then you are full of bull. :-}

> yes. threads are a really evil concept. as is call/cc :)

Preemptive threading can be implemented by combining CALL/CC with a UNIX
Signal type of mechanism. This makes all three concepts not only evil, but
also an evil trinity of sorts.

> > > it's hard to think about the same thing from 2 so different view
> > > points (pure OO vs forth)
> > After 12 years of experience in OO programming, I think my next question
> > ought to be, what is pure OO ?
> i don't have a clue. but it's about things with state that you can talk to
> in different ways.

Ok, that one sounds right. I was fearing that you would be assuming any
feature specific to C++, Smalltalk, Self, Lisp... because that's the most
common mistake. All four languages above have very different object models
and I think your sentence pretty well describes the intersection of the
four.

> there's no revolution here, but forth facilitates the last approach with
> local context determined by stacks. it makes you think different,
> than normal OO syntax where you always (or most of the time) have
> and explicit object and message.

Bound methods are builtin in both C++ and Ruby, though I haven't found a
use for them in Ruby, and I haven't had the patience to figure them out in
C++...

> stretching the concept, forth is definitely OO in its most basic form,
> but more in closure style:

Closure style is not OO. It's afaik a step between classic structured
programming and OO.

There's a Perl5 man page that describes how to make an object system using
only closures, and it gets encapsulation right, but it stops before
implementing inheritance, and I guess I know why. It's because inheritance
is a pain in the ass to implement with ordinary closures. Especially stuff
like the 'super' keyword.

> the more you play with different things, the more everything looks the
> same and a lot can be identified as religion really.

Yeah that's true to a great extent, but language constructs are still
*not* created equal... I mean closures and OO still aren't fully
equivalent.

________________________________________________________________
Mathieu Bouchard                       http://artengine.ca/matju