intelligence is a search for satisfaction

Gerry Quinn wrote:

> In article <2ntj38F4kpuqU1 RemoveThis @uni-berlin.de>,
> try_vanevery_at_mycompanyname RemoveThis @yahoo.com says...
>
>>Peter Ashford wrote:
>>
>>>I think it's just that I've very much settled into the OO way of
>>>viewing the world - solving a problem is creating a bunch of objects
>>>which
>>>simulate the problem domain with appropriate behaviours. I think that
>>>philosphically that view point appeals to me since I've always viewed
>>>understanding and theories as a modelling task (you build a model, try
>>>it out and refine it or replace it when it doesn't match obverved /
>>>desired behaviour)
>>
>>The problem is that world view doesn't work in a lot of instances. Lotsa
>>things aren't self-contained objects, nor do they have clean hierarchical
>>relationships. Lotsa things are relational and fuzzy, so you have to pick
>>object boundaries arbitrarily.
>
>
> But if the world isn't easily divided neatly into objects, it is even
> less easily divided neatly into algorithms.
>
> Personally I'm quite happy to have a class called "MapUtilities" that is
> just a bunch of functions for dealing with shortest paths etc. (I'm
> using a class where others might use a namespace.)
>
> - Gerry Quinn

Exactly. I find that in fact the world *does* devide neatly into
objects especially when you allow abstract units like "MapUtilities"
 >> Stay informed about: intelligence is a search for satisfaction 

Philippa Cowderoy wrote:

> On Wed, 11 Aug 2004, Peter Ashford wrote:
>
>
>>I think it's just that I've very much settled into the OO way of viewing
>>the world - solving a problem is creating a bunch of objects which
>>simulate the problem domain with appropriate behaviours. I think that
>>philosphically that view point appeals to me since I've always viewed
>>understanding and theories as a modelling task (you build a model, try
>>it out and refine it or replace it when it doesn't match obverved /
>>desired behaviour) FP seems a long way away from that - nothing
>>neccessarily wrong with FP, more to do with how I think about code.
>>
>
>
> The approach I take in FP isn't all that different. In a (classed) OO
> language, classes form a little language with its own semantics. Monads
> also do something similar - I've been trying to figure out the exact
> relationship, in some ways monads seem to generalise classes. I suspect
> (but may be wrong) that objects are effectively the closure of a monadic
> computation.
>
> The main difference this seems to make is that you're encouraged to
> rewrite the rules that objects and the like sit on top of - the List monad
> being a great example thereof.
>

I'm clearly going to have to just try this stuff. I read what you're
saying and it may as well be written in Swahili ) I'm just a simple
programmer - I have no idea what Monads and closures are. And you know,
I think it's that element of FP - the language used to describe it and
it's benifits - that keeps dumasses like me from being drawn to giving
FP a go )

That said, I will give it a go. I clearly need to broaden my horizons.
 >> Stay informed about: intelligence is a search for satisfaction 

Peter Ashford wrote:
>
> I'm clearly going to have to just try this stuff. I read what you're
> saying and it may as well be written in Swahili ) I'm just a simple
> programmer - I have no idea what Monads and closures are. And you
> know,
> I think it's that element of FP - the language used to describe it and
> it's benifits - that keeps dumasses like me from being drawn to giving
> FP a go )

Right, it's all couched in a bunch of academic gobbledygook. All while
retaining the stench of dubious utility. Thanks for reminding me that if I
do succeed at using OCaml for a commercial game project, I'll have a fine
career in writing digestible articles for Gamasutra.

--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA

"Trollhunter" - (n.) A person who habitually accuses
people of being Trolls.
 >> Stay informed about: intelligence is a search for satisfaction 

Philippa Cowderoy wrote:
>
>>I think it's just that I've very much settled into the OO way of viewing
>>the world - solving a problem is creating a bunch of objects which
>>simulate the problem domain with appropriate behaviours. I think that
>>philosphically that view point appeals to me since I've always viewed
>>understanding and theories as a modelling task (you build a model, try
>>it out and refine it or replace it when it doesn't match obverved /
>>desired behaviour) FP seems a long way away from that - nothing
>>neccessarily wrong with FP, more to do with how I think about code.
>
> The approach I take in FP isn't all that different. In a (classed) OO
> language, classes form a little language with its own semantics. Monads
> also do something similar - I've been trying to figure out the exact
> relationship, in some ways monads seem to generalise classes. I suspect
> (but may be wrong) that objects are effectively the closure of a monadic
> computation.

Have to disagree here. You don't have to go all the way to monads to
find some analogy for objects in FP. Monads are powerful but pretty
advanced abstractions and I do not see a close relation to the everyday
use of objects.

Above all, objects (or rather, classes) are good old ADTs and ADTs are
plain simple in FPLs. I design in terms of ADTs all the time. Mind you,
objects give you a bit more than basic ADTs, but often this add-on is
not needed, or available by different means. In any case, the way of
thinking about them is not so much different.

Cheers,

- Andreas

--
Andreas Rossberg, rossberg.DeleteThis@ps.uni-sb.de

Let's get rid of those possible thingies! -- TB
 >> Stay informed about: intelligence is a search for satisfaction 

In article <egekmclw3u.fsf.TakeThisOut@ii.uib.no>, ketil.TakeThisOut@ii.uib.no says...
> Peter Ashford <me.TakeThisOut@here.there.com> writes:
> > Gerry Quinn wrote:
>
> >> Personally I'm quite happy to have a class called "MapUtilities"
> >> that is just a bunch of functions for dealing with shortest paths
> >> etc. (I'm using a class where others might use a namespace.)
>
> > Exactly. I find that in fact the world *does* devide neatly into
> > objects especially when you allow abstract units like "MapUtilities"
>
> Uh...an object (as in "object oriented") isn't just a collection of
> functions, you know. This sounds like a case of having a hammer and
> viewing everything else as nails.

It isn't necessarily just a collection of functions. Maybe my
'MapUtilities' class would have a workspace for doing certain
calculations based on a map that is passed to it. Or a set of
parameters for choosing the best pathfinding heuristic. Why would it be
any different in principle from (say) a complex number class? Objects
in OO aren't confined to modelling physical objects.

Of course it may have just functions that deal with data that -
currently at least - is passed to them. I don't see why that should be
the deciding factor in whether it is a class or not.

We have the benefit of function encapsulation, and we have the option of
adding data at a future time, should it be appropriate.

- Gerry Quinn
 >> Stay informed about: intelligence is a search for satisfaction 

Gerry Quinn wrote:
>
> But if the world isn't easily divided neatly into objects, it is even
> less easily divided neatly into algorithms.

I don't know how that follows.

It is important to notice that there are different axes along which you
can decompose problems. Depending on the domain it highly varies which
one is more suitable. Objects support one axis - probably the most
important one - very well, but typical OOPLs force you into using that
axis exclusively (and probably keep you from being aware of others).
Leads to highly distorted designs whereever that particular axis is not
the right choice.

Cheers,

- Andreas

--
Andreas Rossberg, rossberg RemoveThis @ps.uni-sb.de

Let's get rid of those possible thingies! -- TB
 >> Stay informed about: intelligence is a search for satisfaction 

In article <cffef9$7c8vg$4@hades.rz.uni-saarland.de>, rossberg RemoveThis @ps.uni-
sb.de says...
> Gerry Quinn wrote:
> >
> > But if the world isn't easily divided neatly into objects, it is even
> > less easily divided neatly into algorithms.
>
> I don't know how that follows.

It doesn't 'follow' - it is an observation, not a syllogism.

> It is important to notice that there are different axes along which you
> can decompose problems. Depending on the domain it highly varies which
> one is more suitable. Objects support one axis - probably the most
> important one - very well, but typical OOPLs force you into using that
> axis exclusively (and probably keep you from being aware of others).
> Leads to highly distorted designs whereever that particular axis is not
> the right choice.

I don't see why OO languages force one onto any tracks. That seems more
a philosophical argument than anything else. Can you give an example of
the sort of problem you mean? [The problem itself, not a design to
solve the problem according to some non-OO paradigm?}

- Gerry Quinn
 >> Stay informed about: intelligence is a search for satisfaction 

Brandon J. Van Every wrote:
>
> The difference is that banishing GOTO actually happened in industrial
> practice because it proved rather useful rather quickly. No such claim can
> be made for FP purism. In fact, looking at the historical evidence, we
> would say that it has been definitively proven that modifying state is too
> compelling to give up.

Yes, I cannot really argue with that (and as I said, I do not strive for
purism). Just let me note that drugs are very compelling too - and take
some real mental effort to step away from after long-term use...

>>That's mainly a matter of getting used to. In any case, you code
>>explicit recursion much less frequently in functional languages than
>>loops in conventional ones since you normally build higher-order
>>abstractions for that.
>
> 'Normally' for 'normal' algorithms? Why does this reek of domain-specific
> bias?

'Normally' for 'normal' data structures. When you implement a data
structure, you implement the canonical iteration functions (map, fold,
iter) over them. Many (not all) algorithms can then be straightforwardly
expressed in terms of these functions with no need for explicit looping.

>>That's a strawman. FPLs are tuned for building abstractions. E.g. in
>>SML just define
>>
>> infix +=
>> fun (n += i) = (n := !n+i)
>
> Why should we desire this grunge code for such a simple operation? Do you
> believe that you'll be able to prune the state modification at some point,
> if only you add all this verbiage? I'm doubting it. Modifying state is a
> software architectural choice. If it were easy to transform programs that
> modify state into ones that don't, I think we'd just have those language
> technologies and FP adherants wouldn't be complaining about how everyone
> shouldn't modify state.

You missed the point, this was a relpy to cr8910's paragraph claiming
lack of convenient syntax for mutable state in impure FPLs. The example
uses mutable state. It was intended to demonstrate that you actually
have more convenience than just some random built-in operators: you can
create them yourself and put them into a library.

> I can't say that mutable state has ever bitten me in anything I've done in
> software.

Then you are either a genius, or indredibly lucky, or have never
programmed anything concurrent, or anything that is supposed to be
usable as a library component. Or you just didn't realise that the bites
you took in fact were rooted in the presence of state.

> I think the bogdowns come from overoptimizing, core architectural
> decisions I can't change, tedious documentation, and libraries that don't
> actually work.

These are very real problems as well, but may sometimes be related to
the above.

Cheers,

- Andreas

--
Andreas Rossberg, rossberg RemoveThis @ps.uni-sb.de

Let's get rid of those possible thingies! -- TB
 >> Stay informed about: intelligence is a search for satisfaction 

"Andreas Rossberg" <rossberg RemoveThis @ps.uni-sb.de> wrote in message
news:cffkas$7c8vg$5@hades.rz.uni-saarland.de...
> Brandon J. Van Every wrote:
>>
>> The difference is that banishing GOTO actually happened in industrial
>> practice because it proved rather useful rather quickly. No such claim
>> can
>> be made for FP purism. In fact, looking at the historical evidence, we
>> would say that it has been definitively proven that modifying state is
>> too
>> compelling to give up.
>
> Yes, I cannot really argue with that (and as I said, I do not strive for
> purism). Just let me note that drugs are very compelling too - and take
> some real mental effort to step away from after long-term use...
>
maybe...

>>>That's mainly a matter of getting used to. In any case, you code
>>>explicit recursion much less frequently in functional languages than
>>>loops in conventional ones since you normally build higher-order
>>>abstractions for that.
>>
>> 'Normally' for 'normal' algorithms? Why does this reek of
>> domain-specific
>> bias?
>
> 'Normally' for 'normal' data structures. When you implement a data
> structure, you implement the canonical iteration functions (map, fold,
> iter) over them. Many (not all) algorithms can then be straightforwardly
> expressed in terms of these functions with no need for explicit looping.
>
usually in languages like c, one writes functions for doing one of these
kind of operations on one of these types.

yes, in this case a generalized map function would make sense, but this is
still not a good reason to make loops awkward, as the generic map function
may not necissarily have the semantics you want.

in many cases, the map function will not be much more convinient than just
writing a loop, or may actually be more awkward..

now, what if your algo has no data involved? then map is not a good fit,
loops are still better.

thus I argue that having both is a decent solution.

>>>That's a strawman. FPLs are tuned for building abstractions. E.g. in
>>>SML just define
>>>
>>> infix +=
>>> fun (n += i) = (n := !n+i)
>>
>> Why should we desire this grunge code for such a simple operation? Do
>> you
>> believe that you'll be able to prune the state modification at some
>> point,
>> if only you add all this verbiage? I'm doubting it. Modifying state is
>> a
>> software architectural choice. If it were easy to transform programs
>> that
>> modify state into ones that don't, I think we'd just have those language
>> technologies and FP adherants wouldn't be complaining about how everyone
>> shouldn't modify state.
>
> You missed the point, this was a relpy to cr8910's paragraph claiming lack
> of convenient syntax for mutable state in impure FPLs. The example uses
> mutable state. It was intended to demonstrate that you actually have more
> convenience than just some random built-in operators: you can create them
> yourself and put them into a library.
>
and I raise the complaint that you have to do this at all.

>> I can't say that mutable state has ever bitten me in anything I've done
>> in
>> software.
>
> Then you are either a genius, or indredibly lucky, or have never
> programmed anything concurrent, or anything that is supposed to be usable
> as a library component. Or you just didn't realise that the bites you took
> in fact were rooted in the presence of state.
>
yes, threading is one case where state can be annoying.
yes, mutexes can be a hassle as well.

I will argue in this case, though, that the problem is not so much that
there is state, but that you have multiple threads operating on the same
data at the same time.

a possibility is avoidance of modifying data unless necessary, but still
being fine with modifying local variables and such (since these are
invisible to other threads or functions anyways).

from that viewpoint I allready use largely non-destructive approaches,
since, yes, destructive operations on data can be problematic. by that
stance, I typically avoid general use of globals as well.

however, if your data is not shared, then there is no problem.

I don't view this as a reason to ban assignment in general, but more to have
"better" concurrency mechanisms...

>> I think the bogdowns come from overoptimizing, core architectural
>> decisions I can't change, tedious documentation, and libraries that don't
>> actually work.
>
> These are very real problems as well, but may sometimes be related to the
> above.
>
in my experience: not really.

in my experience it is usually because some peice of code/data is a little
too rigid, or because of various sloppy practices, eg: manual creation of
data (directly allocating it vs. calling a function), or direct reliance on
some data's internal structure (vs. calling a function to do something with
it).
another problem is generally trying to approach things too directly, vs.
relying on some more general approach. often the direct approach is a lot
less flexible and more likely to break eventually.

or something...
 >> Stay informed about: intelligence is a search for satisfaction 

Gerry Quinn wrote:
>
>>It is important to notice that there are different axes along which you
>>can decompose problems. Depending on the domain it highly varies which
>>one is more suitable. Objects support one axis - probably the most
>>important one - very well, but typical OOPLs force you into using that
>>axis exclusively (and probably keep you from being aware of others).
>>Leads to highly distorted designs whereever that particular axis is not
>>the right choice.
>
> I don't see why OO languages force one onto any tracks. That seems more
> a philosophical argument than anything else. Can you give an example of
> the sort of problem you mean? [The problem itself, not a design to
> solve the problem according to some non-OO paradigm?}

Well, the standard example (and I have repeatedly used that in similar
discussions) are tree-like structures (e.g. term structures, ASTs,
descriptions of geometric objects) that you have to perform a number of
non-trivial algorithms or transformations on. The OO approach is just
plain masochism for this.

- Andreas

--
Andreas Rossberg, rossberg RemoveThis @ps.uni-sb.de

Let's get rid of those possible thingies! -- TB
 >> Stay informed about: intelligence is a search for satisfaction 

>
>> It is important to notice that there are different axes along which
>> you can decompose problems. Depending on the domain it highly
>> varies which one is more suitable. Objects support one axis -
>> probably the most important one - very well, but typical OOPLs
>> force you into using that axis exclusively (and probably keep you
>> from being aware of others). Leads to highly distorted designs
>> whereever that particular axis is not the right choice.
> I don't see why OO languages force one onto any tracks. That seems
> more a philosophical argument than anything else. Can you give an
> example of the sort of problem you mean? [The problem itself, not a
> design to solve the problem according to some non-OO paradigm?}

Andreas replied:

> Well, the standard example (and I have repeatedly used that in
> similar discussions) are tree-like structures (e.g. term structures,
> ASTs, descriptions of geometric objects) that you have to perform a
> number of non-trivial algorithms or transformations on. The OO
> approach is just plain masochism for this.

I don't think OO-per se is at fault here, where OO is defined in terms
of having inheritance and polymorphism, but rather a slavish
commitment to only class hierarchies as the only parameterization
method. There is very little question that the traditional design of
ASTs and similar tree-structures by using only the class hierarchy to
introduce variants is painful and leads to complex and roccoco
hierarchies that may have parallel clones to implement the "visitor"
pattern. And, yes, this is unfortunately presented as *THE* OO
solution to the problem.

However, I have been a compiler writer for about 25 years, and an OO
practitioner for about 15, and that does not strike me as the natural
OO solution to the problem. I still LOVE inheritance and find it
useful even in the AST problem context. However, it should not be the
only (or even necessarily the primary) method of customizing behavior
of different tree elements (nodes if you will).

Take expression [operator]s, there are communatitive expressions, and
associative ones, and ones that are idempotent, and ones with
identities. These are all distinct properties that come in wide
varieties of combinations. Inheritance is the *wrong* solution for
expressing those variations. Independent properties that can be
associated with each expression operator are the correct solution to
those variations. Now, inheritance may be useful in building up some
combinations that are hierarchical (e.g. some propertied may depend on
others and those may form an inheritance tree), but that's a distinct
issue.

So, as an experienced OO compiler writer, I find it unfortunate that
doing AST variant trees as a class hierarchy has gotten labelled as
the OO solution to the problem. It's not what I practice (well, okay
sometimes for small cases it is an easy solution) and it's not what my
"OO" compiler building tool (Yacc++) supports--although it doesn't
discourage it, which maybe it should. There are places for class
hierarchies, but many of them are much smaller and less entangled than
a naive understanding of OO would lead one to believe.

Hope this helps,
-Chris

*****************************************************************************
Chris Clark Internet : compres DeleteThis @world.std.com
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
23 Bailey Rd voice : (508) 435-5016
Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours)
------------------------------------------------------------------------------
 >> Stay informed about: intelligence is a search for satisfaction 

"cr88192" <cr88192 RemoveThis @hotmail.com> writes:

> usually in languages like c, one writes functions for doing one of these
> kind of operations on one of these types.

....with all the opportunity for error that entails.

> in many cases, the map function will not be much more convinient than just
> writing a loop, or may actually be more awkward..

Here's a random fragment using "map" from my program:

region_start = minimum (map start g1)

Compare to what I presume is fairly idiomatic C:

int region_start(int len, G * g1){
m = 0;
for(i=0; i<len; ++i)
m = max(m,start(g1[i]));
return m;
}

Convenience or not, I prefer the 'map' version.

> now, what if your algo has no data involved? then map is not a good fit,
> loops are still better.

No data? Could you give an example?

> thus I argue that having both is a decent solution.

Sure. And these kinds of higher order functions are being picked up
by the mainstream (read: Python et al). It still doesn't work quite
as nicely as in a "real" FP language, where you have a powerful type
system to help you out (think curried functions given partial
arguments).

> and I raise the complaint that you have to do this at all.

You're not serious. You claim the lack of an += operator is a big
problem, but you're not willing to spend two short lines of code in
your program to get it?

-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
 >> Stay informed about: intelligence is a search for satisfaction 

"Ketil Malde" <ketil RemoveThis @ii.uib.no> wrote in message
news:egy8kkikjd.fsf@ii.uib.no...
> "cr88192" <cr88192 RemoveThis @hotmail.com> writes:
>
>> usually in languages like c, one writes functions for doing one of these
>> kind of operations on one of these types.
>
> ...with all the opportunity for error that entails.
>
yes, maybe...

>> in many cases, the map function will not be much more convinient than
>> just
>> writing a loop, or may actually be more awkward..
>
> Here's a random fragment using "map" from my program:
>
> region_start = minimum (map start g1)
>
> Compare to what I presume is fairly idiomatic C:
>
> int region_start(int len, G * g1){
> m = 0;
> for(i=0; i<len; ++i)
> m = max(m,start(g1[i]));
> return m;
> }
>
yes, one can do it this way (though I will argue that there are different
ways stylistically to do this).

> Convenience or not, I prefer the 'map' version.
>
ok.

>> now, what if your algo has no data involved? then map is not a good fit,
>> loops are still better.
>
> No data? Could you give an example?
>
well, depdends on what you are doing.
eg: rendering code often does not produce any data as a result.
often file writing code doesn't produce and results either.

hmm...

>> thus I argue that having both is a decent solution.
>
> Sure. And these kinds of higher order functions are being picked up
> by the mainstream (read: Python et al). It still doesn't work quite
> as nicely as in a "real" FP language, where you have a powerful type
> system to help you out (think curried functions given partial
> arguments).
>
well, depends on whether you want more of a functional or imperative style.
in general, I opt for the imperative style.

>> and I raise the complaint that you have to do this at all.
>
> You're not serious. You claim the lack of an += operator is a big
> problem, but you're not willing to spend two short lines of code in
> your program to get it?
>
yes, actually...
 >> Stay informed about: intelligence is a search for satisfaction