f



intelligence is a search for satisfaction

42.  :-)

And yes, it's cross-posted for a reason.

I've been doing a lot of voter registration lately... which is boring, and
low paying, which causes me to goof off once I'm done working.  So, quite a
lot of Galactic Civilizations and not a lot of OCaml progress.  It is not a
loss though.  I've been keeping a notebook of all the ways GalCiv is boring,
and how I'm going to fix them.  This has led me to a profound insight on the
nature of intelligence and searching, not to mention game design.

GalCiv suffers from the "unit pushing problem."  As a human being, I spend
the vast majority of my time futzing with whether this unit is 7 squares
away from that enemy unit.  In a world of better game AI, it wouldn't be so
hard to compute regions of safety from enemy units.  However, then I'd still
have to make a lot of decisions about where to put my units.  I envision an
architecture with lotsa set operations on regions.  While planning the
architecture, I notice its O(bad) algorithmic behavior, where 'bad' might be
n^4, some higher polynomial, or maybe exponential.  All depends on how much
thinking I want to do, and how much I'm willing to limit the scope of my
problems.  Maybe I can have my clean architecture if I settle for a board of
only 16x16 squares.  Maybe that is what a current PC can handle.

The operations required are all rather rote, basic computations.  Just
computing distances from one thing to another.   This makes me consider how
much the human brain is simply a more powerful computer, with better analog
sensing equipment, and thus able to leverage physics (light, heat, contact
forces) as part of the computing process.  We do lotsa things that aren't
very complicated, it's just gazillions of operations in parallel.  Our
brains point out how puny our computers really are, great as they may seem
for problems we're not so good at.

Some day we'll have enough silicon gates to equal a human brain.  If Moore's
Law holds we'll have 'em soon.  Even if Moore's Law fails at some point in
the future, there is too much industrial interest in the capability.  It'll
happen, even if we have to go back to building-sized computers to get things
done.  Of course, each and every one of us has working proof of concept that
these computers need not be building-sized.  If silicon computing doesn't do
it, biological computing will.

Given the gates, will we have 'intelligence' ?  What is 'intelligence' ?

I say, we will.  Because 'intelligence' is merely a search for satisfaction.
We have been trying to get satisfaction for millions of years.  That's why
we're at where we're at on the food chain.  Searching for satisfaction is an
evolutionary advantage; we have been "selected for" our willingness to
search.

Searches take the form of trial and error until better methods are refined.
The first searches weren't rocket science: pick up a stick and bash another
monkey in the head with it.  Good way to secure your food, water, and mates.
But refined for generations upon generations, with brains proving more adept
at storage and symbolic manipulations, and you arrive at the ICBM.  Of
course there are many other evolutionary stimulants besides warfare.  My
point is just that the seemingly complicated modern forms of 'intelligence'
have their bootstrapping root in fairly simple animal behaviors.  That's the
magic of evolution: it gets more complicated as life goes on.

We are also not so complicated if you thought about humanity from the
perspective of a 'God'.  By 'God' I just mean something much higher up the
evolutionary ladder than we currently are.  Notice all the tedious,
repetitive tasks in your life?  Notice how humanity's problems are so basic?
Like "Gee we don't feed everybody" even though we grow enough food to do so.
Notice how few people aspire to much of anything?  Notice that even the ones
that do, will mostly be erased by history in 100 years or so?  Maybe 1000
years if they're particularly profound.  Education being the province of the
wealthy, there was less philosophical competition in Aristotle's time.  ;-)

Do you see the cockroach in your own life?  Where is your 'intelligence' ?
You are simply searching for satisfaction, at the evolutionary level you are
capable of doing so.

If intelligence is about searching for satisfaction, and everyone wants to
be satisfied, why aren't more people smarter?  Well, the species doesn't
really need everyone to be smart to propagate.  In fact, it's probably
advantageous to the species, or at least to its smarter members, to have a
lot of dumber drones doing their bidding.  There's probably an optimum smart
/ dumb ratio under any given economic regime.  The current regime is global
capitalism; has the ratio changed that much from provincial monarchs
ordering uneducated peasants around?  Probably not by so much, considering
how much of the world is still in poverty while producing goods and services
for industrialized nations.  Not trying to grind a political axe here, just
trying to point out what 'intelligence' in our species really is.

At any rate, the 'smartest' among us are just algorithmically compulsive.
We search because we have a biological drive to search.  Many searches are
tried.  Some 'succeed', meaning they displace paradigms.

Even global capitalism might be displaced someday.  What would we do with a
technology that allowed us to easily grow food anywhere?  Or get energy
cheaply anywhere?  Or manufacture lotsa things cheaply anywhere?  Of course,
we could also use these things to edit ourselves out of existence.  :-)
Natural Selection at least has the benefit of promoting stable designs
rather than wild experiments!

How does this relate to OCaml?

Well, I've said before, I'm not sure that 'programming languages' are really
the answer as far as productivity goes.  I've wondered if OCaml is not the
answer, but the thing that will lead me to the answer.

Maybe what we really need are architectures that can handle massive search
spaces.  Profoundly stated, all programming language research as we know it
today may be an evolutionary dead end.  Why should we tie algorithmic search
to the quaintness of what human beings can type at a keyboard and see on a
2D screen?  Why do things with our parochial human notions of 'syntax' or
other linguistic constructs?  Just so that human beings can understand and
verify what's going on?  Isn't that always going to be a 'cottage industry'
approach to computation?

Ok, so, let's say you're more interested in the here and now than 20 years
hence.  I will be thinking about what OCaml does or doesn't do to handle
search problems.  Turn Based Strategy games are the particular search
problems I'm working on right now.  They're difficult; it'll be interesting
to see how much of the architecture is better done in a higher level
language, and how much as inflexible but massively high performance low
level computation.


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

"The pioneer is the one with the arrows in his back."
                          - anonymous entrepreneur

0
8/8/2004 9:36:10 PM
comp.lang.functional 2791 articles. 0 followers. Post Follow

384 Replies
1016 Views

Similar Articles

[PageSpeed] 51

Brandon J. Van Every wrote:
> The operations required are all rather rote, basic computations.  Just
> computing distances from one thing to another.   This makes me consider how
> much the human brain is simply a more powerful computer, with better analog
> sensing equipment, and thus able to leverage physics (light, heat, contact
> forces) as part of the computing process.

Explain how this powerful computer creates consciousness.

> If intelligence is about searching for satisfaction, and everyone wants to
> be satisfied, why aren't more people smarter?  Well, the species doesn't
> really need everyone to be smart to propagate.

I am not sure, but I think that biologists don't treat species as a unit
of evolution anymore. Some claim that evolution works on the level of
single genes. It is a gene that survives or vanishes from the gene pool.
A species is a higher-level form of evolution - a colony of organisms
which are themselves colonies of cells which in turn are controlled by
colonies of genes.

But you are talking about humans. I am not sure humans still really
evolve, at least in the highly-developed countries. There are at least
two mechanisms required for evolution to work: mutation and selection.
Medicine works hard to remove the latter.

Best regards,
Tom

-- 
..signature: Too many levels of symbolic links
0
t.zielonka2 (138)
8/8/2004 10:33:10 PM
Tomasz Zielonka wrote:
> Brandon J. Van Every wrote:
>> The operations required are all rather rote, basic computations.  Just
>> computing distances from one thing to another.   This makes me consider how
>> much the human brain is simply a more powerful computer, with better analog
>> sensing equipment, and thus able to leverage physics (light, heat, contact
>> forces) as part of the computing process.
>
> Explain how this powerful computer creates consciousness.

To be clear: I don't claim that consciousness is a prerequisite for
intelligence. I also don't claim that you can't explain consciousness in
terms of computation and/or physics. I am only questioning the use of
word "simply".

Best regards,
Tom

-- 
..signature: Too many levels of symbolic links
0
t.zielonka2 (138)
8/8/2004 10:50:11 PM
Discussions on AI tend to drift into inanity.
In any case, this is off topic for c.l.f.
Please keep these discussion in comp.ai and comp.lang.prolog
0
rambam (304)
8/9/2004 1:04:04 AM
Tomasz Zielonka <t.zielonka@zodiac.mimuw.edu.pl> writes:

> I am not sure, but I think that biologists don't treat species as a unit
> of evolution anymore. Some claim that evolution works on the level of
> single genes. 

It depends on the point of view you want to take.  If you want, you
can view an indiviual as a vehicle for genes.  A species will limit
the interaction between genes, however (branching the gene into
different lines of development), so the species is still important,
but perhaps a bit more vaguely defined than before.

> But you are talking about humans. I am not sure humans still really
> evolve, at least in the highly-developed countries. There are at least
> two mechanisms required for evolution to work: mutation and selection.
> Medicine works hard to remove the latter.

I think you will have evolution even without hard selection pressure.
It is believed that a lot of the genetic change occurs through
"genetic drift", just random changes that doesn't really affect
survivability and reproductability of the individual.  

-ketil
-- 
If I haven't seen further, it is by standing in the footprints of giants
0
ketil (99)
8/9/2004 8:17:30 AM
<snip>

Sorry to ignore the point of most of your post, but how are you finding 
OCaml?  I had a brief look at it recently, but not enough to judge it.
0
Peter
8/9/2004 11:32:51 AM
In article <2nnk2fF2nut4U1@uni-berlin.de>, 
try_vanevery_at_mycompanyname@yahoo.com says...
> 
> I say, we will.  Because 'intelligence' is merely a search for satisfaction.
> We have been trying to get satisfaction for millions of years.  That's why
> we're at where we're at on the food chain.  Searching for satisfaction is an
> evolutionary advantage; we have been "selected for" our willingness to
> search.

According to the 'Hitchhiker's Guide to the Galaxy', flying was simply a 
matter of throwing yourself at the ground - and missing.  Maybe 
intelligence is searching for satisfaction, and missing?  Okay, enough 
philosophy.

> Searches take the form of trial and error until better methods are refined.
> The first searches weren't rocket science: pick up a stick and bash another
> monkey in the head with it.  Good way to secure your food, water, and mates.
> But refined for generations upon generations, with brains proving more adept
> at storage and symbolic manipulations, and you arrive at the ICBM.  

> Maybe what we really need are architectures that can handle massive search
> spaces.  Profoundly stated, all programming language research as we know it
> today may be an evolutionary dead end.  Why should we tie algorithmic search
> to the quaintness of what human beings can type at a keyboard and see on a
> 2D screen?  Why do things with our parochial human notions of 'syntax' or
> other linguistic constructs?  Just so that human beings can understand and
> verify what's going on?  Isn't that always going to be a 'cottage industry'
> approach to computation?

Well, our programming techniques are a bit more complicated than that.  
One way of looking at programming something complicated like a game is 
that is is a case of creating a new language that is appropriate to the 
problem.  C++ and Ocaml don't have GetShortestPath keywords, but your 
map manipulation class (in either) will have a function that does it.  
When you use it you are writing in a higher level language that is good 
for war games.

Of course, shortest path algorithms [or maybe for this example, 
influence map algorithms] are trivial, but once you have them you can 
start working on the trickier GetSafeLocation() functions.  At that 
point you'll be into real AI...

> Ok, so, let's say you're more interested in the here and now than 20 years
> hence.  I will be thinking about what OCaml does or doesn't do to handle
> search problems.  Turn Based Strategy games are the particular search
> problems I'm working on right now.  They're difficult; it'll be interesting
> to see how much of the architecture is better done in a higher level
> language, and how much as inflexible but massively high performance low
> level computation.

Every journey begins with a single step.  If you only know roughly where 
you are going, you can still start building the basic components of your 
new language.

One reason I like C++ is that it gives you a relatively free hand with 
the syntax of the languages you build with it!

Gerry Quinn
http://bindweed.com
Games, Kaleidoscopes, and Screensavers
Try Chomp! - the new game of logical deduction




0
Gerry
8/9/2004 1:19:08 PM
Peter Ashford wrote:
> <snip>
>
> Sorry to ignore the point of most of your post, but how are you
> finding OCaml?  I had a brief look at it recently, but not enough to
> judge it.

Rigorously applying my infamous top-down managerial style, I still haven't
written a line of code in it.  :-)  I have made plenty of progress with it,
however.  Lotsa reading of the manuals and orchestrating tools and
libraries.  It should be realized that I didn't just have to swallow OCaml,
I also had to swallow the Functional Programming paradigm.  I think I sorta
get it; I won't strongly get it until I'm actually coding.  Also I detoured
through SML for a time, but OCaml has got the viable community so I switched
back.  For instance it has an OpenGL binding called LablGL which looks
reasonable, although I haven't delved deeply into it yet.  In SML/NJ land I
would have had to create the binding using experimental tools.  Maybe that
would work; possibly it wouldn't, and probably it would take a lot of time.

I get closer to understanding the performance implications of OCaml and how
to tie it to low level C code.  The C FFI is not so great, it's kinda
clunky.  Basically one needs to go through this thingy called Bigarray to
get the performance.  Bigarray understands simple native C types, unlike the
rest of OCaml.  However, you must use them in simple arrays of all ints or
all floats.  To process game maps this is still viable, however.  The
"flexible stuff" I'll do in OCaml proper, but map crunching probably needs
to be in some kind of low level, high performance C code.  I want a map
crunching architecture that's very simple so that I don't have to write a
lot of that C code.  I'm still working on the design.  Coding happens when I
finally understand how the problem must be solved.

ML Seattle continues to meet on a 3 week basis.  Tentatively we'll be
meeting again on Tuesday, August 17th.
http://groups.yahoo.com/group/mlseattle/


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

Taking risk where others will not.

0
8/9/2004 6:06:51 PM
Gerry Quinn wrote:
>
> Of course, shortest path algorithms [or maybe for this example,
> influence map algorithms] are trivial, but once you have them you can
> start working on the trickier GetSafeLocation() functions.  At that
> point you'll be into real AI...

Not really.  It's just more map crunching.  It all depends on what is meant
by 'real' here.  I did say we should embrace our inner cockroach.  "We're
all just crunching."

> One reason I like C++ is that it gives you a relatively free hand with
> the syntax of the languages you build with it!

I think the OCaml guys would scoff at that.  OCaml is proven at creating
domain-specific languages; it is definitely a "language maker's" tool.
That's part of why I've thought it may not be the answer, but it may lead me
to the answer.  So I'll keep going with it for awhile, even if something
turns sour.

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

"The pioneer is the one with the arrows in his back."
                          - anonymous entrepreneur

0
Brandon
8/9/2004 6:14:21 PM
Tomasz Zielonka wrote:
> Brandon J. Van Every wrote:
>> The operations required are all rather rote, basic computations.
>> Just computing distances from one thing to another.   This makes me
>> consider how much the human brain is simply a more powerful
>> computer, with better analog sensing equipment, and thus able to
>> leverage physics (light, heat, contact forces) as part of the
>> computing process.
>
> Explain how this powerful computer creates consciousness.

Please don't eliminate cross-posts, leave it only in comp.lang.functional,
and then ask for discussion about the AI philosophical portions of the post.
If you want to take it up in comp.ai.philosophy, I'm happy to do so.  I
understand snipping cross-posts to make things more topical, but that isn't
the case here.  I'm reading this thread from comp.ai.philosophy and I only
check other groups to see if anti-crossposters had snipped threads and/or
focused in on something else.

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

Brandon's Law (after Godwin's Law):
"As a Usenet discussion grows longer, the probability of
a person being called a troll approaches one RAPIDLY."

0
8/9/2004 8:10:36 PM
Brandon J. Van Every wrote:
> Please don't eliminate cross-posts, leave it only in comp.lang.functional,
> and then ask for discussion about the AI philosophical portions of the post.
> If you want to take it up in comp.ai.philosophy, I'm happy to do so.  I
> understand snipping cross-posts to make things more topical, but that isn't
> the case here.  I'm reading this thread from comp.ai.philosophy and I only
> check other groups to see if anti-crossposters had snipped threads and/or
> focused in on something else.

You are right. I don't read comp.ai.philosophy, but I suppose it's one
of the favourite subjects and someone will mention it anyway.

Best regards,
Tom

-- 
..signature: Too many levels of symbolic links
0
t.zielonka2 (138)
8/9/2004 9:05:29 PM
"Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com> wrote in
message news:2npsk1F3gnj8U1@uni-berlin.de...
> Gerry Quinn wrote:
> >
> > Of course, shortest path algorithms [or maybe for this example,
> > influence map algorithms] are trivial, but once you have them you can
> > start working on the trickier GetSafeLocation() functions.  At that
> > point you'll be into real AI...
>
> Not really.  It's just more map crunching.  It all depends on what is
meant
> by 'real' here.  I did say we should embrace our inner cockroach.  "We're
> all just crunching."
>
> > One reason I like C++ is that it gives you a relatively free hand with
> > the syntax of the languages you build with it!
>
> I think the OCaml guys would scoff at that.  OCaml is proven at creating
> domain-specific languages; it is definitely a "language maker's" tool.
> That's part of why I've thought it may not be the answer, but it may lead
me
> to the answer.  So I'll keep going with it for awhile, even if something
> turns sour.
>
or one can just use c and write their own language in the form of an
interpreter. one is only mildly constrained by any real aspect of the host
language in this respect, and largely things can be worked around eventually
anyways...
of course, making a decent language is not as easy as it might seem, and one
is likely to fail miserably (be it in terms of performance or inflexibility
or whatever) about as much as they are to have success.
one might also end up relying on designs that feel, if anything, somewhat
dubious, in which case one is left adding extra crap to notify them if the
approach decides to blow-up in their face eventually, eg, recently in the
type system I have been recently relying on the assumption that adler-32
checksums are sufficiently close to unique for short strings, but given the
way it works it might still result in conflicts (which would likely be quite
serious if they can't be handled in a deterministic manner).

I guess existing languages would work, but then you are limited to whatever
the designer(s) could imagine, and in my experience at least existing
interpreter sources tend to be quite messy and scary looking, so making
changes would be difficult...

or something...




0
cr88192
8/9/2004 10:23:39 PM
> 
>>One reason I like C++ is that it gives you a relatively free hand with
>>the syntax of the languages you build with it!
> 
> 
> I think the OCaml guys would scoff at that.  OCaml is proven at creating
> domain-specific languages; it is definitely a "language maker's" tool.
> That's part of why I've thought it may not be the answer, but it may lead me
> to the answer.  So I'll keep going with it for awhile, even if something
> turns sour.
> 

That's interesting.  I was agreeing with Gerry insofar as any OO 
language kind of is building up a language to solve your problem (if you 
accept that the objects you build become effectively an extension to the 
core language)

In what way does OCaml eclipse that kind of tool creation ability that 
you get from OO languages?
0
Peter
8/10/2004 12:20:44 AM
cr88192 wrote:
> "Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com>
> wrote in message news:2npsk1F3gnj8U1@uni-berlin.de...
>> Gerry Quinn wrote:
>>
>>> One reason I like C++ is that it gives you a relatively free hand
>>> with the syntax of the languages you build with it!
>>
>> I think the OCaml guys would scoff at that.  OCaml is proven at
>> creating domain-specific languages; it is definitely a "language
>> maker's" tool. That's part of why I've thought it may not be the
>> answer, but it may lead me to the answer.  So I'll keep going with
>> it for awhile, even if something turns sour.
>>
> or one can just use c and write their own language in the form of an
> interpreter.

I think it is very foolish to be writing Yet Another Language when there are
so many extant, generously licensed language projects already out there.
Having it working already, communities, and libraries are all very important
considerations when deciding whether it's wise to write a language from
scratch.  If you do it anyways, it's at least often preferrable to start
from someone else's working codebase, assuming a MIT style license.  All of
the major languages with such licenses have minor offshoots, and maybe one
of 'em will prove to be a better successor language some day.

Of course, cr8, you are a highly unusual special case.  You code like
bejeezus and can actually barf out all of your own 'starter code' quickly.
The vast majority of people are not as prolific as you are.  Unfortunately,
although you excel at breadth of output, you lack depth of focus.  You don't
even really know why you code, what the goal of your language is, or what
your strategic target is.  Your sheer prowess at coding isn't going to be of
any use to anyone else, until such a time as you embrace other aspects of
design and deployment.

I'm like your cardinal opposite.  All design and strategy, no code.  :-)
Well, honestly I'd be making better progress right now if the day job wasn't
getting in the way.  At least I know what intelligence is now.

> of course, making a decent language is not as easy as it might seem,
> and one is likely to fail miserably (be it in terms of performance or
> inflexibility or whatever) about as much as they are to have success.
> one might also end up relying on designs that feel, if anything,
> somewhat dubious, in which case one is left adding extra crap to
> notify them if the approach decides to blow-up in their face
> eventually,

Right.  Not Invented Here carries some big penalties.  From a risk
management standpoint, it's better to let someone else be the Fall Guy on
what works and what doesn't.  Before I would bother to write my own
language, I'd look at all the commonly available languages and decide what
their strengths and deficiencies are.  Having done that exercise for about a
year now, the following themes recur for me:

- I care about 3D graphics and AI
- I must have a way to efficiently access simple C types
- A good C Foreign Function Interface is highly preferrable
- I need an OpenGL binding or an easy way to achieve it
- The language must be compileable
- I'd like it to also be scriptable
- It must have garbage collection
- I'm looking for better syntax, better abstractions, and recombinative
capabilities
- Windows support has to be decent
- It must have a viable community
- It must have a potential commercial growth trajectory, i.e. not be stuck
in academia

> I guess existing languages would work, but then you are limited to
> whatever the designer(s) could imagine,

Some language designers are quite imaginative.  Of course, they all have
different foci.  The trick is finding a bunch of language designers who
somewhat share your concerns.  For instance, I don't like language designers
who don't care about performance or C FFIs.

> and in my experience at least
> existing interpreter sources tend to be quite messy and scary
> looking, so making changes would be difficult...

Well, every project is different.  I do think that understanding other
people's source code is a PITA, but some source codes are easier to
understand than others.  The effort is worth it if the language gives you
something and you really need to modify it.  I'd need a strong reason to
modify something before I'd bother.  The main thing that bothers me right
now is, "how well does this language understand C, so that I can access my
low level 3D graphics and AI operations efficiently?"

OCaml is not perfect in this regard, it could use some work.  Fortunately, I
know a guy here in Seattle who has undertaken exactly that sort of work.
He's got a project called Forklift.  It's not complete but if I decide to
deal with this problem, I have somewhere to begin + the person who began it.
http://jhenrikson.org/forklift/


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

"We live in a world of very bright people building
crappy software with total shit for tools and process."
                                - Ed Mckenzie

0
8/10/2004 8:22:08 AM
"Brandon J. Van Every" wrote:

> I get closer to understanding the performance implications of OCaml and how
> to tie it to low level C code.  The C FFI is not so great, it's kinda
> clunky.

Can you elaborate a bit on that. What do you miss from the FFI?

Is the OCaml FFI itself flawed or is it cumbersome to take workarounds?

I have never used the OCaml FFI. I use sometimes Bigloo its one.

What is your subjective feeling of the readability of OCaml code? I gather from
your posts that you eagerly are reading and studying OCaml code. When I was
reading other's OCaml code I always felt that there is something wrong with
their attitude: I mean what is bad concerning giving type annotations. Cleaners
do it all the time. The other day I started to type even my Bigloo code; the
latter tremendously improves managing the code but I have got always the
freedom of Scheme programming if I like.

Do you feel that the code in the OCaml distributuion is worth the reading.  If
one believes in the following link then one of the important things when using
alternative languages is their quality of  code of the distribution itself.
However, I am not a professional programmer (you know: I am an academic ass in
a physics departement) but I imagine that professional programmers learn from
code which comes with the distribution:

http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&threadm=40FCBDA1.BCDC11FE%40kfunigraz.ac.at&prev=/groups%3Fdq%3D%26num%3D25%26hl%3Den%26lr%3D%26ie%3DUTF-8%26group%3Dcomp.lang.scheme%26start%3D25

Fensterbrett

0
8/10/2004 9:11:53 AM
"Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com> wrote in
message news:2nre9kF3qs2qU1@uni-berlin.de...
> cr88192 wrote:
> > "Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com>
> > wrote in message news:2npsk1F3gnj8U1@uni-berlin.de...
> >> Gerry Quinn wrote:
> >>
> >>> One reason I like C++ is that it gives you a relatively free hand
> >>> with the syntax of the languages you build with it!
> >>
> >> I think the OCaml guys would scoff at that.  OCaml is proven at
> >> creating domain-specific languages; it is definitely a "language
> >> maker's" tool. That's part of why I've thought it may not be the
> >> answer, but it may lead me to the answer.  So I'll keep going with
> >> it for awhile, even if something turns sour.
> >>
> > or one can just use c and write their own language in the form of an
> > interpreter.
>
> I think it is very foolish to be writing Yet Another Language when there
are
> so many extant, generously licensed language projects already out there.
> Having it working already, communities, and libraries are all very
important
> considerations when deciding whether it's wise to write a language from
> scratch.  If you do it anyways, it's at least often preferrable to start
> from someone else's working codebase, assuming a MIT style license.  All
of
> the major languages with such licenses have minor offshoots, and maybe one
> of 'em will prove to be a better successor language some day.
>
dunno.
I liscenced my language lgpl, though it is not terribly obvious since I
generally failed to put the lgpl header in most of my files, and one has to
be careful as some code is under gpl or such...

I am not that fammiliar with the mit liscence.

> Of course, cr8, you are a highly unusual special case.  You code like
> bejeezus and can actually barf out all of your own 'starter code' quickly.
> The vast majority of people are not as prolific as you are.
Unfortunately,
> although you excel at breadth of output, you lack depth of focus.  You
don't
> even really know why you code, what the goal of your language is, or what
> your strategic target is.  Your sheer prowess at coding isn't going to be
of
> any use to anyone else, until such a time as you embrace other aspects of
> design and deployment.
>
dunno.
I can't come up with much of anything in particular to focus on, or if I do
come up with something I seem to get stuck...

> I'm like your cardinal opposite.  All design and strategy, no code.  :-)
> Well, honestly I'd be making better progress right now if the day job
wasn't
> getting in the way.  At least I know what intelligence is now.
>
ok.

> > of course, making a decent language is not as easy as it might seem,
> > and one is likely to fail miserably (be it in terms of performance or
> > inflexibility or whatever) about as much as they are to have success.
> > one might also end up relying on designs that feel, if anything,
> > somewhat dubious, in which case one is left adding extra crap to
> > notify them if the approach decides to blow-up in their face
> > eventually,
>
> Right.  Not Invented Here carries some big penalties.  From a risk
> management standpoint, it's better to let someone else be the Fall Guy on
> what works and what doesn't.  Before I would bother to write my own
> language, I'd look at all the commonly available languages and decide what
> their strengths and deficiencies are.  Having done that exercise for about
a
> year now, the following themes recur for me:
>
> - I care about 3D graphics and AI
> - I must have a way to efficiently access simple C types
> - A good C Foreign Function Interface is highly preferrable
> - I need an OpenGL binding or an easy way to achieve it
> - The language must be compileable
> - I'd like it to also be scriptable
> - It must have garbage collection
> - I'm looking for better syntax, better abstractions, and recombinative
> capabilities
> - Windows support has to be decent
> - It must have a viable community
> - It must have a potential commercial growth trajectory, i.e. not be stuck
> in academia
>
ok.

yes. at least one should try to keep dubious designs from being to central,
or at least consider possible workarounds in case the issues of the design
become apparent. often just some code needs to be changed or rewritten, or
in the worst case a lot of stuff needs to be thrown away or one might have
to largely start over.

personally I don't know of any languages that fulfill all of this.
also, in damn near every language I see things I like and things I don't
like, but this is more a "taste" issue.

actually the main issues I keep seeing are:
the use of strange syntax;
bad support for functional programming;
bad support for imperative programming;
crappy object systems;
....

I can't say I do any better, but I like to think so at least, or at least if
I don't like something I can fix it...

now for your points:
> - I care about 3D graphics and AI
dubious, I let this aspect decay a bit too much.

> - I must have a way to efficiently access simple C types
in my case the inverse holds, eg, it is fairly straightforward for c code to
use my language's data types (as in most cases casting or assigning to a
variable with the correct type is sufficient).

> - A good C Foreign Function Interface is highly preferrable
err, nope...
I tried writing a tool to generate interfaces via use of c headers at one
point (sort of like swig, but I wanted to be able to use any c header...),
but gave up eventually as, eg, the cygwin headers tend to involve far too
much weird crap and it was getting tiring trying to parse all of it.
> - I need an OpenGL binding or an easy way to achieve it
at least my headerizer could process the gl headers, but I never got around
to writing the part to convert the interface definitions to code...
> - The language must be compileable
nope, or at least not currently.
> - I'd like it to also be scriptable
yep.
> - It must have garbage collection
yep.
> - I'm looking for better syntax, better abstractions, and
> recombinative capabilities
depends on what you want, err, I have a sort of c or javascript style
syntax.
the syntax is tweakable if code is written to handle and compile whatever
features are added.

> - Windows support has to be decent
depends on what is meant here...
> - It must have a viable community
seriously nope.
> - It must have a potential commercial growth trajectory, i.e. not be stuck
> in academia
I doubt it.

but whatever, I wrote it for myself, others can just use perl or python or
whatever...

> > I guess existing languages would work, but then you are limited to
> > whatever the designer(s) could imagine,
>
> Some language designers are quite imaginative.  Of course, they all have
> different foci.  The trick is finding a bunch of language designers who
> somewhat share your concerns.  For instance, I don't like language
designers
> who don't care about performance or C FFIs.
>
yes, and if their focus does not match mine, then the lang is not very
interesting to me... it is hard enough keeping my language interesting to
me, but it does have the advantage of being mine.

an ffi needs tools of some sort, but there is some balance, eg: between the
amount of work required to write interfaces and the amount of work required
to write the tool, that is not being met.

also, how to deal with more than trivial types or semantic mismatches is
another more complicated issue that doesn't seem that easily solvable by a
tool.

otherwise, one might be left having to write large globs of text describing
each and every function, variable, or constant that they want to import,
which would make gluing to existing api's a hassle.
eventually, though, this may be what is required...

> > and in my experience at least
> > existing interpreter sources tend to be quite messy and scary
> > looking, so making changes would be difficult...
>
> Well, every project is different.  I do think that understanding other
> people's source code is a PITA, but some source codes are easier to
> understand than others.  The effort is worth it if the language gives you
> something and you really need to modify it.  I'd need a strong reason to
> modify something before I'd bother.  The main thing that bothers me right
> now is, "how well does this language understand C, so that I can access my
> low level 3D graphics and AI operations efficiently?"
>
well, I looked before, eg, at scm, the self vm, ... and was largely scared
off by the kinds of things I saw:
craploads of goto's/failure to use goto and while where it would make sense
to do such;
strange and awkward access to the typesystem;
....
along with quite often my eternal nemesis:
the 1 or 2 space tab, with often unindented lines and putting the brace on
the end of the previous line, or failing to break the line at some
reasonable position (eg: 80, like they were relying on word wrap or
something);
well, this and people going k&r on me.

  double
foo(x, y)
double x, y; {
  return sqrt(x*x+y*y);}

now, consider things like this being done with c++, combined with craploads
of ifdefs and too many overly small source files, and you have the self
vm...

totally eww...

yes, not "all" projects are like this, but far too many are...

> OCaml is not perfect in this regard, it could use some work.  Fortunately,
I
> know a guy here in Seattle who has undertaken exactly that sort of work.
> He's got a project called Forklift.  It's not complete but if I decide to
> deal with this problem, I have somewhere to begin + the person who began
it.
> http://jhenrikson.org/forklift/
>
ok.




0
cr881921 (15)
8/10/2004 9:26:21 AM
Peter Ashford wrote:
>>> One reason I like C++ is that it gives you a relatively free hand
>>> with the syntax of the languages you build with it!
>>
>>
>> I think the OCaml guys would scoff at that.  OCaml is proven at
>> creating domain-specific languages; it is definitely a "language
>> maker's" tool. That's part of why I've thought it may not be the
>> answer, but it may lead me to the answer.  So I'll keep going with
>> it for awhile, even if something turns sour.
>>
>
> That's interesting.  I was agreeing with Gerry insofar as any OO
> language kind of is building up a language to solve your problem (if
> you accept that the objects you build become effectively an extension
> to the core language)
>
> In what way does OCaml eclipse that kind of tool creation ability that
> you get from OO languages?

OCaml is an OO language.  That's what the 'O' is for.  It will also allow
you to code imperatively, you don't have to use the Functional paradigm.
Basically you can do what you like, whatever is appropriate to your problem
and suitable to your current mode of thinking / understanding.  So if
there's an 'eclipse', it's that you have more options at your disposal.

Also OCaml has pattern matching, which is quite a bit more built-in
expressive power than anything C++ has.  Also it has Functors and
Parameterized Classes, which make C++ Templates seem pretty brittle and lame
by comparison.

Also OCaml is a "language writer's language."  I'm not sure how people
actually use it to write their domain-specific langauges, as I don't really
know much of anything about writing languages.  People seem to do stuff with
a macro preprocessor called CamlP4.  I do know that OCaml is proven for use
among language theorists, that dealing with 'languages for programming' is a
core strength / point of what is done with it.  In other words, it has a
strong academic pedigree for such jobs.  Unfortunately these aren't my
problems, I'm into 3D graphics, AI, and games.

That said, intereresting work is being done with OCaml.  There's some
paradigm called Generative Programming and some thingy called MetaOCaml,
which I haven't looked into deeply yet.  http://www.metaocaml.org/  I'll be
researching this as part of my long term strategy for "where we're supposed
to go with computers."  But right now I'm still on OCaml basics, not OCaml
guruism.

The other upcoming paradigm shift that I think will be incredibly important
is fullblown voice recognition and voice synthesis.  If we get to the point
where we can *talk* to our computers with 100% accuracy, that's going to
change commerce fundamentally.  I don't know if there's going to be some
other Next Big Thing before then, but when we have full voice, it'll be like
the dot.com boom.

This is all reminiscent of some tech tree in a 4X TBS, where you're
wondering which tech you should research next to gain the most advantage.
:-)  More difficult when you don't know all the pros and cons of the techs
in advance!

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

"The pioneer is the one with the arrows in his back."
                          - anonymous entrepreneur

0
8/10/2004 9:31:25 AM
"Brandon J. Van Every" wrote:

> But right now I'm still on OCaml basics, not OCaml
> guruism.

Maybe you should actually take the outrageously daring move of writing
an actual line of code in OCaml?

-- 
 __ Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
/  \ San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
\__/ I used to walk around / Like nothing could happen to me
    -- TLC
0
max78 (1220)
8/10/2004 9:53:06 AM
On Tue, 10 Aug 2004, Peter Ashford wrote:

> In what way does OCaml eclipse that kind of tool creation ability that
> you get from OO languages?
>

I'll answer for Haskell, as I don't use ML much, but some of the points
still stand:

1) There are excellent parsing tools available - in particular, this seems
to be where Spirit got its inspiration from

2) The pattern-matching facilities, which operate on any data type. They
make mildly complicated transformations on trees and graphs an absolute
doddle.

3) Higher-order functions make it easier to build up code at run-time.

4) Techniques such as monads and monad transformers make it even easier -
you can build the semantics of your DSL piece-by-piece.

5) The type systems are more suited to this kind of work.

-- 
flippa@flippac.org
0
Philippa
8/10/2004 10:40:16 AM
cr88192 wrote:
>
> I am not that fammiliar with the mit liscence.

MIT license is "do whatever you want with the code."  It's not public
domain, however.  You have to acknowledge that the code is Copyright by
whoever wrote it.

BSD license is almost identical.  The additional provisio is you can't use
the name of the Copyright holder as a form of endorsement.  You can't ship
MySoftware using OtherGuyCode and say, "My product is so great and fantastic
because it usess OtherGuyCode, that's why you should buy it!  OtherGuyCode
is this wonderful entity that yadda yadda yadda...."  The idea here is that
OtherGuyCode really doesn't want you conducting marketing campaigns on their
behalf.  They want to market themselves in their own way and not have other
people saying things about their stuff.  After all, what if MySoftware sucks
and thereby taints the reputation of OtherGuyCode?

Anyways, aside from this one small caveat, MIT and BSD are identical.  Do
what you want with the code.  Personally, if I release anything it'll be
under MIT, because I want people to feel free to yak yak yak about how great
I am until they're blue in the face.  :-)

>> Of course, cr8, you are a highly unusual special case.  You code like
>> bejeezus and can actually barf out all of your own 'starter code'
>> quickly. The vast majority of people are not as prolific as you are.
> Unfortunately,
>> although you excel at breadth of output, you lack depth of focus.
>> You don't even really know why you code, what the goal of your
>> language is, or what your strategic target is.  Your sheer prowess
>> at coding isn't going to be of any use to anyone else, until such a
>> time as you embrace other aspects of design and deployment.
>>
> dunno.
> I can't come up with much of anything in particular to focus on, or
> if I do come up with something I seem to get stuck...

Right.  You've mastered breadth of development.  You are a rank amateur at
depth of development.  It's learnable, but you have to actually desire to do
so.  To date, that desire is lacking on your part.  You're always working on
the project of the moment, building up some big yam pile of code, rather
than any long term goal.

This is probably because producing code pleases you, in and of itself.
Whereas I usually find it bloody irritating, so I've concentrated on 'why'
rather than 'Just Do It.'  My evolution is the exact opposite from yours.  I
have mounds and mounds of *notebooks* built up over the years.  Not mounds
and mounds of code.  I can design things on paper extremely easily.

It's too bad we can't get you more addicted to some game, so that you'd
become obsessed with some genre, and then have a firm goal for that prolific
coding output of yours.  As it stands, you're condemned to drift upon the
waters until you latch on to something that causes you to focus.

> personally I don't know of any languages that fulfill all of this.
> also, in damn near every language I see things I like and things I
> don't like, but this is more a "taste" issue.

I was unable to find a language that had it all.  OCaml has most of it.  I
figure if I get farther and farther into OCaml, eventually I might fix
whatever's broken about it.  It is open source, after all.

> actually the main issues I keep seeing are:
> the use of strange syntax;

OCaml's syntax is baroque, but not as bad as C++.

> bad support for functional programming;
> bad support for imperative programming;

OCaml supports both just fine.

> crappy object systems;
> ...

OCaml is OO.  I doubt it's 'crappy' given all the functional bells and
whistles at one's disposal, but I don't have experience with it yet either
so I really can't say.

> I can't say I do any better, but I like to think so at least, or at
> least if I don't like something I can fix it...

But the price of "I can fix anything," taken to your extreme limit, is you
never really get anything done.  You take too many engineering
responsibilities upon yourself.  Sure you code prolifically, but even the
most prolific coder can't get anywhere without a good plan.  A good design.
And good design is *hard*.  There's a reason you're not good at it, it takes
years to hone good design skills.  So, you're just going to keep running
into the "too much labor to design" brick wall over and over again, until
you wise up and realize you don't really want to write everything yourself.
What you want to do, is write a small chunk of stuff yourself that's core to
your strategic goal.  "I can fix anything" isn't a strategic goal.  It's an
undirected dispersal of energy on a perceived, non-critical problem.

Software managers talk about "the critical path."  The stuff you absolutely
need to get done to ship your app.  What's your critical path, cr8?  At
present, you don't have one.  Nothing's critical, so you have no path.

>> - A good C Foreign Function Interface is highly preferrable
> err, nope...
> I tried writing a tool to generate interfaces via use of c headers at
> one point (sort of like swig, but I wanted to be able to use any c
> header...), but gave up eventually as, eg, the cygwin headers tend to
> involve far too much weird crap and it was getting tiring trying to
> parse all of it.

I don't know much about language writing, but I've bumped into so many
people that say this is a difficult problem, due to macro preprocessing and
whatnot, that I conclude, "That waay thaere bee Dragons."

>> Some language designers are quite imaginative.  Of course, they all
>> have different foci.  The trick is finding a bunch of language
>> designers who somewhat share your concerns.  For instance, I don't
>> like language designers who don't care about performance or C FFIs.
>>
> yes, and if their focus does not match mine, then the lang is not very
> interesting to me... it is hard enough keeping my language
> interesting to me, but it does have the advantage of being mine.

Yes, but what *is* your focus?  You don't have one!  So nobody can match it.

At present your lack of focus seems to be:
- You like C/UNIX style hacking.
- You like being able to change everything.
- You pick flavor-of-the-month (week??) problems to work on, so prototyping
must be important to you.
- You don't really care about performance, just getting things working.

This puts you in the scripting language camp.  So, what do you think of Lua?
Or Ruby?

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

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

0
8/10/2004 10:46:48 AM
Siegfried Gonzi wrote:
> "Brandon J. Van Every" wrote:
>
>> I get closer to understanding the performance implications of OCaml
>> and how
>> to tie it to low level C code.  The C FFI is not so great, it's kinda
>> clunky.
>
> Can you elaborate a bit on that. What do you miss from the FFI?

Ocaml does not natively understand 32-bit integers!  It only uses 31-bit
integers, keeping 1 bit for garbage collection purposes.  Personally I'm not
at all pleased with this language design choice.  It's one of the things I
wish I didn't have to explain about OCaml when promoting it.

OCaml, like many other Higher Level Languages, also doesn't support 32-bit
floats.  It thinks 64-bit doubles are good enough for anything.  This is
annoying and shows that a language isn't mature in the realm of 3D graphics.

These warts can be worked around.  There's a module called Bigarray that
will allow you to have unboxed arrays of native 32-bit integer types, or
32-bit floats.  The purpose is to make it easier to pass data back and forth
to C or Fortran programs.  The problem is you can only have an array of the
simple type.  You can't have C structures, which is often what you really
want an array of.  These limitations aren't insurmountable to the game
designer, if you're creating your own design.  They'd be a bitch for
interfacing to someone else's code though.

The OCaml C FFI also gets hairy when you want to pass more than 5
parameters.  You end up having to do it in 2 steps!  Also you have to do the
OCaml 31-bit type to C 32-bit type translation.  That's a PITA.  I don't
really want to deal with any of this.  So, I'm mainly focusing on how to use
Bigarray to avoid the work.

> What is your subjective feeling of the readability of OCaml code?

I don't have trouble so much with OCaml as with Functional Programming
styles.  I'm still not to the point of being able to read other people's
OCaml code and know what's going on.  Then again, often I don't know what's
going on with other people's C++ code either!

Or more accurately, I don't wish to know.  Whenever someone shows me a code
snippet, my eyes glaze over.  I don't like anyone's code, I only like what I
built myself.  This is because if I went through the mental steps to build
the code, then I know what it does.  Even if I come back to it months later,
my style + my comments makes it quite accessible to me.  Of course, I
tolerate other people's code as a matter of industrial necessity.  But, I
minimize my interaction with other people's code as much as possible.  My
ideal universe would have only my code 97% of the time.  I think the real
power of programming is building *your own* semantic system.  Using other
people's semantic systems frequently is no more than slavery, i.e. corporate
bumblefuck APIs to sell someone's godawful OS.

I think Python code is easy to read.  It should be, because that was a core
of its design.  Most languages haven't had that as a core design priority.
I'd say readability and ease of use are Python's major contributions to
languagedom.

OCaml is difficult to read, at least at first.  To a complete newbie, it's a
tossup between OCaml and C++ as to which is more difficult.  I think
advanced guys are going to have an easier time in OCaml though.  It's
baroque, but not as bad as C++.  For instance it has type inference, so you
don't have to type 'int' all the friggin' time.  Also I just don't see the
potential for the "son of a virtual son of a multiply inherited base class
constructor with member function pointer" problems as I did in C++.  My
impression is that the organizational paradigms of OCaml are simpler than
that, once you've swallowed Functional Programming.

> I gather from
> your posts that you eagerly are reading and studying OCaml code.

No, I hate studying OCaml *code*.  My attention is upon OCaml
*documentation*.  Like, how does Bigarray work so I can get around C FFI
problems.  And designing my AI algorithms.  What components of the language
will allow me to do that more effectively?  That's what I'm currently
working on.  I don't care about other people's code, they're not solving my
problems.

> When I was
> reading other's OCaml code I always felt that there is something
> wrong with
> their attitude: I mean what is bad concerning giving type
> annotations.

Because most of the time you shouldn't need to type extra words.  Compilers
can usually figure this stuff out.  Why should we do lotsa extra boring
manual labor for the compiler's benefit?  It's a machine, it doesn't get
bored, it should make our coding job easier.

OCaml isn't anal about this issue: type annotations are used when needed.
So I don't see that OCaml has "the wrong attitude" in any way here.

> Cleaners
> do it all the time. The other day I started to type even my Bigloo
> code; the
> latter tremendously improves managing the code but I have got always
> the freedom of Scheme programming if I like.

The ML camp does not believe in freedom of type.  They believe in strongly,
rigorously knowing all types.  They don't belive in having to type lotsa
extra verbiage about it, they think the compiler should infer the type as
often as possible.  I do not yet know how much industrial advantage this
exceedingly strong, anal notion of typing yields.  It could yield a lot, but
on the other hand, I've been through what RISC actually yields in industrial
practice.  Many claims are often made for things that just don't pan out to
be so relevant or achievable in the real world.

> Do you feel that the code in the OCaml distributuion is worth the
> reading.

Well, in the sense that I looked at the C module of Bigarray to understand
what it does, I guess I'd answer "yes."  But I'd answer "no" in general,
because I do not like reading code.  :-)  I will probably answer "yes"
when/if I want to fix some of OCaml's warts someday.

> If
> one believes in the following link then one of the important things
> when using
> alternative languages is their quality of  code of the distribution
> itself.

Bigarray was reasonable.  But, it was also pretty trivial.  I have no idea
how complicated the core of the language is.

I will say, if you think your first problem is mucking around with the
internals of a language implementation, trying to change it, submitting
those changes to the administrative body, and getting them approved, is how
you should be using your time, then you've got totally screwed up
priorities.  First see if you can get something done with the language,
regardless of what it looks like under the hood.

> However, I am not a professional programmer (you know: I am an
> academic ass in
> a physics departement) but I imagine that professional programmers
> learn from code which comes with the distribution:

Some do, others don't.  I far prefer to bang things out with people in
newsgroups and mailing lists.  Also to read a lot of documentation, so that
I'm not saying completely stupid things on the mailing lists.  Eventually I
make enough passes through documentation that I understand what a language
can and can't do.  I will say that OCaml documentation is fine.


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

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

0
8/10/2004 11:15:25 AM
"Brandon J. Van Every" wrote:

>
> These warts can be worked around.  There's a module called Bigarray that
> will allow you to have unboxed arrays of native 32-bit integer types, or
> 32-bit floats.  The purpose is to make it easier to pass data back and forth
> to C or Fortran programs.  The problem is you can only have an array of the
> simple type.  You can't have C structures, which is often what you really
> want an array of.  These limitations aren't insurmountable to the game
> designer, if you're creating your own design.  They'd be a bitch for
> interfacing to someone else's code though.
>

As far as I can remember that also plagues Bigloo. Some do not consider Bigloo
a legal Scheme programming language out of that reason.

But Tim jr. (the man behind the PHP/Bigloo compiler and the link  was given in
my last post) once posted a workaround on the Bigloo mailing list. He used some
external C types. Surely, the situation still remains "wacky" especially for
people who come from another Scheme camp. But one must honestly say, that the
Bigloo manual never hides that shortcomming of 31-bit integers.

I once tried to make a binding between OCaml and the plotting library DISLIN.
But as you wrote, I was a bit irritated by the passing scheme when there were
more than 5 variables in an external C function. I never grasped that scheme;
surely OCaml by nature is much more complex than Bigloo I assume and
communicating with external C code is not that easy.

In the meantime I have completed the binding to DISLIN but for Bigloo.
Integrating C code in Bigloo was easy. The binding now is as comfortable to use
as the one for Python/DISLIN.



>
>
> Because most of the time you shouldn't need to type extra words.  Compilers
> can usually figure this stuff out.  Why should we do lotsa extra boring
> manual labor for the compiler's benefit?  It's a machine, it doesn't get
> bored, it should make our coding job easier.

It is not so much the typing issue itself rather it is something like
"documenting my own code".

I much prefer something like the following:

==
(define (do-this var::double s::bstring saro::vector bul::pair)
      )
==

over:

==
(define (do-this var s saro bul)
)
==

The OCaml lacks such an "educational" style. This was in stark contrast to the
Clean manuals.


Out of curiosity: how many people attended your first ML meeting?

Fensterbrett

0
8/10/2004 11:27:23 AM
In article <2npsk1F3gnj8U1@uni-berlin.de>, 
try_vanevery_at_mycompanyname@yahoo.com says...
> Gerry Quinn wrote:
> >
> > Of course, shortest path algorithms [or maybe for this example,
> > influence map algorithms] are trivial, but once you have them you can
> > start working on the trickier GetSafeLocation() functions.  At that
> > point you'll be into real AI...
> 
> Not really.  It's just more map crunching.  It all depends on what is meant
> by 'real' here.  I did say we should embrace our inner cockroach.  "We're
> all just crunching."

It's not obvious to me how to define a safe location, or that such a 
definition is even possible.  What is safe depends on a lot of 
circumstances.  It's a fuzzy problem, whereas a shortest path analysis 
just involves plugging in a standard algorithm.  

> > One reason I like C++ is that it gives you a relatively free hand with
> > the syntax of the languages you build with it!
> 
> I think the OCaml guys would scoff at that.  OCaml is proven at creating
> domain-specific languages; it is definitely a "language maker's" tool.
> That's part of why I've thought it may not be the answer, but it may lead me
> to the answer.  So I'll keep going with it for awhile, even if something
> turns sour.

Well, maybe both C++ and Ocaml have this property.  My own view is that 
designing and programming games is hard, and so long as your language is 
powerful, scales well, and is not too awful, it's not the problem.  Of 
course you think C++ is too awful - I'm happy to stick with it.

- Gerry Quinn

0
Gerry
8/10/2004 1:02:37 PM
In article <2nribhF3pupgU1@uni-berlin.de>, 
try_vanevery_at_mycompanyname@yahoo.com says...
> Peter Ashford wrote:
> >
> > In what way does OCaml eclipse that kind of tool creation ability that
> > you get from OO languages?
> 
> OCaml is an OO language.  That's what the 'O' is for.  It will also allow
> you to code imperatively, you don't have to use the Functional paradigm.
> Basically you can do what you like, whatever is appropriate to your problem
> and suitable to your current mode of thinking / understanding.  So if
> there's an 'eclipse', it's that you have more options at your disposal.
> 
> Also OCaml has pattern matching, which is quite a bit more built-in
> expressive power than anything C++ has.  Also it has Functors and
> Parameterized Classes, which make C++ Templates seem pretty brittle and lame
> by comparison.

Doesn't this go back to a comment you made earlier, though - the things 
computer languages express are not the same as the things we want to 
express?

At some stage you're going to be writing a function that in C++ might 
look like:

Map::GetShortestPath( const Location & startLoc, const Location & 
endLoc, vector< Location > & path )

And in C++ or Ocaml, it's going to have a similar I/O format, and be 
algorithmically similar under the hood.

- Gerry Quinn














0
gerryq (1329)
8/10/2004 1:18:40 PM
"Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com> wrote in 
message news:2nrmosF3thv2U1@uni-berlin.de...
> cr88192 wrote:
>>
>> I am not that fammiliar with the mit liscence.
>
> MIT license is "do whatever you want with the code."  It's not public
> domain, however.  You have to acknowledge that the code is Copyright by
> whoever wrote it.
>
ok.

> BSD license is almost identical.  The additional provisio is you can't use
> the name of the Copyright holder as a form of endorsement.  You can't ship
> MySoftware using OtherGuyCode and say, "My product is so great and 
> fantastic
> because it usess OtherGuyCode, that's why you should buy it!  OtherGuyCode
> is this wonderful entity that yadda yadda yadda...."  The idea here is 
> that
> OtherGuyCode really doesn't want you conducting marketing campaigns on 
> their
> behalf.  They want to market themselves in their own way and not have 
> other
> people saying things about their stuff.  After all, what if MySoftware 
> sucks
> and thereby taints the reputation of OtherGuyCode?
>
> Anyways, aside from this one small caveat, MIT and BSD are identical.  Do
> what you want with the code.  Personally, if I release anything it'll be
> under MIT, because I want people to feel free to yak yak yak about how 
> great
> I am until they're blue in the face.  :-)
>
ok.
the bsd liscence is pretty cool imo...
similar would likely go for the mit liscence.

in your oppinion, how does lgpl compare?

>>> Of course, cr8, you are a highly unusual special case.  You code like
>>> bejeezus and can actually barf out all of your own 'starter code'
>>> quickly. The vast majority of people are not as prolific as you are.
>> Unfortunately,
>>> although you excel at breadth of output, you lack depth of focus.
>>> You don't even really know why you code, what the goal of your
>>> language is, or what your strategic target is.  Your sheer prowess
>>> at coding isn't going to be of any use to anyone else, until such a
>>> time as you embrace other aspects of design and deployment.
>>>
>> dunno.
>> I can't come up with much of anything in particular to focus on, or
>> if I do come up with something I seem to get stuck...
>
> Right.  You've mastered breadth of development.  You are a rank amateur at
> depth of development.  It's learnable, but you have to actually desire to 
> do
> so.  To date, that desire is lacking on your part.  You're always working 
> on
> the project of the moment, building up some big yam pile of code, rather
> than any long term goal.
>
> This is probably because producing code pleases you, in and of itself.
> Whereas I usually find it bloody irritating, so I've concentrated on 'why'
> rather than 'Just Do It.'  My evolution is the exact opposite from yours. 
> I
> have mounds and mounds of *notebooks* built up over the years.  Not mounds
> and mounds of code.  I can design things on paper extremely easily.
>
> It's too bad we can't get you more addicted to some game, so that you'd
> become obsessed with some genre, and then have a firm goal for that 
> prolific
> coding output of yours.  As it stands, you're condemned to drift upon the
> waters until you latch on to something that causes you to focus.
>
ok.

hmm, during the time when I was without my computer a few months ago, I came 
up with much of the underlying ideas for pdscript (along with a few other 
things that went nowhere).
so I guess designing stuff is possible, but, I tend not to do it for the 
most part it seems (or at least much more than a few minutes worth).

>> personally I don't know of any languages that fulfill all of this.
>> also, in damn near every language I see things I like and things I
>> don't like, but this is more a "taste" issue.
>
> I was unable to find a language that had it all.  OCaml has most of it.  I
> figure if I get farther and farther into OCaml, eventually I might fix
> whatever's broken about it.  It is open source, after all.
>
ok.

>> actually the main issues I keep seeing are:
>> the use of strange syntax;
>
> OCaml's syntax is baroque, but not as bad as C++.
>
yes, but imo most things that don't look like the c family are arguably 
"strange".
yes, one can alter the syntax pretty signifigantly (eg: to the level of 
javascript or beyond). mine probably pushes things pretty far though, but 
still likely classifies as c-style...

pushing it to the level of a python, pascal, or basic style syntax clearly 
breaks things imo, this is no longer c-style.
whether a pascal or basic style syntax is "oddball" depends on who you ask. 
in my oppinion they are not that stange, but I just don't really like basic 
or pascal style syntax (even though I started out coding largely in basic, 
and later used pascal to a far lesser extent...).

python's syntax is odd though. even though I have not used it much, what I 
have seen looks like an odd combination of things from various languages.

however, all this is in the world of oppinion...

>> bad support for functional programming;
>> bad support for imperative programming;
>
> OCaml supports both just fine.
>
yes, maybe.
then the stance is functional-imperative (eg: a more functional core with 
imperative features) or imperative-functional (an imperative core language 
with features for assisting in fp).

the difference here may be debatable, but in general:
functional-imperative languages tend to have cruddier support of imperative 
coding (eg: assignment or block-structured code is awkward);
imperative-functional languages tend to have cruddier support of functional 
coding (awkward syntax for complex expressions, first class functions, ...).

I leaned more twards crappy fp, though I don't think it has been screwed 
over that badly...

things are still unclear though, oh well.

>> crappy object systems;
>> ...
>
> OCaml is OO.  I doubt it's 'crappy' given all the functional bells and
> whistles at one's disposal, but I don't have experience with it yet either
> so I really can't say.
>
I have no real experience with it, so I can't comment on that.

>> I can't say I do any better, but I like to think so at least, or at
>> least if I don't like something I can fix it...
>
> But the price of "I can fix anything," taken to your extreme limit, is you
> never really get anything done.  You take too many engineering
> responsibilities upon yourself.  Sure you code prolifically, but even the
> most prolific coder can't get anywhere without a good plan.  A good 
> design.
> And good design is *hard*.  There's a reason you're not good at it, it 
> takes
> years to hone good design skills.  So, you're just going to keep running
> into the "too much labor to design" brick wall over and over again, until
> you wise up and realize you don't really want to write everything 
> yourself.
> What you want to do, is write a small chunk of stuff yourself that's core 
> to
> your strategic goal.  "I can fix anything" isn't a strategic goal.  It's 
> an
> undirected dispersal of energy on a perceived, non-critical problem.
>
hrm...
just, if I use existing stuff, given my lack of focus, there is not much for 
me to do (except for maybe gluing things together).

> Software managers talk about "the critical path."  The stuff you 
> absolutely
> need to get done to ship your app.  What's your critical path, cr8?  At
> present, you don't have one.  Nothing's critical, so you have no path.
>
yeah, pretty much.

>>> - A good C Foreign Function Interface is highly preferrable
>> err, nope...
>> I tried writing a tool to generate interfaces via use of c headers at
>> one point (sort of like swig, but I wanted to be able to use any c
>> header...), but gave up eventually as, eg, the cygwin headers tend to
>> involve far too much weird crap and it was getting tiring trying to
>> parse all of it.
>
> I don't know much about language writing, but I've bumped into so many
> people that say this is a difficult problem, due to macro preprocessing 
> and
> whatnot, that I conclude, "That waay thaere bee Dragons."
>
yes, this is probably true.

or you start encountering types like:
__builtin_sint8x8 or whatever (after all the preprocessing is done), which 
would have to be handled specially.
I think the system headers tend not to be intended to be processed by tools.
sad really.

>>> Some language designers are quite imaginative.  Of course, they all
>>> have different foci.  The trick is finding a bunch of language
>>> designers who somewhat share your concerns.  For instance, I don't
>>> like language designers who don't care about performance or C FFIs.
>>>
>> yes, and if their focus does not match mine, then the lang is not very
>> interesting to me... it is hard enough keeping my language
>> interesting to me, but it does have the advantage of being mine.
>
> Yes, but what *is* your focus?  You don't have one!  So nobody can match 
> it.
>
probably.

> At present your lack of focus seems to be:
> - You like C/UNIX style hacking.
> - You like being able to change everything.
> - You pick flavor-of-the-month (week??) problems to work on, so 
> prototyping
> must be important to you.
> - You don't really care about performance, just getting things working.
>
> This puts you in the scripting language camp.  So, what do you think of 
> Lua?
> Or Ruby?
>
lua: looks like pascal, but otherwise seems cool.

ruby: looks strange imo (the string #{whatever} syntax looks cool, but, err, 
similar is possible in my language in a different way).
puts "a #{foo} b #{bar} c #{baz}"
println("a "&foo&" b "&bar&" c "&baz);

I like javascript, but would have to find some free implementation if I 
wanted to use it...


I am not sure why so many scripting langs resemble shell scripts though.
c-syntax would be awkward at a shell, but otherwise I don't get it that 
well...

maybe it is just that I am not that much into shell scripts?...



0
cr88192355 (1928)
8/10/2004 2:16:58 PM
Siegfried Gonzi wrote:

> 
> Is the OCaml FFI itself flawed or is it cumbersome to take workarounds?
> 

The OCaml FFI requires that you understand well C argument passing, memory
management and memory layout of datastructures, things which you don't need
to know when you use the same libraries from C. There is CamlIDL but it's
not as complete as one might want, mainly binding callbacks is not easy.
Haskell suffers of the same problem, and this is the reason why, even if I
am very productive when I code in OCaml (as I suspect everyone is), I am
constrained to C/C++ or java if I want to be sure that I will be able to
interoperate with other languages.

The problem is even more irritating when you want to write a general purpose
library, and you know that if you write it in C, you will be able to call
it from haskell and ocaml, even if it will be difficult, while if you write
that in OCaml or Haskell you won't be able to call it from respectively
Haskell or OCaml. And there are no serious efforts (where serious means:
paid by someone, since an high-level FFI needs expert people which are
already well-paid for their jobs and won't waste their little free time) to
solve this issue. 

When I try to ask about cross-language interoperability solutions for
haskell and ocaml on their mailing lists or here what I get is an
embarassing silence. This might be because I don't know obvious solutions
(in this case please someone tell me) or just because no one is going to
solve the problem, which means that in any serious software project I will
never take the risk of choosing ocaml or haskell, even if they are my
favourite languages, because I will not be able to reuse components written
in these languages if I need to write some part of the software say in
java, or C++, or some .net language.

V.
0
8/10/2004 5:01:01 PM
Philippa Cowderoy wrote:

> 
> 3) Higher-order functions make it easier to build up code at run-time.
> 

3.1 - An example: you have this foreach in C#

foreach (<TYPE> <IDENTIFIER> in <COLLECTION>)
{
  do something with IDENTIFIER
}

can you write a similar construct named map

map (<TYPE> <IDENTIFIER> in <COLLECTION> to <COLLECTION>)
{
  return (something calculated using IDENTIFIER)
}

which collects the return values into a destination collection? No, your
best choice is to use delegates, so that you have to declare a new type for
the delegate, and write a separate function representing the body of the
"map". Compare this with the simplicity of the map operation in OCaml or
Haskell :) And think that you can rewrite map yourself if you like.

V.
0
Vincenzo
8/10/2004 5:11:41 PM
On Tue, 10 Aug 2004 17:01:01 +0000, Vincenzo aka Nick Name wrote:

> The OCaml FFI requires that you understand well C argument passing, memory
> management and memory layout of datastructures, things which you don't need
> to know when you use the same libraries from C. There is CamlIDL but it's
> not as complete as one might want, mainly binding callbacks is not easy.
> Haskell suffers of the same problem,

Haskell has a more convenient FFI than OCaml. In most cases you can avoid
writing a single line of C to access a C library. You need to write manual
wrappers for passing structs by value, and for wrapping function-like macros,
and you can't wrap vararg functions at all due to inherent C limitations.

You don't have to know the layout of C structures nor Haskell objects.
You must know only about the same amount of information as you need to
know anyway to access the library from C, except that you need to know
which functions are in fact macros.

You can wrap Haskell values in opaque C objects. You can allocate raw C
memory from Haskell and put C objects there. You can access C numbers,
enums, strings, structs etc.

You can even convert Haskell function closures to C function pointers
which store the closure inside them, which needs constructing machine code
on the fly, stored in the heap. They should be explicitly freed when no
longer needed.

> The problem is even more irritating when you want to write a general purpose
> library, and you know that if you write it in C, you will be able to call
> it from haskell and ocaml, even if it will be difficult, while if you write
> that in OCaml or Haskell you won't be able to call it from respectively
> Haskell or OCaml.

Indeed.

I'm experimenting with bindings between my pet language Kogut and other
languages.

Python bridge is mostly ready, you can access Python libraries without
wrapping each library separately, and it's quite convenient - values are
converted, wrapped or unwrapped automatically as needed. If someone has
done the trouble of wrapping some C library for Python (e.g. gtk), you can
easily access the library from Kogut. I haven't thought about building
Python modules though.

Perl bridge is being made; most of it is ready. It can't be as convenient
as the Python bridge because of fundamental language differences. For
example you can't reliably find out whether a Perl scalar was meant to be
interpreted as a string or as a number. Another problem is that everything
in Perl is mutable, so automatic conversion of objects from Perl to
another language would lose object identity when it might be important.
So data is not automatically converted from Perl.

I will see what can be done with Haskell and OCaml later. They are a
harder case because they are statically typed, so there must be some glue
code written in them for each library separately.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

0
qrczak (1266)
8/10/2004 5:41:01 PM
In article <2nrmosF3thv2U1@uni-berlin.de>,
 "Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com> 
 wrote:
....
> I was unable to find a language that had it all.  OCaml has most of it.  I
> figure if I get farther and farther into OCaml, eventually I might fix
> whatever's broken about it.  It is open source, after all.
....
> OCaml's syntax is baroque, but not as bad as C++.

It's worse.  C++ may have a lot of keywords and confusing semantics,
but at the basic level of writing out expressions and having what
you wrote turn out to be what you meant, the syntactic structure is
not a big problem.

Objective CAML is probably simpler to parse, if you're a computer,
but its syntax has this stupid problem that I imagine it must have
inherited from ML, that makes structure ambiguous.  E.g. (hope I
remember enough to get away with this),

  match k with
    0) -> Printf "k 0\n"; True
    1) -> Printf "k 1\n"; False

Now, is that the same as

  (
   match k with
    0) -> Printf "k 0\n"; True
    1) -> Printf "k 1\n"; False
        )

or

  (
   match k with
    0) -> Printf "k 0\n"; True
    1) -> Printf "k 1\n"
        );
  False

I don't know.  I would have to write a test program.  I think
it's the first, because I recall that explicit block notation
at the bottom level doesn't change a thing,

    1) -> BEGIN Printf "k 1\n" END;
  False             -- same story, it's really part of 1) -> {}

Not everyone thinks this is a serious problem, maybe only myself,
but I think it's enough to qualify Objective CAML for seriously
broken syntax.

The ocaml compiler is very good as far as I'm concerned, really
emphatically the best by far of any functional language I have
tried to use, so it's too bad Objective CAML is not more appealing.  
I've wondered if there couldn't be some way to build a different
language on ocaml, something like Haskell with a native string
type like Python's (not like Objective CAML) and reactive objects
like O'Haskell.  And useful tracebacks from the top level exception
handler.

   Donn Cave, donn@u.washington.edu
0
Donn
8/10/2004 5:41:53 PM
Donn Cave wrote:
>
>   match k with
>     0) -> Printf "k 0\n"; True
>     1) -> Printf "k 1\n"; False
>
> Now, is that the same as
>
>   (
>    match k with
>     0) -> Printf "k 0\n"; True
>     1) -> Printf "k 1\n"; False
>         )

Sure it is the same. Those parentheses don't eliminate this ambiguity.
You probably meant something like this:

    match k with
     0) -> Printf "k 0\n"; True
     1) -> (Printf "k 1\n"; False)

Anyway, the ambiguity is there, and I have been bitten by it. Luckily,
it was a minor injury :)

Have you tried the revised syntax? It doesn't have such problems.

> The ocaml compiler is very good as far as I'm concerned, really
> emphatically the best by far of any functional language I have
> tried to use, so it's too bad Objective CAML is not more appealing.  

Sometimes I think that it's just because of compromises Ocaml developers
made. I mean the unboxed int hack, imperative strings, imperative
arrays, imperative hashes. If you really want to program in a purely
functional style with it, performance can be less impressive.

> I've wondered if there couldn't be some way to build a different
> language on ocaml, something like Haskell with a native string
> type like Python's (not like Objective CAML)

Adding support for efficient strings to Haskell is quite high on
my wish/TODO list. There is PackedString but it lacks some important
operations, like efficiently reading a line from a Handle directly to a
PackedString.

Best regards,
Tom

-- 
..signature: Too many levels of symbolic links
0
t.zielonka2 (138)
8/10/2004 7:51:46 PM
["Followup-To:" header set to comp.lang.functional.]
chris wrote:
> I don't understand what the problem is so i can't comment on it, but the 
> fact integers are 31 bit integers  because of the design of the 
> implementation isn't particuarly nice.  It's better imo not to let 
> implementation issues pollute the language as much as possible.
>
> The people behind O'Caml did it for a reason, although it's not clear to 
> me what the reason was.

I think it was efficiency and simplicity of implementation. I don't like
the result.

Best regards,
Tom

-- 
..signature: Too many levels of symbolic links
0
t.zielonka2 (138)
8/10/2004 7:55:38 PM
Followup-To: comp.lang.functional

On Tue, 10 Aug 2004 20:17:26 +0000, chris wrote:

> I don't understand what the problem is so i can't comment on it, but the 
> fact integers are 31 bit integers  because of the design of the 
> implementation isn't particuarly nice.  It's better imo not to let 
> implementation issues pollute the language as much as possible.

A reasonable idea is to represent small integers in 31 bits, larger
integers as bignums, and do this transparently to the user. This is what
various implementations of Lisp and Scheme do.

Glasgow Haskell also uses two internal representations of type Integer,
but the small case, and the type Int as a whole, use full machine word.
It's a full word because in the general case the int must be boxed anyway
(because of laziness). The compiler makes a sophisticated analysis which
allows it to be often unboxed.

Such analysis would probably be a bad tradeoff for OCaml, because it would
introduce some boxing and unboxing which is less efficient than using the
invariant representation of tagged ints directly, would introduce much
complication for internals of the compiler and runtime, and there are no
other reasons than interfacing to some libraries to make ints 32 bits
instead of 31 bits.

> The people behind O'Caml did it for a reason, although it's not clear to 
> me what the reason was.

For performance.

31-bit ints are faster than a hybrid of 31-ints and bignums, especially
if they ignore overflow like in OCaml (as opposed to SML).

They are also faster than 32-bit ints in a language with parametric
polymorphism, unless the compiler performs sophisticated analysis and/or
give up some language properties to compile polymorphic code separately
for different types, like C++ and new C# do. C++ gives up separate
compilation of templates, and C# relies on generating code at runtime.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

0
qrczak (1266)
8/10/2004 7:56:41 PM
Donn Cave wrote:

> I don't know.  I would have to write a test program.  I think
> it's the first, because I recall that explicit block notation
> at the bottom level doesn't change a thing,

I tried the second one and it was incorrectly typed, so it may be the 
first (below).

# let _ =
   let k = 0 in
   let x =
     (
       match k with
	 0 -> (); true
        | 1 -> (); false
     )
   in x;;
                 Characters 38-105:
Warning: this pattern-matching is not exhaustive.
Here is an example of a value that is not matched:
2
   ....(
         match k with
   	 0 -> (); true
          | 1 -> (); false
       )
- : bool = true


>     1) -> BEGIN Printf "k 1\n" END;
>   False             -- same story, it's really part of 1) -> {}

I don't really understand the problem.  Is the problem that (a; b) is 
equivalent to a; b?  Or that begin ... end is not of type unit?  Or that 
in a; b, the type of a and the type of b need not be the same?


> Not everyone thinks this is a serious problem, maybe only myself,
> but I think it's enough to qualify Objective CAML for seriously
> broken syntax.

I don't understand what the problem is so i can't comment on it, but the 
fact integers are 31 bit integers  because of the design of the 
implementation isn't particuarly nice.  It's better imo not to let 
implementation issues pollute the language as much as possible.

The people behind O'Caml did it for a reason, although it's not clear to 
me what the reason was.


Chris
0
spamoff.danx (197)
8/10/2004 8:17:26 PM
Vincenzo aka Nick Name wrote:
>
> When I try to ask about cross-language interoperability solutions for
> haskell and ocaml on their mailing lists or here what I get is an
> embarassing silence.

Jeff Henrikson has made a stab at the problem with his Forklift project.
http://www.jhenrikson.org/forklift/  I'm in regular contact with him here in
Seattle.  He's still interested in the problem, but as you said he's only
one guy.  Maybe you could pool resources with him.  I'm somewhat interested
in the problem myself, but still far from having the OCaml skills needed to
pull such a thing off.

Designing in terms of Bigarray is more practical for me at the moment.  I'm
hoping to create a layer of syntactic sugar that would allow for C
structures composed of uniformly sized and typed elements, and treated as
structures from OCaml.  For instance, all 32-bit ints for some low level
game map primitive, or all 32-bit floats for 3D graphics vertices.

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

"We live in a world of very bright people building
crappy software with total shit for tools and process."
                                - Ed Mckenzie

0
8/10/2004 8:33:44 PM
Gerry Quinn wrote:
> In article <2npsk1F3gnj8U1@uni-berlin.de>,
> try_vanevery_at_mycompanyname@yahoo.com says...
>> Gerry Quinn wrote:
>>>
>>> Of course, shortest path algorithms [or maybe for this example,
>>> influence map algorithms] are trivial, but once you have them you
>>> can start working on the trickier GetSafeLocation() functions.  At
>>> that  point you'll be into real AI...
>>
>> Not really.  It's just more map crunching.  It all depends on what
>> is meant by 'real' here.  I did say we should embrace our inner
>> cockroach.  "We're all just crunching."
>
> It's not obvious to me how to define a safe location, or that such a
> definition is even possible.  What is safe depends on a lot of
> circumstances.  It's a fuzzy problem, whereas a shortest path analysis
> just involves plugging in a standard algorithm.

Having more constraints, and not being completely solveable, doesn't make it
any more than a number crunching problem.  From a goal oriented standpoint,
all that really matters is that it's computed to be "safe enough to win the
game."  And if that doesn't pan out in practice, it just has to be "safe
enough to have seemingly put up a good fight."  Look at a real war.  You
know the joke about Military Intelligence, right?

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

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

0
Brandon
8/10/2004 8:41:58 PM
Gerry Quinn wrote:
>
> Doesn't this go back to a comment you made earlier, though - the
> things computer languages express are not the same as the things we
> want to express?
>
> At some stage you're going to be writing a function that in C++ might
> look like:
>
> Map::GetShortestPath( const Location & startLoc, const Location &
> endLoc, vector< Location > & path )
>
> And in C++ or Ocaml, it's going to have a similar I/O format, and be
> algorithmically similar under the hood.

But in C++ I'd have to deal with garbage collection myself, lists are a
tacky STL thing, functions are not easily composed, it's not type safe, and
I'd have to type 'int' all the time.  Even if OCaml isn't my ideal domain
specific language, it has built in tools that are more convenient than C++
is, without sacrificing much performance.  I do think OCaml is going to be
useful for the higher level aspects of the problem.  In particular, there
will probably come a point at which I'm barfing out ad hoc AI heuristic
code, rather than any well-defined low-level algorithm.  OCaml is better set
up to handle those kinds of problems than C++ is.

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

"We live in a world of very bright people building
crappy software with total shit for tools and process."
                                - Ed Mckenzie


0
8/10/2004 8:47:28 PM
In article <slrnchi9qc.asb.t.zielonka@zodiac.mimuw.edu.pl>,
 Tomasz Zielonka <t.zielonka@zodiac.mimuw.edu.pl> wrote:
> Donn Cave wrote:
> >
> >   match k with
> >     0) -> Printf "k 0\n"; True
> >     1) -> Printf "k 1\n"; False
> >
> > Now, is that the same as
> >
> >   (
> >    match k with
> >     0) -> Printf "k 0\n"; True
> >     1) -> Printf "k 1\n"; False
> >         )
> 
> Sure it is the same. Those parentheses don't eliminate this ambiguity.
> You probably meant something like this:
> 
>     match k with
>      0) -> Printf "k 0\n"; True
>      1) -> (Printf "k 1\n"; False)

Yes, thank you, that's right.

> Anyway, the ambiguity is there, and I have been bitten by it. Luckily,
> it was a minor injury :)
> 
> Have you tried the revised syntax? It doesn't have such problems.

Not sure I ever heard of it.  Does it look like Haskell?
That would be nice.

> > The ocaml compiler is very good as far as I'm concerned, really
> > emphatically the best by far of any functional language I have
> > tried to use, so it's too bad Objective CAML is not more appealing.  
> 
> Sometimes I think that it's just because of compromises Ocaml developers
> made. I mean the unboxed int hack, imperative strings, imperative
> arrays, imperative hashes. If you really want to program in a purely
> functional style with it, performance can be less impressive.

Actually I don't care much about the fabulous shootout
scores and that kind of thing.  The first thing on the list
of priorities is simply to be able to get the compiler to work.
So far, I have been able to port ocaml to whatever platform
I wanted, including native thread support.  I consider that
a major feat of engineering on their part, particularly compared
to the compilers available for Haskell.  I can't port them, so
I can't use them, hence ocaml compares favorably.

Pure functional is a head scratcher for me, appealing in principle
at least -- but from what I can tell it isn't why people use
Objective CAML.  Are you saying that pure functional ocaml
is worse in terms of performance than imperative ocaml, or is
it (also) possibly worse than ghc?

> > I've wondered if there couldn't be some way to build a different
> > language on ocaml, something like Haskell with a native string
> > type like Python's (not like Objective CAML)
> 
> Adding support for efficient strings to Haskell is quite high on
> my wish/TODO list. There is PackedString but it lacks some important
> operations, like efficiently reading a line from a Handle directly to a
> PackedString.

Yes, I can see how that might be useful.

   Donn Cave, donn@u.washington.edu
0
Donn
8/10/2004 8:59:50 PM
cr88192 wrote:
>
> ok.
> the bsd liscence is pretty cool imo...
> similar would likely go for the mit liscence.
>
> in your oppinion, how does lgpl compare?

The difficulty with the LGPL is that in commercial practice, you must
provide your library as a dynamic link library to comply with the license.
You can't, for instance, just compile the library statically into your code.
I find this to be an annoying futz factor, and in some commercial contexts
the restriction would be unacceptable.  Of course that's the LGPL's point,
it wants to make certain things unacceptable to commercial development.
LGPL prioritizes the right of some geek to fiddle with the library as he
sees fit.

MIT / BSD doesn't prioritize anybody.  You can do whatever you want with the
code.  Nothing is in the way.  I figure, if you're going to give something
away, give it away completely.  If it's too valuable to give away
completely, don't!  Keep that chunk proprietary.

> hmm, during the time when I was without my computer a few months ago,
> I came up with much of the underlying ideas for pdscript (along with
> a few other things that went nowhere).
> so I guess designing stuff is possible, but, I tend not to do it for
> the most part it seems (or at least much more than a few minutes
> worth).

Probably because you don't enjoy it so much compared to programming and
aren't so good at it.  So, you stick with what you like.  This is going to
limit you, until you decide that you need to tackle certain problems with
discipline and resolve, rather than simply what you like.

>> OCaml's syntax is baroque, but not as bad as C++.
>>
> yes, but imo most things that don't look like the c family are
> arguably "strange".

So what?  That's called learning something new.  In computers you have to do
it all the time, one way or another.  I don't believe in learning
everything, I do believe we should make strategic choices about what we're
going to bother to learn.  But I don't buy this "eew it's strange" attitude
for its own sake.  Everything new is strange.

> pushing it to the level of a python, pascal, or basic style syntax
> clearly breaks things imo, this is no longer c-style.

There's nothing precious about C style.  I see no a priori reason to prefer
C style over some other style.  In fact, as languages have evolved I can see
various reasons for getting away from C style.  The main reasons to retain C
style are language bridging and low level hardware access.

Also, I don't see the big deal about learning a new language style, in and
of itself.  I've got a big brain, I'm smart, I'm a capable computer guy.  I
wouldn't wuss out about any other kind of algorithmic problem, why would I
wuss out about learning a new style?  Be a real man and learn some different
style other than this C stuff.

Granted, for any given language, that's a time investment.  I don't believe
in learning all languages.  Rather, I've identified what I'm trying to do
(3D graphics and AI).  So I've looked at the languages that seem most
applicable to what I'm trying to do.  For now that seems to be OCaml, so
that's where I focus my attention.

>>> bad support for functional programming;
>>> bad support for imperative programming;
>>
>> OCaml supports both just fine.
>>
> yes, maybe.
> then the stance is functional-imperative (eg: a more functional core
> with imperative features) or imperative-functional (an imperative
> core language with features for assisting in fp).

OCaml is functional-imperative, per your terms.

>> But the price of "I can fix anything," taken to your extreme limit,
>> is you never really get anything done.  You take too many engineering
>> responsibilities upon yourself.  Sure you code prolifically, but
>> even the most prolific coder can't get anywhere without a good plan.
>> A good design.
>> And good design is *hard*.  There's a reason you're not good at it,
>> it takes
>> years to hone good design skills.  So, you're just going to keep
>> running into the "too much labor to design" brick wall over and over
>> again, until you wise up and realize you don't really want to write
>> everything yourself.
>> What you want to do, is write a small chunk of stuff yourself that's
>> core to
>> your strategic goal.  "I can fix anything" isn't a strategic goal.
>> It's an
>> undirected dispersal of energy on a perceived, non-critical problem.
>>
> hrm...
> just, if I use existing stuff, given my lack of focus, there is not
> much for me to do (except for maybe gluing things together).

SO GET A FOCUS!!!  Geez!!  Hit the nail on the head dude.

>> At present your lack of focus seems to be:
>> - You like C/UNIX style hacking.
>> - You like being able to change everything.
>> - You pick flavor-of-the-month (week??) problems to work on, so
>> prototyping
>> must be important to you.
>> - You don't really care about performance, just getting things
>> working.
>>
>> This puts you in the scripting language camp.  So, what do you think
>> of Lua?
>> Or Ruby?
>>
> lua: looks like pascal, but otherwise seems cool.

Ok, so try writing something in lua.  Lua was also designed to be extended
by guys like you, so try extending it somehow.

> I am not sure why so many scripting langs resemble shell scripts
> though. c-syntax would be awkward at a shell, but otherwise I don't
> get it that well...

It's historical.  The people interested in scripting languages have
typically been the ones who learned shell languages.  Python is the opposite
taste from this.  It can do all the scripting jobs, it's quite commercially
proven in that arena, and it is utterly un-Perl-like.  As far as syntactic
taste goes, you're either a Python guy or a Perl guy.  FWIW I'm a Python
guy, in the aesthetic sense.

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

"We live in a world of very bright people building
crappy software with total shit for tools and process."
                                - Ed Mckenzie

0
8/10/2004 9:06:30 PM
Donn Cave wrote:
> In article <2nrmosF3thv2U1@uni-berlin.de>,
>  "Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com>
>  wrote:
> ...
>> I was unable to find a language that had it all.  OCaml has most of
>> it.  I figure if I get farther and farther into OCaml, eventually I
>> might fix whatever's broken about it.  It is open source, after all.
> ...
>> OCaml's syntax is baroque, but not as bad as C++.
>
> It's worse.  C++ may have a lot of keywords and confusing semantics,
> but at the basic level of writing out expressions and having what
> you wrote turn out to be what you meant, the syntactic structure is
> not a big problem.

How many multiply inherited virtual base classes with pointers have you
done?  You're right that C++ has the readability advantage for small code
blocks, but once you scale up, all of C++'s picky problems rear their ugly
hydra heads!

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

"We live in a world of very bright people building
crappy software with total shit for tools and process."
                                - Ed Mckenzie

0
8/10/2004 9:10:17 PM
On Tue, 10 Aug 2004 13:59:50 -0700, Donn Cave wrote:

>> Have you tried the revised syntax? It doesn't have such problems.
> 
> Not sure I ever heard of it.  Does it look like Haskell?

Not quite (but a bit closer to Haskell than the traditional syntax).

http://caml.inria.fr/camlp4/tutorial/tutorial005.html

It's more consistent, less "ambiguous", at the cost of being more verbose.
In particular it uses more brackets.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

0
qrczak (1266)
8/10/2004 9:10:28 PM
chris wrote:
>
> I don't understand what the problem is so i can't comment on it, but
> the fact integers are 31 bit integers  because of the design of the
> implementation isn't particuarly nice.  It's better imo not to let
> implementation issues pollute the language as much as possible.
>
> The people behind O'Caml did it for a reason, although it's not clear
> to me what the reason was.

The reason they did it is because back in the day, the GC was marching over
huge arrays of ints all the time, screwing around with whether things needed
to be allocated or deallocated or not.  Even though one would think that in
theory, a GC should be designed so that big chunks of memory wouldn't have
to be naively walked over, apparently they were.  I haven't studied GC
design much, but I'm sure other strategies are taken nowadays.

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

"We live in a world of very bright people building
crappy software with total shit for tools and process."
                                - Ed Mckenzie

0
8/10/2004 9:13:56 PM
Philippa Cowderoy wrote:

> On Tue, 10 Aug 2004, Peter Ashford wrote:
> 
> 
>>In what way does OCaml eclipse that kind of tool creation ability that
>>you get from OO languages?
>>
> 
> 
> I'll answer for Haskell, as I don't use ML much, but some of the points
> still stand:
> 
> 1) There are excellent parsing tools available - in particular, this seems
> to be where Spirit got its inspiration from
> 
> 2) The pattern-matching facilities, which operate on any data type. They
> make mildly complicated transformations on trees and graphs an absolute
> doddle.

Okay, that'll explain the language creation benefits that Brandon was 
talking about,

> 3) Higher-order functions make it easier to build up code at run-time.
> 
> 4) Techniques such as monads and monad transformers make it even easier -
> you can build the semantics of your DSL piece-by-piece.

Could you give an example?

> 5) The type systems are more suited to this kind of work.
> 

I really must get around to playing more with OCaml.  I really love LISP 
but that's as far as I've ever gone with Functional Languages (except 
for dabbling briefly with Erlang) and I have to say the 'hard core' 
functional languages freak me out somewhat :o)  I just don't get them. 
Which is all the more reason to put the effort in a learn one properly :o)
0
Peter
8/10/2004 9:23:24 PM
> 
> Well, maybe both C++ and Ocaml have this property.  My own view is that 
> designing and programming games is hard, and so long as your language is 
> powerful, scales well, and is not too awful, it's not the problem.  Of 
> course you think C++ is too awful - I'm happy to stick with it.

That's my point of view as well (of course, insert Java for C++ :o) )

I don't often find myself with programming issues which I can figure out 
how fix but can't really express cleanly with the language I'm using.  I 
suppose that's part of the reason I'm a little dubious about the 
advantages of using a functional language.

<uninformed opinion>
FL's seem to have lots of benefits that seem very high level and obscure 
whereas the problems I end up solving usually don't seem to require 
especially complex or unusal programming approaches to defeat.  The real 
work is figuring out what I want to do and a good algorithm to do it 
rather than wrangling with the language.
</uninformed opinion>
0
Peter
8/10/2004 9:33:05 PM
Brandon J. Van Every on Tue, 10 Aug 2004 14:06:30 -0700 writes:

> cr88192 wrote:
>>
>> ok.
>> the bsd liscence is pretty cool imo...
>> similar would likely go for the mit liscence.
>>
>> in your oppinion, how does lgpl compare?
>
> The difficulty with the LGPL is that in commercial practice, you must
> provide your library as a dynamic link library to comply with the license.
> You can't, for instance, just compile the library statically into your code.
> I find this to be an annoying futz factor, and in some commercial contexts
> the restriction would be unacceptable.  Of course that's the LGPL's point,
> it wants to make certain things unacceptable to commercial development.
> LGPL prioritizes the right of some geek to fiddle with the library as he
> sees fit.

That's not correct.

You _can_ statically link proprietary code with LGPL licensed code,
for example by providing the (linkable) object file(s) for the
proprietary code.

This is to allow the use of newer versions of the LGPL library
(perhaps containing bug-fixes, improvements, etc...).

From the LGPL [1], "Preable":

<< ...

   When a program is linked with a library, whether statically or
   using a shared library, the combination of the two is legally
   speaking a combined work, a derivative of the original library. The
   ordinary General Public License therefore permits such linking only
   if the entire combination fits its criteria of freedom. The Lesser
   General Public License permits more lax criteria for linking other
   code with the library.

   ... >>

  1. http://www.gnu.org/licenses/lgpl.html

Now, "TERMS AND CONDITIONS ...", section 6a and section 6c:

<< ...  Also, you must do one of these things:

    * a) Accompany the work with the complete corresponding
      machine-readable source code for the Library including whatever
      changes were used in the work (which must be distributed under
      Sections 1 and 2 above); and, if the work is an executable
      linked with the Library, with the complete machine-readable
      "work that uses the Library", as object code and/or source code,
      so that the user can modify the Library and then relink to
      produce a modified executable containing the modified
      Library. (It is understood that the user who changes the
      contents of definitions files in the Library will not
      necessarily be able to recompile the application to use the
      modified definitions.)

   ...

      c) Accompany the work with a written offer, valid for at least
      three years, to give the same user the materials specified in
      Subsection 6a, above, for a charge no more than the cost of
      performing this distribution.

   ...>>

> MIT / BSD doesn't prioritize anybody.  You can do whatever you want with the
> code.  Nothing is in the way.  I figure, if you're going to give something
> away, give it away completely.  If it's too valuable to give away
> completely, don't!  Keep that chunk proprietary.

Yeah, BSD-like licenses shares with everyone, GPL shares only with who
share, the LGPL shares with everyone, but less than the BSD-alikes.

Some peoples refer to BSD-like licenses as permissive licenses, and to
GPL and LGPL licenses as copyleft licenses.

Some text about Copyleft:

  2. http://www.gnu.org/licenses/licenses.html#WhatIsCopyleft

  3. http://www.gnu.org/philosophy/why-copyleft.html

  4. http://www.gnu.org/philosophy/pragmatic.html

-- 
Marco Parrone <marc0@autistici.org> [0x45070AD6]
0
marc0 (56)
8/10/2004 9:39:14 PM
On Tue, 10 Aug 2004 10:41:53 -0700, Donn Cave wrote:

>> OCaml's syntax is baroque, but not as bad as C++.
> 
> It's worse.  C++ may have a lot of keywords and confusing semantics,
> but at the basic level of writing out expressions and having what
> you wrote turn out to be what you meant, the syntactic structure is
> not a big problem.

I know no language which is harder to parse than C++.

It has all phases of compiler frontend entangled. In most languages after
parsing comes name resolution, then typechecking if the language is
statically typed, then optimizations.

But in C++ the result of constant expressions may influence template
specializations, which influence types, which influence name lookup,
which influence parsing of declarations. Of course forward dependencies
between these phases are still there, so all those phases must be
interleaved, together with template instantiation.

This implies that it's impossible to write an accurate parser of C++ which
e.g. is able to see which names are declared in a particular declaration,
without doing a complete typechecking, Koenig lookup, resolving inherited
names, function template argument deduction, user type conversions, and
constant folding of integer expressions.

A silly example:

template<bool> struct A {};
template<> struct A<true>  {static  int x;};
template<> struct A<false> {typedef int x;};
int p, x;
void f() {
   A<sizeof(int)<4>::x * p;
   // Whether the above line uses the global p, or declares a local p
   // as a pointer, depends on the size of int.
}

BTW, the line
   A<sizeof(int)<4>::x * p;
would have a completely different meaning if A were an int variable
rather than a class template. It would compare A with sizeof(int),
compare the result with 4, and compare the result with the value of
global x multiplied by p.

Beware of cases like this:
   template <class T>
   void f() {
      T::A<sizeof(int)<4>::x *p;
   }
This does not define p as a pointer even if A is a template inside every
class T this function is instantiated for. It does the comparison version,
because C++ wants to parse a template without yet knowing what T will
contain, and it assumes the "it's not a type and not a template" version.
This must be written thus instead:
   template <class T>
   void f() {
      typename T::template A<sizeof(int)<4>::x *p;
   }

Be sure to insert "typename" and "template" disambiguation markers only in
templates. Outside templates this kind of ambiguity can't happen and C++
doesn't *allow* to add these disambiguation markers there.

So much for C++ grammar simplicity.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

0
qrczak (1266)
8/10/2004 9:44:58 PM
Brandon J. Van Every wrote:

> I'm�in�regular�contact�with�him�here�in
> Seattle.��He's�still�interested�in�the�problem,�but�as�you�said�he's�only
> one guy.��Maybe�you�could�pool�resources�with�him

As I said, the main problem is that no one is being paid for this, while
there are infinitely many paid research projects on high level languages,
and infinitely many researchers that worked on interoperability at least
when microsoft was desigining .net. I code 8 hours per day, and by night
guess what... I code for my own free software project. Even if I were paid
to work on forklift I wouldn't do such a good job because you need a real
expert in programming languages semantics to design a similar thing.

It's crazy and I am not sure how to justify this :) My project is in C++
(and sometimes segfaults) for the exact reasons I mentioned earlier.

I am pretty sure that, if I will become a computer science researcher again
after the short and wonderful parenthesis of my master thesis I will do
everything in my possibilities to work on cross-language interoperability.
But I don't expect a single man, in his free time, to be able to do this
thing, not better than .net at least. My hope is that with .net evolution,
generics and so on, someone will manage to create a true backend for
haskell, ocaml and other functional languages, where "true" means that you
can pass an ocaml function where C# expects a delegate and the converse.

Bye

Vincenzo
0
8/10/2004 10:13:21 PM
Marcin 'Qrczak' Kowalczyk wrote:

> 
> I'm experimenting with bindings between my pet language Kogut and other
> languages.

But what is this language designed for? Have you got documentation?

bye

Vincenzo
0
8/10/2004 10:14:39 PM
In article <pan.2004.08.10.21.10.28.351484@knm.org.pl>,
 Marcin 'Qrczak' Kowalczyk <qrczak@knm.org.pl> wrote:

> On Tue, 10 Aug 2004 13:59:50 -0700, Donn Cave wrote:
> 
> >> Have you tried the revised syntax? It doesn't have such problems.
> > 
> > Not sure I ever heard of it.  Does it look like Haskell?
> 
> Not quite (but a bit closer to Haskell than the traditional syntax).
> 
> http://caml.inria.fr/camlp4/tutorial/tutorial005.html
> 
> It's more consistent, less "ambiguous", at the cost of being more verbose.
> In particular it uses more brackets.

Yes, that's a lot better.  I don't think it's really conspicuously more
verbose, and it is clearer, so that's a big help.  The only thing that
seems awkward at first glance is the brackets for "match", but
I don't have any alternative idea to propose (other than Haskell
style layout.)

thanks,

   Donn Cave, donn@u.washington.edu
0
Donn
8/10/2004 11:48:26 PM
On Wed, 11 Aug 2004, Peter Ashford wrote:

> Philippa Cowderoy wrote:
> > 3) Higher-order functions make it easier to build up code at run-time.
> >
> > 4) Techniques such as monads and monad transformers make it even easier -
> > you can build the semantics of your DSL piece-by-piece.
>
> Could you give an example?
>

A fun one's the List monad - it represents computations that can return
zero or more results, instead of functions that always return one
result[1]. Makes it easy to write code that maintains a list of
possibilities and filters them down, for example - but more interestingly,
if you only want one result then under lazy evaluation it's equivalent to
backtracking.

Supposing you want to bolt exceptions on top of this, you could apply the
ErrorT monad transformer to it. Alternatively, you could apply a ListT
transformer to the Error monad - these produce two different results.
ErrorT on top of List yields a semantics where an exception appears within
the list of possible results and can be caught appropriately, whereas
ListT on top of Error produces a system where an exception stops the whole
computation.

Prolog, anyone?

> > 5) The type systems are more suited to this kind of work.
> >
>
> I really must get around to playing more with OCaml.  I really love LISP
> but that's as far as I've ever gone with Functional Languages (except
> for dabbling briefly with Erlang) and I have to say the 'hard core'
> functional languages freak me out somewhat :o)  I just don't get them.
> Which is all the more reason to put the effort in a learn one properly :o)
>

Any idea what bugs you? It's a bit weird working without state at first,
certainly. Well, until you find all the tricks for providing state when
you really really need it (gee, I'm talking a stateful protocol over the
network here...).

If you decide to learn Haskell, you might find these two links useful:
http://www.haskell.org/tutorial/ (general tutorial)
http://www.nomaware.com/monads/html/ (a decent tutorial on monads)

I'm afraid somebody else'll have to provide equivalent links for OCaml,
I've not really used it any.

[1] Monads effectively provide means to embed a semantics that's
higher-order[2] into Haskell, and Haskell within that semantics. There's
an Identity monad that represents Haskell semantics on top of which you can
apply monad transformers, for example. A more generic framework called
Arrows relaxes the higher-order restriction.

[2] By which I mean that computations can take computations as
parameters and return computations as results - if there's an existing
use of the term that differs from this, could somebody enlighten me
btw? - this has a consequence, which is that any data the monad keeps
(state being the classical example) won't branch any - this allows the IO
monad to represent a function of type world->world without ever trying to
duplicate the world, thus allowing a pure (if not complete) language to
express interaction with the outside world without giving too many
physicists big headaches.

-- 
flippa@flippac.org
0
Philippa
8/10/2004 11:59:24 PM
In article <2nsr9uF4dvqjU1@uni-berlin.de>,
 "Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com> 
 wrote:

> Donn Cave wrote:
> > In article <2nrmosF3thv2U1@uni-berlin.de>,
> >  "Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com>
> >  wrote:
> > ...
> >> I was unable to find a language that had it all.  OCaml has most of
> >> it.  I figure if I get farther and farther into OCaml, eventually I
> >> might fix whatever's broken about it.  It is open source, after all.
> > ...
> >> OCaml's syntax is baroque, but not as bad as C++.
> >
> > It's worse.  C++ may have a lot of keywords and confusing semantics,
> > but at the basic level of writing out expressions and having what
> > you wrote turn out to be what you meant, the syntactic structure is
> > not a big problem.
> 
> How many multiply inherited virtual base classes with pointers have you
> done?  You're right that C++ has the readability advantage for small code
> blocks, but once you scale up, all of C++'s picky problems rear their ugly
> hydra heads!

I believe that we agree to some extent about the problems
with C++, and differ only over whether they should be
called "syntax" or not.  Suit yourself, but for discussion
that focuses on C++ issues you should probably omit
comp.lang.functional.

   Donn Cave, donn@u.washington.edu
0
Donn
8/11/2004 12:03:54 AM
In article <donn-07FA85.17035410082004@gnus01.u.washington.edu>,
Donn Cave  <donn@u.washington.edu> wrote:
>I believe that we agree to some extent about the problems with C++,
>and differ only over whether they should be called "syntax" or not.
>Suit yourself, but for discussion that focuses on C++ issues you
>should probably omit comp.lang.functional.

   Sorry, Brandon Van Every is a bit of a troll on the games
development newsgroups. Despite never completing any projects-- and it
seems that he's never written a line of OCaml code if I read this
thread correctly-- he'll start up big inflamatory topics.  After
painting himself into a corner, he'll refuse to get out, and
eventually unsubscribe when it's been clear for weeks that his
positions are logically untenable.  There's a 5+ year history of him
doing this if you care to look up google groups or the like. 

   The past year or so, he's been a "language dilettante" -- picking a
pet language for a bit, promoting it while never using it, and moving
on after some months. Please feel free to redirect any of his threads
out of your newsgroups.

Nathan Mates
--
<*> Nathan Mates - personal webpage http://www.visi.com/~nathan/  
# Programmer at Pandemic Studios -- http://www.pandemicstudios.com/
# NOT speaking for Pandemic Studios. "Care not what the neighbors
# think. What are the facts, and to how many decimal places?" -R.A. Heinlein
0
nathan43 (53)
8/11/2004 1:00:32 AM
"Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com> wrote in 
message news:2nsr2rF4f945U1@uni-berlin.de...
> cr88192 wrote:
>>
>> ok.
>> the bsd liscence is pretty cool imo...
>> similar would likely go for the mit liscence.
>>
>> in your oppinion, how does lgpl compare?
>
> The difficulty with the LGPL is that in commercial practice, you must
> provide your library as a dynamic link library to comply with the license.
> You can't, for instance, just compile the library statically into your 
> code.
> I find this to be an annoying futz factor, and in some commercial contexts
> the restriction would be unacceptable.  Of course that's the LGPL's point,
> it wants to make certain things unacceptable to commercial development.
> LGPL prioritizes the right of some geek to fiddle with the library as he
> sees fit.
>
ok.

> MIT / BSD doesn't prioritize anybody.  You can do whatever you want with 
> the
> code.  Nothing is in the way.  I figure, if you're going to give something
> away, give it away completely.  If it's too valuable to give away
> completely, don't!  Keep that chunk proprietary.
>
ok.

>> hmm, during the time when I was without my computer a few months ago,
>> I came up with much of the underlying ideas for pdscript (along with
>> a few other things that went nowhere).
>> so I guess designing stuff is possible, but, I tend not to do it for
>> the most part it seems (or at least much more than a few minutes
>> worth).
>
> Probably because you don't enjoy it so much compared to programming and
> aren't so good at it.  So, you stick with what you like.  This is going to
> limit you, until you decide that you need to tackle certain problems with
> discipline and resolve, rather than simply what you like.
>
ok.

>>> OCaml's syntax is baroque, but not as bad as C++.
>>>
>> yes, but imo most things that don't look like the c family are
>> arguably "strange".
>
> So what?  That's called learning something new.  In computers you have to 
> do
> it all the time, one way or another.  I don't believe in learning
> everything, I do believe we should make strategic choices about what we're
> going to bother to learn.  But I don't buy this "eew it's strange" 
> attitude
> for its own sake.  Everything new is strange.
>
but things that are stange can scare off newbies.
c syntax scares off vb programmers, but at least most others wont be scared 
off so easily as likely they are more fammiliar with it.

>> pushing it to the level of a python, pascal, or basic style syntax
>> clearly breaks things imo, this is no longer c-style.
>
> There's nothing precious about C style.  I see no a priori reason to 
> prefer
> C style over some other style.  In fact, as languages have evolved I can 
> see
> various reasons for getting away from C style.  The main reasons to retain 
> C
> style are language bridging and low level hardware access.
>
but it is mainstream.
c and c++ comprise most of the software in existance.
c# and java fall way behind, but are still not exactly that small (compared 
with most other languages).

I had found it quite annoying that most people I encountered irl, if they 
knew any programming, could not understand fragments from my previous langs.

there are lots of people that take classes to try to learn java;
javascript is commonly enough at least lightly handled in web-development 
classes;
vb is common in introductory classes.

most things had seemed to point in a single direction.

I had then decided:
I am largely going to stick to c-style syntax;
failing that, I will rip off bits of vb style syntax (as at least it is 
common).

it is difficult to avoid drifting too far from the c realm sometimes...

I compare it to the linux and wondows issue:
linux is sufficiently unlike windows (even though lots of effort is put into 
cloning it), that many windows users get disorientated and feel hopeless 
when faced with linux (or mac for that matter, eg, "what is this menu bar at 
the top of the screen? oh, how do I operate these apps?!...").
I will argue that most programmers are largely the same way.

it doesn't matter so much what I am willing to do, but more what I can get 
others to be willing to do...

> Also, I don't see the big deal about learning a new language style, in and
> of itself.  I've got a big brain, I'm smart, I'm a capable computer guy. 
> I
> wouldn't wuss out about any other kind of algorithmic problem, why would I
> wuss out about learning a new style?  Be a real man and learn some 
> different
> style other than this C stuff.
>
hmm...

err, annoyingly I have come up with something that could allow really cool 
features (eg: the ability to handle relational db type stuff in the core 
language), but it will likely look quite strange.

db[owner:="Bob", cost:<10000]

managing things like this could be an issue though, since with types like 
this there is no longer really a 1d index space for such types.
but it just seemed too cool to not implement.

> Granted, for any given language, that's a time investment.  I don't 
> believe
> in learning all languages.  Rather, I've identified what I'm trying to do
> (3D graphics and AI).  So I've looked at the languages that seem most
> applicable to what I'm trying to do.  For now that seems to be OCaml, so
> that's where I focus my attention.
>
yes.
this may be a bias driven largely by my lang design instincts.

I will use other languages sometimes (eg: I still do some scheme coding 
every so often, and I do write shell scripts), but I will be reluctant to 
really support langs that use unusual syntax.

>>>> bad support for functional programming;
>>>> bad support for imperative programming;
>>>
>>> OCaml supports both just fine.
>>>
>> yes, maybe.
>> then the stance is functional-imperative (eg: a more functional core
>> with imperative features) or imperative-functional (an imperative
>> core language with features for assisting in fp).
>
> OCaml is functional-imperative, per your terms.
>
yes.

>>> But the price of "I can fix anything," taken to your extreme limit,
>>> is you never really get anything done.  You take too many engineering
>>> responsibilities upon yourself.  Sure you code prolifically, but
>>> even the most prolific coder can't get anywhere without a good plan.
>>> A good design.
>>> And good design is *hard*.  There's a reason you're not good at it,
>>> it takes
>>> years to hone good design skills.  So, you're just going to keep
>>> running into the "too much labor to design" brick wall over and over
>>> again, until you wise up and realize you don't really want to write
>>> everything yourself.
>>> What you want to do, is write a small chunk of stuff yourself that's
>>> core to
>>> your strategic goal.  "I can fix anything" isn't a strategic goal.
>>> It's an
>>> undirected dispersal of energy on a perceived, non-critical problem.
>>>
>> hrm...
>> just, if I use existing stuff, given my lack of focus, there is not
>> much for me to do (except for maybe gluing things together).
>
> SO GET A FOCUS!!!  Geez!!  Hit the nail on the head dude.
>
getting focus is not an easy task...

>>> At present your lack of focus seems to be:
>>> - You like C/UNIX style hacking.
>>> - You like being able to change everything.
>>> - You pick flavor-of-the-month (week??) problems to work on, so
>>> prototyping
>>> must be important to you.
>>> - You don't really care about performance, just getting things
>>> working.
>>>
>>> This puts you in the scripting language camp.  So, what do you think
>>> of Lua?
>>> Or Ruby?
>>>
>> lua: looks like pascal, but otherwise seems cool.
>
> Ok, so try writing something in lua.  Lua was also designed to be extended
> by guys like you, so try extending it somehow.
>
dunno.

>> I am not sure why so many scripting langs resemble shell scripts
>> though. c-syntax would be awkward at a shell, but otherwise I don't
>> get it that well...
>
> It's historical.  The people interested in scripting languages have
> typically been the ones who learned shell languages.  Python is the 
> opposite
> taste from this.  It can do all the scripting jobs, it's quite 
> commercially
> proven in that arena, and it is utterly un-Perl-like.  As far as syntactic
> taste goes, you're either a Python guy or a Perl guy.  FWIW I'm a Python
> guy, in the aesthetic sense.
>
I am still mostly a c guy though.

yes, c has flaws. these can be worked over and cleaned up without making 
things too scarily different though.
going, eg, to a linebreak and indentation sensitive syntax is likely to 
confuse a great many coders (well, ok, same goes for my objects and scoping, 
and I do have a more traditional style syntax for object creation, just I 
don't end up using it as much as the much terser "dictionary" syntax).



0
cr88192355 (1928)
8/11/2004 1:53:50 AM
In article <2nribhF3pupgU1@uni-berlin.de>, "Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com> wrote:
>The other upcoming paradigm shift that I think will be incredibly important
>is fullblown voice recognition and voice synthesis.  If we get to the point
>where we can *talk* to our computers with 100% accuracy, that's going to
>change commerce fundamentally.

Personally, I seriously doubt voice recognition will catch on. HR 
people or accountants will never use it because their data is often 
semi-confidential. Programmers aren't likely to use it, at least in 
the near term, because of all the punctuation needed. 
Managers need primarily to interact with other people and don't 
produce loads of output streams, apart from email, which again is 
likely to be semi-confidential. Have you ever worked in an office 
where someone played a radio tuned to a station you don't like? 
Multiply that by five or ten.

Novelists, maybe, would find it useful.

Alan
0
amonroejj (18)
8/11/2004 2:07:24 AM
Marco Parrone wrote:
> Brandon J. Van Every on Tue, 10 Aug 2004 14:06:30 -0700 writes:
>>
>> The difficulty with the LGPL is that in commercial practice, you must
>> provide your library as a dynamic link library to comply with the
>> license. You can't, for instance, just compile the library
>> statically into your code. I find this to be an annoying futz
>> factor, and in some commercial contexts the restriction would be
>> unacceptable.  Of course that's the LGPL's point, it wants to make
>> certain things unacceptable to commercial development. LGPL
>> prioritizes the right of some geek to fiddle with the library as he
>> sees fit.
>
> That's not correct.
>
> You _can_ statically link proprietary code with LGPL licensed code,
> for example by providing the (linkable) object file(s) for the
> proprietary code.

I said "in commercial practice."  No proprietary developer wants to provide
what you suggest.

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

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

0
8/11/2004 2:53:53 AM
>>I really must get around to playing more with OCaml.  I really love LISP
>>but that's as far as I've ever gone with Functional Languages (except
>>for dabbling briefly with Erlang) and I have to say the 'hard core'
>>functional languages freak me out somewhat :o)  I just don't get them.
>>Which is all the more reason to put the effort in a learn one properly :o)
>>
> 
> 
> Any idea what bugs you? It's a bit weird working without state at first,
> certainly. Well, until you find all the tricks for providing state when
> you really really need it (gee, I'm talking a stateful protocol over the
> network here...).


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.

I guess the other thing is that FP tends to be littered with 
mathematical terms and I'm not fond of maths. :o)

0
Peter
8/11/2004 3:12:25 AM
cr88192 wrote:
> "Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com>
> wrote in message news:2nsr2rF4f945U1@uni-berlin.de...
>> cr88192 wrote:
>>>>
>>> yes, but imo most things that don't look like the c family are
>>> arguably "strange".
>>
>> So what?  That's called learning something new.  In computers you
>> have to do
>> it all the time, one way or another.  I don't believe in learning
>> everything, I do believe we should make strategic choices about what
>> we're going to bother to learn.  But I don't buy this "eew it's
>> strange" attitude
>> for its own sake.  Everything new is strange.
>>
> but things that are stange can scare off newbies.
> c syntax scares off vb programmers, but at least most others wont be
> scared off so easily as likely they are more fammiliar with it.

If your point is that educational hurdles have to be overcome to gain
converts, I agree with you.  If your point is that we should all just wallow
in fear about new things, or mollycoddle people who can't get over newness,
I'd say such people need a different industry.

If you want a language that was explicitly designed to be easy for newbies
to pick up, look at Python.  Python, of course, doesn't have the performance
that OCaml does.  That's the tradeoff.  Python might solve that in a few
years, but I'm working in the here and now.

> there are lots of people that take classes to try to learn java;
> javascript is commonly enough at least lightly handled in
> web-development classes;
> vb is common in introductory classes.

Hopefully you realize that us 'old farts' took our classes in things like
Pascal and C.  In 1988..1992 Cornell U. wasn't even teaching C++!  I learned
that on my own after college.  Anyways college is not vocational training,
there's no mandate that anyone should learn the flavor-of-the-year language
that industry wants to hear about.  That said, I think the prevailent
languages should be taught if they aren't getting in the way of instruction.

> most things had seemed to point in a single direction.
>
> I had then decided:
> I am largely going to stick to c-style syntax;
> failing that, I will rip off bits of vb style syntax (as at least it
> is common).
>
> it is difficult to avoid drifting too far from the c realm
> sometimes...
>
> I compare it to the linux and wondows issue:
> linux is sufficiently unlike windows (even though lots of effort is
> put into cloning it), that many windows users get disorientated and
> feel hopeless when faced with linux (or mac for that matter, eg,
> "what is this menu bar at the top of the screen? oh, how do I operate
> these apps?!...").
> I will argue that most programmers are largely the same way.

Yes, but most programmers aren't idiots, they're just inclined to bitch and
moan.  If a 'strange' language gets some job done better that the programmer
actually needs, then I think the bitching and moaning should cease.  If the
language is 'strange' without any value add, then yes that's gratuitous and
why bother.

I believe OCaml has value add for the problems I'm working on, which is why
I've sunk the time investment into it.  I think it will yield long-term
strategic advantages over the crap everyone else in industry is using.
We'll see though.  If OCaml doesn't yield it, I'll find something that will.
I ain't gonna just do what the herd does, moo, moo.

> it doesn't matter so much what I am willing to do, but more what I
> can get others to be willing to do...

I'm doing just fine starting a face-to-face OCaml discussion group in
Seattle, and a game development mailing list.  The real challenge will be
convincing paying clients to bite on this stuff.  I don't expect I'll get
that to happen right away, but some AI proof-of-concept would do wonders for
what clients are willing to buy.

Getting other people to do stuff means (1) having the will to actually deal
with others in human terms, i.e. communication, mailing lists, group
meetings, and websites, not just coding by yourself inventing everything fro
m scratch.  (2) leveraging the human organizations that are already
available.  I'm working with OCaml because it has critical mass.  I found
some technical features of SML/NJ's C FFI to be more appealing, but they
have no critical mass whatsoever and no will to build it.

Anyways, if you get paying clients to use your language before I get paying
clients to use OCaml, power to you.  I'd hail you as an enterpreneurial
genius.  I know you're not that kinda guy, that you don't seriously deal
with the issue of "getting others to be willing to do stuff."  Maybe you'll
figure out what's required and take some steps, once you've worked in
industry some and get a handle on what people are really after.

> err, annoyingly I have come up with something that could allow really
> cool features (eg: the ability to handle relational db type stuff in
> the core language), but it will likely look quite strange.
>
> db[owner:="Bob", cost:<10000]

What's with your prejudice about this sort of thing looking 'strange' ?
Pretty clearly, you're accessing a database, searching for an owner equal to
Bob and cost less than 10000.  You're way too brittle about what you think
things need to look like, if you think this is 'strange'.

OCaml, yes, it's 'strange' at first to a C++ guy.  But hardly
insurmountable.  It's actually less strange than Lisp, as it is essentially
a block structured language, with human syntactical cues like different
kinds of brackets, braces, and parentheses, rather than a soup of ( ).

>> Granted, for any given language, that's a time investment.  I don't
>> believe
>> in learning all languages.  Rather, I've identified what I'm trying
>> to do (3D graphics and AI).  So I've looked at the languages that
>> seem most applicable to what I'm trying to do.  For now that seems
>> to be OCaml, so that's where I focus my attention.
>>
> yes.
> this may be a bias driven largely by my lang design instincts.
>
> I will use other languages sometimes (eg: I still do some scheme
> coding every so often, and I do write shell scripts), but I will be
> reluctant to really support langs that use unusual syntax.

I say this is because you have no 'driving problem'.  A 'driving problem' is
something you're really really really trying to solve, that pulls you along
and forces you to make decisions about what the right way to do things is.
You dicker with syntax because you don't have a driving problem that's more
fundamentally important than syntax.  I do think syntax matters, for
instance I think C++ syntax is braindead for the complicated parts of it,
and I don't wish to do it anymore.  But between Python and OCaml,
performance clearly counts more for me than syntax.  My driving problems
require the performance.

>> SO GET A FOCUS!!!  Geez!!  Hit the nail on the head dude.
>>
> getting focus is not an easy task...

Didn't say it was.  Learning how to fight isn't easy either.  Nor how to get
a date, for those of us who aren't gorgeous or naturally charming.  Money
doesn't just fall into most people's laps, it has to be earned through a
certain amount of hard work (to set up the coasting, if nothing else).
Anyways, you need to get a focus if you're going to make significant
progress in software development.  I'm sure you'll deal with that reality in
your own sweet time, as everybody does.  All I can do is plant a seed,
regarding where you will inevitably need to go.

One job in industry would cure you of your ills.  If you can't manage
yourself, you'll get managed, and then you'll learn something about focusing
on 'the point'.  Whatever 'the point' is.

This won't satisfy you, and you will probably leave industry to do your own
thing, but at least with that experience, you'll have learned what focus is.

That said, maybe you'll discover some job in industry that could care less
about depth, asks you to produce buckets and buckets of breadth all the
time, and maybe you'll like it.  You won't amount to anything in the
"brilliant computer ideas" dept. under that scenario, but you could
certainly make bags of money as a mega-productive coder.

I strongly prefer brilliance to bags of money, which is why I'm leading the
life I am.

>> Ok, so try writing something in lua.  Lua was also designed to be
>> extended by guys like you, so try extending it somehow.
>>
> dunno.

Translation: donwanna.  You have no driving problem that requires Lua.
Between Lua toys and your own toys, you prefer to play with your own toys.

>> FWIW I'm a Python guy, in the aesthetic sense.
>>
> I am still mostly a c guy though.

I don't have any problem with C for its proper domain: low level
computation.  If I think I'm going to need to turn something into ASM
someday, I definitely want to write it in "the portable assembler" first.
Properly, my C routines should fit on a page or so.  Functions have to be
fairly simple and short to be worthy of ASM optimization.  If it's going to
be more complicated than that, I want a HLL.

I do have problems with C++.  I like operator overloading and that's about
it.  I'm not even convinced that simple inheritance is all it's cracked up
to be.  I've spent an awful lot of time writing OO libraries at the wrong
level of hierarchical granularity, only to throw them out.  OO hierarchies
are not terribly readable, they distribute the semantics of what's going on
all over hell and a half acre.  And of course, memory management is a PITA.
Finally, there's all these bizzare little rules when you need to do anything
complex.  I find myself with one hand in the C++ manual, even after all of
these years.  I don't have that problem with C, it's easy to remember almost
everything about C.

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

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

0
8/11/2004 3:38:40 AM
Peter Ashford wrote:
>
> I really must get around to playing more with OCaml.  I really love
> LISP but that's as far as I've ever gone with Functional Languages
> (except
> for dabbling briefly with Erlang) and I have to say the 'hard core'
> functional languages freak me out somewhat :o)  I just don't get them.
> Which is all the more reason to put the effort in a learn one
> properly :o)

In a hand-wavy sort of way, I think functional languages are easiest to
understand as "having far better templating capabilities than C++ has."
That's all the functional paradigm really seems to amount to.

Sure, there's this fixation on copying stuff rather than modifying state,
but practical languages like OCaml blow that off.  Anally copying everything
is a purist notion, borne of the idea that this is going to make theorem
proving easier.

There may be a point to that, but it sounds remarkably like the argument "if
everybody would just do everything in terms of RISC, the world will be such
a better place!"  Well, the best RISC CPU in the world (the DEC Alpha)
couldn't solve lotsa marketing problems in practice, nor emulate Intel's
architectural approach particularly well.  The main schism was how one
accesses memory.  RISC architectures are deeply pipelined and want a LOAD,
COMPUTE, STORE coding style.  Intel would access memory willy nilly.
Actually, hm, it's kinda the same semantic issue as the FP guys complain
about, having to deal with state changes when you don't want to.

Anyways, as great a CPU as the DEC Alpha was, it wasn't coupled with an
equally good memory controller.  Thus it didn't perform as well as it could
have.  So although RISC has been influential, it simply doesn't solve all of
the industrial problems or make the world a fundamentally better place.
That's what I think the Pure FP fixation on copying amounts to.
Realistically, this just ain't gonna have significant industrial impact.

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

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

0
8/11/2004 3:48:58 AM
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.

> I guess the other thing is that FP tends to be littered with
> mathematical terms and I'm not fond of maths. :o)

From a marketing standpoint I do agree that blah blahing about "the lambda
calculus" is a dead turnoff to anyone interested in the practical.

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

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

0
8/11/2004 3:56:22 AM
"Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com> wrote in 
message news:2nti22F4k9hfU1@uni-berlin.de...
> cr88192 wrote:
>> "Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com>
>> wrote in message news:2nsr2rF4f945U1@uni-berlin.de...
>>> cr88192 wrote:
>>>>>
>>>> yes, but imo most things that don't look like the c family are
>>>> arguably "strange".
>>>
>>> So what?  That's called learning something new.  In computers you
>>> have to do
>>> it all the time, one way or another.  I don't believe in learning
>>> everything, I do believe we should make strategic choices about what
>>> we're going to bother to learn.  But I don't buy this "eew it's
>>> strange" attitude
>>> for its own sake.  Everything new is strange.
>>>
>> but things that are stange can scare off newbies.
>> c syntax scares off vb programmers, but at least most others wont be
>> scared off so easily as likely they are more fammiliar with it.
>
> If your point is that educational hurdles have to be overcome to gain
> converts, I agree with you.  If your point is that we should all just 
> wallow
> in fear about new things, or mollycoddle people who can't get over 
> newness,
> I'd say such people need a different industry.
>
well, probably most of the people in those classes will never really do any 
"real" coding anyways.
most were sitting there and whining about the complexities of bubble sort 
and whatever...

> If you want a language that was explicitly designed to be easy for newbies
> to pick up, look at Python.  Python, of course, doesn't have the 
> performance
> that OCaml does.  That's the tradeoff.  Python might solve that in a few
> years, but I'm working in the here and now.
>
ok.

>> there are lots of people that take classes to try to learn java;
>> javascript is commonly enough at least lightly handled in
>> web-development classes;
>> vb is common in introductory classes.
>
> Hopefully you realize that us 'old farts' took our classes in things like
> Pascal and C.  In 1988..1992 Cornell U. wasn't even teaching C++!  I 
> learned
> that on my own after college.  Anyways college is not vocational training,
> there's no mandate that anyone should learn the flavor-of-the-year 
> language
> that industry wants to hear about.  That said, I think the prevailent
> languages should be taught if they aren't getting in the way of 
> instruction.
>
in my experience that was mostly what was taught...

I had found it ammusing that the a+ teacher knew far more about programming 
than the programming teacher, but I guess he was a programmer that got 
"burnt out on it" or such...

>> most things had seemed to point in a single direction.
>>
>> I had then decided:
>> I am largely going to stick to c-style syntax;
>> failing that, I will rip off bits of vb style syntax (as at least it
>> is common).
>>
>> it is difficult to avoid drifting too far from the c realm
>> sometimes...
>>
>> I compare it to the linux and wondows issue:
>> linux is sufficiently unlike windows (even though lots of effort is
>> put into cloning it), that many windows users get disorientated and
>> feel hopeless when faced with linux (or mac for that matter, eg,
>> "what is this menu bar at the top of the screen? oh, how do I operate
>> these apps?!...").
>> I will argue that most programmers are largely the same way.
>
> Yes, but most programmers aren't idiots, they're just inclined to bitch 
> and
> moan.  If a 'strange' language gets some job done better that the 
> programmer
> actually needs, then I think the bitching and moaning should cease.  If 
> the
> language is 'strange' without any value add, then yes that's gratuitous 
> and
> why bother.
>
I guess this makes sense.

still, it was kind of annoying when no one could understand my gobs of 
scheme code, which gave me less to talk about...

> I believe OCaml has value add for the problems I'm working on, which is 
> why
> I've sunk the time investment into it.  I think it will yield long-term
> strategic advantages over the crap everyone else in industry is using.
> We'll see though.  If OCaml doesn't yield it, I'll find something that 
> will.
> I ain't gonna just do what the herd does, moo, moo.
>
well, I don't think the herd is totally ungrounded, at least what the herd 
does shows what the herd does...

>> it doesn't matter so much what I am willing to do, but more what I
>> can get others to be willing to do...
>
> I'm doing just fine starting a face-to-face OCaml discussion group in
> Seattle, and a game development mailing list.  The real challenge will be
> convincing paying clients to bite on this stuff.  I don't expect I'll get
> that to happen right away, but some AI proof-of-concept would do wonders 
> for
> what clients are willing to buy.
>
ok.

> Getting other people to do stuff means (1) having the will to actually 
> deal
> with others in human terms, i.e. communication, mailing lists, group
> meetings, and websites, not just coding by yourself inventing everything 
> fro
> m scratch.  (2) leveraging the human organizations that are already
> available.  I'm working with OCaml because it has critical mass.  I found
> some technical features of SML/NJ's C FFI to be more appealing, but they
> have no critical mass whatsoever and no will to build it.
>
> Anyways, if you get paying clients to use your language before I get 
> paying
> clients to use OCaml, power to you.  I'd hail you as an enterpreneurial
> genius.  I know you're not that kinda guy, that you don't seriously deal
> with the issue of "getting others to be willing to do stuff."  Maybe 
> you'll
> figure out what's required and take some steps, once you've worked in
> industry some and get a handle on what people are really after.
>
maybe if I am lucky I can actually get people to care about my efforts, 
though it hasn't really worked thus far. now I have a secret weapon though: 
c style syntax...

>> err, annoyingly I have come up with something that could allow really
>> cool features (eg: the ability to handle relational db type stuff in
>> the core language), but it will likely look quite strange.
>>
>> db[owner:="Bob", cost:<10000]
>
> What's with your prejudice about this sort of thing looking 'strange' ?
> Pretty clearly, you're accessing a database, searching for an owner equal 
> to
> Bob and cost less than 10000.  You're way too brittle about what you think
> things need to look like, if you think this is 'strange'.
>
ok.
I wrote it because I thought it seemed cool (or at least the underlying 
structure, but nothing using it thus far).

I then got distracted by another seemingly glittering feature: complex 
numbers.
I am using the syntax:
#(x, y), since it meshes well with my current vector notation.
#(x, y) => (x+yi)

I figured I would treat these like vectors (making things like quaternions 
seem straightforward):
#(w, x, y, z) => (w+xi+yj+zk)

of course, like bignums I can't really answer why, but they seem cool...

> OCaml, yes, it's 'strange' at first to a C++ guy.  But hardly
> insurmountable.  It's actually less strange than Lisp, as it is 
> essentially
> a block structured language, with human syntactical cues like different
> kinds of brackets, braces, and parentheses, rather than a soup of ( ).
>
ok.

>>> Granted, for any given language, that's a time investment.  I don't
>>> believe
>>> in learning all languages.  Rather, I've identified what I'm trying
>>> to do (3D graphics and AI).  So I've looked at the languages that
>>> seem most applicable to what I'm trying to do.  For now that seems
>>> to be OCaml, so that's where I focus my attention.
>>>
>> yes.
>> this may be a bias driven largely by my lang design instincts.
>>
>> I will use other languages sometimes (eg: I still do some scheme
>> coding every so often, and I do write shell scripts), but I will be
>> reluctant to really support langs that use unusual syntax.
>
> I say this is because you have no 'driving problem'.  A 'driving problem' 
> is
> something you're really really really trying to solve, that pulls you 
> along
> and forces you to make decisions about what the right way to do things is.
> You dicker with syntax because you don't have a driving problem that's 
> more
> fundamentally important than syntax.  I do think syntax matters, for
> instance I think C++ syntax is braindead for the complicated parts of it,
> and I don't wish to do it anymore.  But between Python and OCaml,
> performance clearly counts more for me than syntax.  My driving problems
> require the performance.
>
ok.
I don't so much like c++ syntax either. mine looks somewhat different that 
c++, which could discourage c++ programmers, but oh well.

(maybe one could wonder what kind of stamps soustrup was using on his 
envelopes...).
oh well, whatever was being done caused c++ to be successful. it is on-par 
with c, which is quite impressive.

>>> SO GET A FOCUS!!!  Geez!!  Hit the nail on the head dude.
>>>
>> getting focus is not an easy task...
>
> Didn't say it was.  Learning how to fight isn't easy either.  Nor how to 
> get
> a date, for those of us who aren't gorgeous or naturally charming.  Money
> doesn't just fall into most people's laps, it has to be earned through a
> certain amount of hard work (to set up the coasting, if nothing else).
> Anyways, you need to get a focus if you're going to make significant
> progress in software development.  I'm sure you'll deal with that reality 
> in
> your own sweet time, as everybody does.  All I can do is plant a seed,
> regarding where you will inevitably need to go.
>
ok.

> One job in industry would cure you of your ills.  If you can't manage
> yourself, you'll get managed, and then you'll learn something about 
> focusing
> on 'the point'.  Whatever 'the point' is.
>
> This won't satisfy you, and you will probably leave industry to do your 
> own
> thing, but at least with that experience, you'll have learned what focus 
> is.
>
> That said, maybe you'll discover some job in industry that could care less
> about depth, asks you to produce buckets and buckets of breadth all the
> time, and maybe you'll like it.  You won't amount to anything in the
> "brilliant computer ideas" dept. under that scenario, but you could
> certainly make bags of money as a mega-productive coder.
>
> I strongly prefer brilliance to bags of money, which is why I'm leading 
> the
> life I am.
>
ok.

>>> Ok, so try writing something in lua.  Lua was also designed to be
>>> extended by guys like you, so try extending it somehow.
>>>
>> dunno.
>
> Translation: donwanna.  You have no driving problem that requires Lua.
> Between Lua toys and your own toys, you prefer to play with your own toys.
>
yeah, probably.

>>> FWIW I'm a Python guy, in the aesthetic sense.
>>>
>> I am still mostly a c guy though.
>
> I don't have any problem with C for its proper domain: low level
> computation.  If I think I'm going to need to turn something into ASM
> someday, I definitely want to write it in "the portable assembler" first.
> Properly, my C routines should fit on a page or so.  Functions have to be
> fairly simple and short to be worthy of ASM optimization.  If it's going 
> to
> be more complicated than that, I want a HLL.
>
I use c for almost everything.
only in rare cases do I use hll's...

> I do have problems with C++.  I like operator overloading and that's about
> it.  I'm not even convinced that simple inheritance is all it's cracked up
> to be.  I've spent an awful lot of time writing OO libraries at the wrong
> level of hierarchical granularity, only to throw them out.  OO hierarchies
> are not terribly readable, they distribute the semantics of what's going 
> on
> all over hell and a half acre.  And of course, memory management is a 
> PITA.
> Finally, there's all these bizzare little rules when you need to do 
> anything
> complex.  I find myself with one hand in the C++ manual, even after all of
> these years.  I don't have that problem with C, it's easy to remember 
> almost
> everything about C.
>
ok.

yes, in some ways my lang is a rebellion against traditional oo as well.
I am trying for a "good mix" of features from different styles of languages 
(err, and sometimes glimmering features, which don't allways get 
maintained/finished if they are not that useful or I don't feel motivated to 
work on them...).



0
cr88192355 (1928)
8/11/2004 4:38:03 AM
Vincenzo aka Nick Name wrote:

> I am pretty sure that, if I will become a computer science researcher again
> after the short and wonderful parenthesis of my master thesis I will do
> everything in my possibilities to work on cross-language interoperability.
> But I don't expect a single man, in his free time, to be able to do this
> thing, not better than .net at least. My hope is that with .net evolution,
> generics and so on, someone will manage to create a true backend for
> haskell, ocaml and other functional languages, where "true" means that you
> can pass an ocaml function where C# expects a delegate and the converse.

Wouldn't such a project be a good topic for your PhD? You shouldn't stop after
you Master thesis.

I am not convinced that a paid software engineer will be better at doing and
accomplishing what you describe.   Surely a PhD position is poorly paid. I
have a paid PhD position in physics but I can survive and it is better than to
have to apply for a loan and paying it back after the PhD term.

A lot of good things exclusively first happen in the computer science
departements.

Fensterbrett

0
8/11/2004 6:21:01 AM
["Followup-To:" header set to comp.lang.functional.]
cr88192 wrote:
> err, annoyingly I have come up with something that could allow really cool 
> features (eg: the ability to handle relational db type stuff in the core 
> language), but it will likely look quite strange.
>
> db[owner:="Bob", cost:<10000]
>
> managing things like this could be an issue though, since with types like 
> this there is no longer really a 1d index space for such types.
> but it just seemed too cool to not implement.

You may want to look at haskellDB for inspiration:
    http://haskelldb.sourceforge.net/

Overview

   HaskellDB is a combinator library for expressing queries and other
   operations on relational databases in a type safe and declarative
   way.  All the queries and operations are completely expressed within
   Haskell, no embedded (SQL) commands are needed.

I was playing with it recently and I like it very much. The only problem
was that it insists on using subqueries (even if a join would suffice),
so I couldn't use it on our pre 4.1 production MySQL server.

Best regards,
Tom

-- 
..signature: Too many levels of symbolic links
0
t.zielonka2 (138)
8/11/2004 7:05:19 AM
"Tomasz Zielonka" <t.zielonka@zodiac.mimuw.edu.pl> wrote in message 
news:slrnchjh9e.dom.t.zielonka@zodiac.mimuw.edu.pl...
> ["Followup-To:" header set to comp.lang.functional.]
> cr88192 wrote:
>> err, annoyingly I have come up with something that could allow really 
>> cool
>> features (eg: the ability to handle relational db type stuff in the core
>> language), but it will likely look quite strange.
>>
>> db[owner:="Bob", cost:<10000]
>>
>> managing things like this could be an issue though, since with types like
>> this there is no longer really a 1d index space for such types.
>> but it just seemed too cool to not implement.
>
> You may want to look at haskellDB for inspiration:
>    http://haskelldb.sourceforge.net/
>
ok.

I was relying on "attributes" (this is a feature that allready exists in my 
lang). attributes are objects that represent a variable or relation or such.

> Overview
>
>   HaskellDB is a combinator library for expressing queries and other
>   operations on relational databases in a type safe and declarative
>   way.  All the queries and operations are completely expressed within
>   Haskell, no embedded (SQL) commands are needed.
>
> I was playing with it recently and I like it very much. The only problem
> was that it insists on using subqueries (even if a join would suffice),
> so I couldn't use it on our pre 4.1 production MySQL server.
>
ok.

personally I am not much of a fan of haskell in general though, mostly 
because I had problems with the typesystem.

inter-table queries could be problematic, but in the specific case of tables 
at least iteration and manual joins would be possible:

res=sales[price:<1000];
for(i=0; i<|res; i++)
{
    res2=employees[id:=res[i].id];
    println(res2.last, ", ", res2.first, " ", res[i].price);
}
but this seems awkward though.

crap, why is it that whenever I think of databases I come up with stupid 
buisness logic examples?...
crap, my brain probably got corrupted as I learned about them from an sql 
book that had buisness crap for all the examples...



0
cr88192355 (1928)
8/11/2004 8:13:56 AM
On Tue, 10 Aug 2004 22:14:39 +0000, Vincenzo aka Nick Name wrote:

>> I'm experimenting with bindings between my pet language Kogut and other
>> languages.
> 
> But what is this language designed for?

To program in the dynamically typed functional style, without sexpr-based
syntax. There are only a few existing languages with this paradigm (Dylan,
Erlang).

More specifically, I want to experiment with language and environment
introperability, such that a program in my language can use existing
libraries written for other languages. Wrapped foreign objects are
integrated quite seamlessly, and thanks to generic functions they offer
the same interfaces as native objects. I'm quite happy with the Python
integration.

Besides that, it's for me to practice implementing compilers and for fun.

> Have you got documentation?

It's started but not finished yet.
http://kokogut.sourceforge.net/kogut.html

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

0
qrczak (1266)
8/11/2004 8:44:15 AM
Brandon J. Van Every wrote:
> 
> In a hand-wavy sort of way, I think functional languages are easiest to
> understand as "having far better templating capabilities than C++ has."
> That's all the functional paradigm really seems to amount to.

Mhh... I mildly distorted view, I'd say.

> Sure, there's this fixation on copying stuff rather than modifying state,
> but practical languages like OCaml blow that off.  Anally copying everything
> is a purist notion, borne of the idea that this is going to make theorem
> proving easier.
> 
> There may be a point to that, but it sounds remarkably like the argument "if
> everybody would just do everything in terms of RISC, the world will be such
> a better place!"

No, it's rather comparable to "if everybody would just stop using GOTOs, 
debugging and maintaining programs would be much less of a nightmare."

Mutable state is the GOTO of data structures. (Which does not preclude 
it from being handy some time in a while, if used with care and at the 
right places.)

	- Andreas

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

Let's get rid of those possible thingies!  -- TB

0
rossberg (600)
8/11/2004 9:23:11 AM
In article <2nsr9uF4dvqjU1@uni-berlin.de>, 
try_vanevery_at_mycompanyname@yahoo.com says...
> Donn Cave wrote:

> > It's worse.  C++ may have a lot of keywords and confusing semantics,
> > but at the basic level of writing out expressions and having what
> > you wrote turn out to be what you meant, the syntactic structure is
> > not a big problem.
> 
> How many multiply inherited virtual base classes with pointers have you
> done?  

0.

>You're right that C++ has the readability advantage for small code
> blocks, but once you scale up, all of C++'s picky problems rear their ugly
> hydra heads!

I recommend scaling up software, instead of scaling up language 
complexities!

- Gerry Quinn


0
gerryq (1329)
8/11/2004 9:41:24 AM
In article <2ntj38F4kpuqU1@uni-berlin.de>, 
try_vanevery_at_mycompanyname@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




0
gerryq (1329)
8/11/2004 9:49:44 AM
In article <BabSc.11649$N77.518130@news.xtra.co.nz>, me@here.there.com 
says...
> > 
> > Well, maybe both C++ and Ocaml have this property.  My own view is that 
> > designing and programming games is hard, and so long as your language is 
> > powerful, scales well, and is not too awful, it's not the problem.  Of 
> > course you think C++ is too awful - I'm happy to stick with it.
> 
> That's my point of view as well (of course, insert Java for C++ :o) )

Java is way too awful for me - but at least we each have one reasonably 
capable language we can stand...

> I don't often find myself with programming issues which I can figure out 
> how fix but can't really express cleanly with the language I'm using.  I 
> suppose that's part of the reason I'm a little dubious about the 
> advantages of using a functional language.
> 
> <uninformed opinion>
> FL's seem to have lots of benefits that seem very high level and obscure 
> whereas the problems I end up solving usually don't seem to require 
> especially complex or unusal programming approaches to defeat.  The real 
> work is figuring out what I want to do and a good algorithm to do it 
> rather than wrangling with the language.
> </uninformed opinion>

I agree entirely.  My recent game 'Chomp' was quite challenging 
algorithmically (in an 'arrays of vectors of lists of vectors' kind of 
way) but I don't think expressing the search algorithms was the main 
difficulty.

Gerry Quinn
http://bindweed.com
Games, Kaleidoscopes, and Screensavers
Try Chomp! - the new game of logical deduction






0
Gerry
8/11/2004 9:57:24 AM
"Andreas Rossberg" <rossberg@ps.uni-sb.de> wrote in message 
news:cfcoi0$7c8vg$1@hades.rz.uni-saarland.de...
> Brandon J. Van Every wrote:
>>
>> In a hand-wavy sort of way, I think functional languages are easiest to
>> understand as "having far better templating capabilities than C++ has."
>> That's all the functional paradigm really seems to amount to.
>
> Mhh... I mildly distorted view, I'd say.
>
>> Sure, there's this fixation on copying stuff rather than modifying state,
>> but practical languages like OCaml blow that off.  Anally copying 
>> everything
>> is a purist notion, borne of the idea that this is going to make theorem
>> proving easier.
>>
>> There may be a point to that, but it sounds remarkably like the argument 
>> "if
>> everybody would just do everything in terms of RISC, the world will be 
>> such
>> a better place!"
>
> No, it's rather comparable to "if everybody would just stop using GOTOs, 
> debugging and maintaining programs would be much less of a nightmare."
>
yes, and gotos were replaced by generally less awkward forms...

I would much rather type
while(x<3)x++;

than

l1:
if(x<3)goto l2;
x++;
goto l1;
l2:

> Mutable state is the GOTO of data structures. (Which does not preclude it 
> from being handy some time in a while, if used with care and at the right 
> places.)
>
but, unlike goto, many of the attempts to replace it are more awkward.

I will still debate this saying that assignment *is* one of the fundamental 
operations in most programming languages.
yes, fp makes it a little less necessary, but for a majority of cases it is 
still one of the most straightforward approaches imo...

eg: we have a while loop and assignments vs. a recursive form.
yes, the recursive form is more elegant, but is a little more unruly than 
the while loop. yes, via continuations you can jump around or break from the 
loop, but this is yet another thing to need to worry about.
though there are cases where recursion makes more sense, in which case 
convinient recursion is a nice feature.

I don't think it can be phased out as easily as goto, and the approach of 
many fp languages of making it more awkward doesn't fly well imo. yes, it 
still exists, but it is longer to type, and doesn't have such nice forms as:
x+=3;
instead we are often left with things more like:
set x=x+3
or similar, along with the issue that we know that it is bad style for that 
language to use it...



0
cr88192355 (1928)
8/11/2004 10:02:20 AM
R. Alan Monroe wrote:

> Personally, I seriously doubt voice recognition will catch on.

If all computers were (or rather are going to be) PC:s than perhaps a 
guarded yes. The revolution certainly isn't going to start there. But 
that's ignoring all the other stuff that could become computerised if 
there were only decent interface capabilities today.

Imagine how much more convenient it would be to be able to talk to your 
TV or car for example. No futsing about with remotes (invariably lost) 
or groping for the radio controls while taking your hands of the wheel 
and eyes of the road. Think about the possibility of wearables. Putting 
a screen in your glasses is easy enough, but strapping a keyboard to 
your stomach is not really practical.

With workable voice recognition and speech synthesis you could put 
computers *everywhere*. Carton of milk: "Milk how old are you?" Or 
"Milk, tell the fridge when you're one day away from expiration." 
Coupled with a biological sensor to actually determine when the milk's 
actually gone bad you could forget about the "use by" date. You could 
even have the milk tell you: "Please put me back in the fridge now if 
you want me to last three more days". And that's just one very silly 
example. Chosen because no one is ever going to bother walking over to a 
PC to perform those tasks. I've even ignored the obvious ones such as 
your mobile, you're already speaking 'to' it, so why anyone would choose 
to have a keyboard on there if they didn't have to is beyond me.

When the kids that have grown up in such a surrounding enter the 
workplace, they'll find the few people how still use keyboards (I would 
probably be one of the geriatric ones) as quaint old dodgers.

Compare the mobile (cell phone for you yanks) revolution. I'm still 
irked (though it's wearing off) at meeting people in the corridors at 
work speaking straight out into thin air having a conversation via their 
handsfree. And we've incidentally let go of all our land lines, relying 
completely on GSM (GSM indoors) for all phones, so there's a lot of that 
going around. Now I was an adult, well out of university when I got my 
first mobile, but all the first graders here have one these days. I 
think they'll find land lines just as quaint when they enter the 
workforce as their grand children will find keyboards. They'll probably 
still be there but people wont use them much, it'll be a specialised 
skill/taste. Just like the kids going into university today don't get a 
land line for their dorm room. Why should they?

Stefan,
-- 
Stefan Axelsson  (email at http://www.cs.chalmers.se/~sax)
0
crap1234 (43)
8/11/2004 10:42:15 AM
cr88192 wrote:
>>
>>>Sure, there's this fixation on copying stuff rather than modifying state,
>>>but practical languages like OCaml blow that off.  Anally copying 
>>>everything
>>>is a purist notion, borne of the idea that this is going to make theorem
>>>proving easier.
>>>
>>>There may be a point to that, but it sounds remarkably like the argument 
>>>"if
>>>everybody would just do everything in terms of RISC, the world will be 
>>>such
>>>a better place!"
>>
>>No, it's rather comparable to "if everybody would just stop using GOTOs, 
>>debugging and maintaining programs would be much less of a nightmare."
> 
> yes, and gotos were replaced by generally less awkward forms...

That's how you judge it from today's perspective, but back in those days 
people used pretty similar arguments against the banning of goto as you 
hear against discouraging mutable state today. Ask some Fortran veterans.

Like with GOTO, most uses of mutation can be expressed with relative 
ease in more structured ways. And similar to mutable state, people had 
nifty uses of goto that you cannot easily substitute (i.e. fold into a 
loop) - you just don't consider these uses worthwhile today, because you 
have been socialised with the conviction of them being evil.

> I will still debate this saying that assignment *is* one of the fundamental 
> operations in most programming languages.

True. So?

> yes, fp makes it a little less necessary, but for a majority of cases it is 
> still one of the most straightforward approaches imo...
> 
> eg: we have a while loop and assignments vs. a recursive form.
> yes, the recursive form is more elegant, but is a little more unruly than 
> the while loop.

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.

> I don't think it can be phased out as easily as goto, and the approach of 
> many fp languages of making it more awkward doesn't fly well imo. yes, it 
> still exists, but it is longer to type, and doesn't have such nice forms as:
> x+=3;
> instead we are often left with things more like:
> set x=x+3

That's a strawman. FPLs are tuned for building abstractions. E.g. in SML 
just define

   infix +=
   fun (n += i) = (n := !n+i)

> or similar, along with the issue that we know that it is bad style for that 
> language to use it...

Actually, I consider it bad style independent of the language. It's just 
that some languages don't support "good style". I try to avoid them for 
doing high-level stuff.

To clarify: I'm not dogmatic about state. I use languages that allow me 
to fall back to mutable state when I really have to. But I always think 
twice before doing so, because pretty much every single use of mutable 
state has bitten me in some way sooner or later. And I originally come 
from C/C++, too (heck, hard to admit, but there even were days when I 
was so dumb that I considered C++ the greatest language on earth - today 
I'd say the opposite.)

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

Let's get rid of those possible thingies!  -- TB

0
rossberg (600)
8/11/2004 12:16:21 PM
On Wed, 11 Aug 2004, cr88192 wrote:

> I was relying on "attributes" (this is a feature that allready exists in my
> lang). attributes are objects that represent a variable or relation or such.
>

A number of Haskell libraries define something similar - wxHaskell, for
example. You end up with a similar syntax, too:

set obj [prop := val, prop :~ updateFun]

-- 
flippa@flippac.org
0
flippa (196)
8/11/2004 1:39:33 PM
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.

-- 
flippa@flippac.org
0
Philippa
8/11/2004 2:30:44 PM
"Philippa Cowderoy" <flippa@flippac.org> wrote in message 
news:Pine.WNT.4.53.0408111438260.1384@SLINKY...
> On Wed, 11 Aug 2004, cr88192 wrote:
>
>> I was relying on "attributes" (this is a feature that allready exists in 
>> my
>> lang). attributes are objects that represent a variable or relation or 
>> such.
>>
>
> A number of Haskell libraries define something similar - wxHaskell, for
> example. You end up with a similar syntax, too:
>
> set obj [prop := val, prop :~ updateFun]
>
ok, cool.

of course, as of yet attribute types other than ':=' are not supported...

they are used, eg, as the basis of "dictionary syntax" and for other such 
uses...



0
cr88192355 (1928)
8/11/2004 4:04:45 PM
"Andreas Rossberg" <rossberg@ps.uni-sb.de> wrote in message 
news:cfd2ml$7c8vg$2@hades.rz.uni-saarland.de...
> cr88192 wrote:
>>>
>>>>Sure, there's this fixation on copying stuff rather than modifying 
>>>>state,
>>>>but practical languages like OCaml blow that off.  Anally copying 
>>>>everything
>>>>is a purist notion, borne of the idea that this is going to make theorem
>>>>proving easier.
>>>>
>>>>There may be a point to that, but it sounds remarkably like the argument 
>>>>"if
>>>>everybody would just do everything in terms of RISC, the world will be 
>>>>such
>>>>a better place!"
>>>
>>>No, it's rather comparable to "if everybody would just stop using GOTOs, 
>>>debugging and maintaining programs would be much less of a nightmare."
>>
>> yes, and gotos were replaced by generally less awkward forms...
>
> That's how you judge it from today's perspective, but back in those days 
> people used pretty similar arguments against the banning of goto as you 
> hear against discouraging mutable state today. Ask some Fortran veterans.
>
well, in many langs it is not exactly banned, more just bad style to use it 
too heavily.

my lang retains goto, and here is a chink of what it looks like:
function gfun()
{
    local i;

    i=0;

    l0:
    i++;
    if(i>10)goto l1;
    if(i<5)goto l0;
    println("gfun ", i);
    goto l0;
    l1:
}

but, yes, goto is used a lot less anymore...
(I debated adding goto for a while, but eventually decided to add it).

> Like with GOTO, most uses of mutation can be expressed with relative ease 
> in more structured ways. And similar to mutable state, people had nifty 
> uses of goto that you cannot easily substitute (i.e. fold into a loop) - 
> you just don't consider these uses worthwhile today, because you have been 
> socialised with the conviction of them being evil.
>
or at least annoying.
goto is a lot more usable, at least in the assembler I use, as they follow 
kinds of nesting rules and such absent in many languages...

>> I will still debate this saying that assignment *is* one of the 
>> fundamental operations in most programming languages.
>
> True. So?
>
well, in this case it is difficult to remove without people feeling 
constrained.

>> yes, fp makes it a little less necessary, but for a majority of cases it 
>> is still one of the most straightforward approaches imo...
>>
>> eg: we have a while loop and assignments vs. a recursive form.
>> yes, the recursive form is more elegant, but is a little more unruly than 
>> the while loop.
>
> 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.
>
well, I was using a lot of recursion.

in my lang the syntax for recursion is not quite as elegant as would be 
hoped, but it is still usable:
(fun r0(x){(x<=1)?1:x*r0(x-1)})(10);
fun r0(x) {(x<=1)?1:x*r0(x-1)} (10);
or:
fun r0(x)x<=1?1:x*r0(x-1)(10);

all these results in the factorial of 10.

yes, I had considered adding things like let and rlet, but application and 
first class functions just work so well (even if they are awkward looking).
yes, I have better ways of calculating numbers like this, but this was an 
example.

however, first they need to compete with things like while or for...

>> I don't think it can be phased out as easily as goto, and the approach of 
>> many fp languages of making it more awkward doesn't fly well imo. yes, it 
>> still exists, but it is longer to type, and doesn't have such nice forms 
>> as:
>> x+=3;
>> instead we are often left with things more like:
>> set x=x+3
>
> That's a strawman. FPLs are tuned for building abstractions. E.g. in SML 
> just define
>
>   infix +=
>   fun (n += i) = (n := !n+i)
>
ok.
I am, however, used to this kind of thing being a standard feature of the 
language. I retain features that are low level and can promote bad style, 
along with those that might promote better use.

I am sticking close to its imperative roots, which is partly why I coined it 
as imperative-functional...

>> or similar, along with the issue that we know that it is bad style for 
>> that language to use it...
>
> Actually, I consider it bad style independent of the language. It's just 
> that some languages don't support "good style". I try to avoid them for 
> doing high-level stuff.
>
ok.

> To clarify: I'm not dogmatic about state. I use languages that allow me to 
> fall back to mutable state when I really have to. But I always think twice 
> before doing so, because pretty much every single use of mutable state has 
> bitten me in some way sooner or later. And I originally come from C/C++, 
> too (heck, hard to admit, but there even were days when I was so dumb that 
> I considered C++ the greatest language on earth - today I'd say the 
> opposite.)
>
well, c is by far not that great of a language, but it offers things which 
many other languages fall short on:
it is still fairly portable;
it gives you fairly direct control over what is going on;
....

one doesn't have to feel bad about doing ugly things with it, building their 
own type and memory management systems, having parts of their source written 
by tools, ...
c is a good lang for ugly things.

or something...



0
cr88192355 (1928)
8/11/2004 4:55:24 PM
Siegfried Gonzi wrote:

> 
> Wouldn't such a project be a good topic for your PhD? You shouldn't stop
> after you Master thesis.

Of course it would, but you have to see what your supervisor wants you to
do :) I still don't know if I will be admitted to PhD, exams are in
november, but I am working at the moment and just discovered that I am
better paid to write foreach than to prove theorems.

> 
> I am not convinced that a paid software engineer will be better at doing
> and accomplishing what you describe.���

Yes, I meant "a paid research group" :)

>> Surely�a�PhD�position�is�poorly 
> paid.�I have a paid PhD position in physics but I can survive and it is
> better than to have to apply for a loan and paying it back after the PhD
> term.
> 
> A lot of good things exclusively first happen in the computer science
> departements.

I still believe in computer science research but am unsure of how much of
this research, that could be applied if projects were not closed every 3
years, will ever be used for some purpose when it's buried a dead project's
archive. Or patented by microsoft, of course :) 

V.
0
8/11/2004 6:19:58 PM
Gerry Quinn wrote:

> In article <2ntj38F4kpuqU1@uni-berlin.de>, 
> try_vanevery_at_mycompanyname@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"
0
me5036 (108)
8/11/2004 10:39:33 PM
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 :o)  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 :o)

That said, I will give it a go. ;-)  I clearly need to broaden my horizons.
0
Peter
8/11/2004 10:44:04 PM
On Wed, 11 Aug 2004 00:59:24 +0100, Philippa Cowderoy
<flippa@flippac.org> wrote:

>[2] By which I mean that computations can take computations as
>parameters and return computations as results - if there's an existing
>use of the term that differs from this, could somebody enlighten me
>btw? - this has a consequence, which is that any data the monad keeps
>(state being the classical example) won't branch any - this allows the IO
>monad to represent a function of type world->world without ever trying to
>duplicate the world, thus allowing a pure (if not complete) language to
>express interaction with the outside world without giving too many
>physicists big headaches.

Is that like a statically typed version of Scheme's continuations? If
not, what (apart from the static typing) is the difference?

-- 
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
0
wallacethinmintr
8/11/2004 11:03:52 PM
In article <2nubg8F4q8r9U1@uni-berlin.de>, Stefan Axelsson <crap1234@hotmail.com> wrote:
>R. Alan Monroe wrote:
>
>> Personally, I seriously doubt voice recognition will catch on.
>
>If all computers were (or rather are going to be) PC:s than perhaps a 
>guarded yes. The revolution certainly isn't going to start there. But 
>that's ignoring all the other stuff that could become computerised if 
>there were only decent interface capabilities today.
>
>Imagine how much more convenient it would be to be able to talk to your 
>TV or car for example. No futsing about with remotes (invariably lost) 
>or groping for the radio controls while taking your hands of the wheel 
>and eyes of the road.

Sorry, but I'm still not buying it. If I'm listening to the radio in 
the car I'm probably following an interview conversation or news 
story, and interjecting my own voice is just going to be so much 
noise. If you're rocking out really hard, are you going to start 
yelling to be heard over the music? Ditto listening to music at home. 
I'm probably in the minority but when I listen to music, I'm actually 
LISTENING to it and not just using it for background noise. I want to 
listen to the music and not myself. And consider those occasions where 
you're involved with a member of the opposite sex... going to stop to 
yell at your stereo to turn the volume up or down?


>With workable voice recognition and speech synthesis you could put 
>computers *everywhere*. Carton of milk: "Milk how old are you?" Or 
>"Milk, tell the fridge when you're one day away from expiration." 
>Coupled with a biological sensor to actually determine when the milk's 
>actually gone bad you could forget about the "use by" date. You could 
>even have the milk tell you: "Please put me back in the fridge now if 
>you want me to last three more days". And that's just one very silly 
>example. Chosen because no one is ever going to bother walking over to a 
>PC to perform those tasks.

I think a MUCH more practical approach is simply to make the packaging 
glow a different hue or play a quiet simple tune when you pick up the 
container. Major chords for fresh and minor chords for stale.

Maybe it's just me but it seems like a lot of people that grew up on 
Star Trek and the like think that talking to a computer is useful. 
What they fail to remember is that in a scripted drama only one person 
is typically speaking at any given time. Have you ever seen the movie 
Close Encounters of the Third Kind? Imagine the air traffic control 
room scene, many times over. Noise and chatter is just not conducive 
to good concentration. Inadvertently commanding someone else's device 
is also a problem.

Alan
0
amonroejj (18)
8/12/2004 3:16:34 AM
Peter Ashford <me@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. 

>> But if the world isn't easily divided neatly into objects, 

I think insisting on analogy with the "real world" is a blind alley,
computer programs are, like it or not, mathematical constructs.
Sometimes math has an obvious connection to the real world ("John has
four apples...", sometimes less so.

>> it is even less easily divided neatly into algorithms.

OTOH, FP doesn't require any neat division, it's not hierarchical like
OO.  It just lets you compose those algorithms in very flexible ways.

-ketil
-- 
If I haven't seen further, it is by standing in the footprints of giants
0
ketil (99)
8/12/2004 6:16:21 AM
Andreas Rossberg wrote:
> cr88192 wrote:
>>
>> yes, and gotos were replaced by generally less awkward forms...
>
> That's how you judge it from today's perspective, but back in those
> days people used pretty similar arguments against the banning of goto
> as you
> hear against discouraging mutable state today. Ask some Fortran
> veterans.

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.

> 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?

> 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.

> To clarify: I'm not dogmatic about state. I use languages that allow
> me
> to fall back to mutable state when I really have to. But I always
> think
> twice before doing so, because pretty much every single use of mutable
> state has bitten me in some way sooner or later. And I originally come
> from C/C++, too (heck, hard to admit, but there even were days when I
> was so dumb that I considered C++ the greatest language on earth -
> today I'd say the opposite.)

I can't say that mutable state has ever bitten me in anything I've done in
software.  I think the bogdowns come from overoptimizing, core architectural
decisions I can't change, tedious documentation, and libraries that don't
actually work.

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

20% of the world is real.
80% is gobbledygook we make up inside our own heads.


0
8/12/2004 7:54:09 AM
Siegfried Gonzi wrote:
>
> I am not convinced that a paid software engineer will be better at
> doing and accomplishing what you describe.   Surely a PhD position is
> poorly paid. I have a paid PhD position in physics but I can survive
> and it is better than to have to apply for a loan and paying it back
> after the PhD term.

Currently I register voters at $8/hour to support myself.  Starving artists
all over the world do what they gotta do to fulfil their visions.  All the
money in computers makes people soft, or "golden handcuffed."  But if you
end up on the wrong side of a dot.com bust, your perspective can change as
to what's the most important thing to pursue.  Most important to me right
now is advancing my OCaml 3D graphics and AI projects.  I will admit, I
think the investments will pay off with millions of dollars someday.  Just
not now.  I wouldn't do this if I thought I was going to be poor forever at
it.  It's too much work; I would just paint.


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

When no one else sells courage, supply and demand take hold.

0
8/12/2004 8:01:45 AM
R. Alan Monroe wrote:

> Sorry, but I'm still not buying it. If I'm listening to the radio in 
> the car I'm probably following an interview conversation or news 
> story, and interjecting my own voice is just going to be so much 
> noise. If you're rocking out really hard, are you going to start 
> yelling to be heard over the music? 

Well, I'm not sure I follow your objection. If you're listening 
intensely on the radio you're not fiddling with the knobs at the same 
time today are you? So why would you speak to it in the voice 
recognition scenario? It's only when you're not happy with the current 
state of affairs you'll be set on changing them.

And one wouldn't have to yell at the radio even today, since the radio 
knows what signal it's putting through the speaker with a few 
microphones in the car it could hear you over its own output quite well 
assuming only the state of the art in signal processing, so that's not 
much of a problem.

> Ditto listening to music at home. 
> I'm probably in the minority but when I listen to music, I'm actually 
> LISTENING to it and not just using it for background noise. I want to 
> listen to the music and not myself. And consider those occasions where 
> you're involved with a member of the opposite sex... going to stop to 
> yell at your stereo to turn the volume up or down?

No, these aren't situations when I'd like to speak to my stereo, but 
then again I wouldn't grope for the remote today either, so I'm not 
quite following your point.

> I think a MUCH more practical approach is simply to make the packaging 
> glow a different hue or play a quiet simple tune when you pick up the 
> container. Major chords for fresh and minor chords for stale.

Sure, today that would be. But there are several problems with that. The 
first is that then you've introduced an interface that has to be learned 
again. And not many are going to bother with that when it comes to a 
carton of milk. Second while I'm musical (and you obviously) I know a 
few tone deaf people who would have a problem even distinguishing your 
chords. :-)

> Maybe it's just me but it seems like a lot of people that grew up on 
> Star Trek and the like think that talking to a computer is useful. 
> What they fail to remember is that in a scripted drama only one person 
> is typically speaking at any given time. 

Well, to be frank, what bothers me about the Star Trek interface more 
are the control panels more than the speech recognition. They seem to 
consistently get an a awful lot of interaction from just three key 
presses or so, regardless of the problem to be solved. For the type of 
situation I've drawn up I think it actually works: "Computer open the 
door" (or some such) when someone is on the outside and you're inside, 
would actually work fairly well.

> Have you ever seen the movie 
> Close Encounters of the Third Kind? Imagine the air traffic control 
> room scene, many times over. Noise and chatter is just not conducive 
> to good concentration. Inadvertently commanding someone else's device 
> is also a problem.

Well, I'm assuming relatively smart voice recognition also. The computer 
has to be able to recognise when someone is talking to them (perhaps via 
a prefix) and who it is doing the talking.

And yes, I've seen Close Encounters though long ago. But I've actually 
visited a real ATC (equally long ago) and believe me they're not nearly 
as chatty. Well, they are, since the controllers talk to airplanes all 
the time, but there's not much interference between them. If there were 
people would lose their lives, so the workplace is set up to correct that.

Come to think of it, the bridge scenario (command and control) would 
probably work pretty well with voice recognition, as that's how it 
operates today. If *people* weren't capable of hearing orders and 
responses in those situations then mixing in one computer to act as one 
listener (as in Star Trek) wouldn't make matters much worse. Introducing 
several listeners (one for each bridge officer) would lead to more chat. 
But not much more than what is already present in a real scenario today, 
as many people on a bridge will actually be communicating with other 
members of the crew via some voice link. So it's not that far fetched.

Now, sure if you're a cubicle peon then the noise level would tend to 
the unbearable pretty quickly (or at least it could), so voice 
recognition would be yet another good reason to have separate offices 
(yeay!), just compare phones, but at least in the early stages I would 
replace some of the mouse interaction with speech recognition. Compare 
the hotkeys on some keyboards today, with buttons for email etc. These 
should imho be replaced with spoken commands: "PC: email". Combine that 
with being able to check or hear the current status ("A secretary in a 
can" if you will). Such as "You have a meeting in ten minutes". "PC: Who 
with?" "Alice and Bob". I think that would work, and work well, as I'm 
seemingly always on the run these days.

I'm not saying voice for everything and every situation, my research 
area is visualisation after all :-). But I am saying that the majority 
of interaction with computers in the future will probably be by voice. 
And that these 'computers' won't be thought of as computers in that they 
will have been embedded in everyday objects, everywhere, and that 
speaking to your e.g door will have become second nature.

Stefan,
-- 
Stefan Axelsson  (email at http://www.cs.chalmers.se/~sax)
0
crap1234 (43)
8/12/2004 8:02:28 AM
> Personally, I seriously doubt voice recognition will catch on. HR
> people or accountants will never use it because their data is often
> semi-confidential. Programmers aren't likely to use it, at least in
> the near term, because of all the punctuation needed.
> Managers need primarily to interact with other people and don't
> produce loads of output streams, apart from email, which again is
> likely to be semi-confidential. Have you ever worked in an office
> where someone played a radio tuned to a station you don't like?
> Multiply that by five or ten.
>
> Novelists, maybe, would find it useful.

It has its uses.  I wrote some VR code about 6 months ago for a company that
wanted a command and control interface for a complex documentation
management system (for the military's "objective force" initiative) and it
hooked straight into our AI so that you could accomplish complicated tasks
with minimal input once there was minor familiarity with the system, the
example wasn't document related, it was a 3D scene and it worked like:

"Look at the humvee"
"Track the humvee"
"hide all buildings"
"hide all vehicles"
"zoom in on the BMP"

Et cetera...  All actions which would require computer familiarity or scene
knowledge in order to achieve w/o a VR hooked up to our AI (to interpret the
intention of the voice command [subject, action, et cetera.])

It will have its uses.  I'm in the process of wiring my house for automation
and I have already tested out a "Star Trek"-like system where my old 733 Mhz
machine does nothing but listen for the phrase "Computer" by itself.  When
it does, it replies "Computer here" via SAPI 5 TTS.  Of course, I had to add
the "I'm sorry Dave, I can't do that" clip to the 'unknown goal' responses
;).

    WTH:)


0
spamsucks (63)
8/12/2004 8:12:40 AM
cr88192 wrote:
> "Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com>
>>
>> If your point is that educational hurdles have to be overcome to gain
>> converts, I agree with you.  If your point is that we should all just
>> wallow
>> in fear about new things, or mollycoddle people who can't get over
>> newness,
>> I'd say such people need a different industry.
>>
> well, probably most of the people in those classes will never really
> do any "real" coding anyways.
> most were sitting there and whining about the complexities of bubble
> sort and whatever...

But you went briefly to some community college in Nevada, right?  You're not
even vaguely where you belong, you should be at MIT or Carnegie-Mellon or
something.  At least at Cornell U., you were far more likely to run into
guys who think their professors are full of shit, than guys who whine about
bubble sorts.  I don't think that sort of whining is allowed at Cornell - in
*any* academic subject.  I'm not saying Cornell is full of geniuses.  There
are 9 colleges, some of 'em are state land grant schools, and you can find
plenty of stupid people there.  But, the private schools do have high
admission standards.  It pays to go to a school who's students are way
smarter than the general population.

Well, at least you have the internet, where people can keep up with you.

>> Yes, but most programmers aren't idiots, they're just inclined to
>> bitch and
>> moan.  If a 'strange' language gets some job done better that the
>> programmer
>> actually needs, then I think the bitching and moaning should cease.
>> If the
>> language is 'strange' without any value add, then yes that's
>> gratuitous and
>> why bother.
>>
> I guess this makes sense.
>
> still, it was kind of annoying when no one could understand my gobs of
> scheme code, which gave me less to talk about...

Who says they'd understand it just because you wrote it in C?  It's just
*less* of a barrier.  You still have to contend with how readable your code
is, whether other people understand the problem domain you're working on,
whether they care, whether they think you're wasting their time on a
profitless exercise, etc.

>> I believe OCaml has value add for the problems I'm working on, which
>> is why
>> I've sunk the time investment into it.  I think it will yield
>> long-term strategic advantages over the crap everyone else in
>> industry is using. We'll see though.  If OCaml doesn't yield it,
>> I'll find something that will.
>> I ain't gonna just do what the herd does, moo, moo.
>>
> well, I don't think the herd is totally ungrounded, at least what the
> herd does shows what the herd does...

What the herd does is show up to write corporate accounting software in
exchange for a fat paycheck.  When you've had a job in industry, you'll see
what I mean.  It may take you some time to find a job where people actually
give a shit about the kinds of 'brainy' problems you entertain regularly.  I
hope you find the right kind of job for you quickly, otherwise you're gonna
be one miserable sonofabitch.

> maybe if I am lucky I can actually get people to care about my
> efforts, though it hasn't really worked thus far. now I have a secret
> weapon though: c style syntax...

Which is so secret that... C# uses it, Java uses it.  Sorry, this is not a
competitive advantage.  You need something so great about your language that
it rises above being Yet Another Language.  Nobody's interested in YAL.  The
language has to do something that's not getting done, or getting done badly.

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

"Trollhunt" - (n.) A searching out for persecution
of persons accused of Trolling. (c.f. witch-hunt)

0
8/12/2004 8:23:22 AM
amonroejj@yahoo.com (R. Alan Monroe) writes:

[snip]
>>Imagine how much more convenient it would be to be able to talk to your 
>>TV or car for example. No futsing about with remotes (invariably lost) 
>>or groping for the radio controls while taking your hands of the wheel 
>>and eyes of the road.
>
> Sorry, but I'm still not buying it. If I'm listening to the radio in the
> car I'm probably following an interview conversation or news story, and
> interjecting my own voice is just going to be so much noise.

It'd be really interesting if the car confused your voice with the radio
presenter's ..

However, voice-activation in this scenario is a solution looking for a
problem. It takes about 30-40% of a human's concentration to drive, and
there's nothing wrong with picking one's moment to eat a sandwich, drink
irn-bru and change the radio volume whilst trundling along. (I'd go as far
as to say, if you *can't* see when it's safe to juggle such a few simple
things at once, get the hell off my road.)

I also object to the idea of inflicting noise on others in my environment.
Just as yelling at the phone in conference-call mode in an open-plan office
is bad, so would yelling at the computer be; by extrapolation, I wouldn't
want to pain everyone else in the household with a battery of beeping
voices telling me it's time to eat a carrot, either.

~Tim
-- 
   09:41:51 up 15 days, 14:32,  0 users,  load average: 0.04, 0.29, 0.24
piglet@stirfried.vegetable.org.uk |Bagpuss gave a big yawn,
http://spodzone.org.uk/cesspit/   |and settled down to sleep.
0
8/12/2004 8:48:21 AM
"Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com> wrote in 
message news:2o0n3sF5ci49U1@uni-berlin.de...
> cr88192 wrote:
>> "Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com>
>>>
>>> If your point is that educational hurdles have to be overcome to gain
>>> converts, I agree with you.  If your point is that we should all just
>>> wallow
>>> in fear about new things, or mollycoddle people who can't get over
>>> newness,
>>> I'd say such people need a different industry.
>>>
>> well, probably most of the people in those classes will never really
>> do any "real" coding anyways.
>> most were sitting there and whining about the complexities of bubble
>> sort and whatever...
>
> But you went briefly to some community college in Nevada, right?  You're 
> not
> even vaguely where you belong, you should be at MIT or Carnegie-Mellon or
> something.  At least at Cornell U., you were far more likely to run into
> guys who think their professors are full of shit, than guys who whine 
> about
> bubble sorts.  I don't think that sort of whining is allowed at Cornell - 
> in
> *any* academic subject.  I'm not saying Cornell is full of geniuses. 
> There
> are 9 colleges, some of 'em are state land grant schools, and you can find
> plenty of stupid people there.  But, the private schools do have high
> admission standards.  It pays to go to a school who's students are way
> smarter than the general population.
>
ok.

the occurance of rambling old people is annoying as well, since they tend to 
interfere with the progress of the class and such...

> Well, at least you have the internet, where people can keep up with you.
>
yes.

>>> Yes, but most programmers aren't idiots, they're just inclined to
>>> bitch and
>>> moan.  If a 'strange' language gets some job done better that the
>>> programmer
>>> actually needs, then I think the bitching and moaning should cease.
>>> If the
>>> language is 'strange' without any value add, then yes that's
>>> gratuitous and
>>> why bother.
>>>
>> I guess this makes sense.
>>
>> still, it was kind of annoying when no one could understand my gobs of
>> scheme code, which gave me less to talk about...
>
> Who says they'd understand it just because you wrote it in C?  It's just
> *less* of a barrier.  You still have to contend with how readable your 
> code
> is, whether other people understand the problem domain you're working on,
> whether they care, whether they think you're wasting their time on a
> profitless exercise, etc.
>
a problem with plain c code is that it would just take too damn much 
printing to have anything of real value there.

>>> I believe OCaml has value add for the problems I'm working on, which
>>> is why
>>> I've sunk the time investment into it.  I think it will yield
>>> long-term strategic advantages over the crap everyone else in
>>> industry is using. We'll see though.  If OCaml doesn't yield it,
>>> I'll find something that will.
>>> I ain't gonna just do what the herd does, moo, moo.
>>>
>> well, I don't think the herd is totally ungrounded, at least what the
>> herd does shows what the herd does...
>
> What the herd does is show up to write corporate accounting software in
> exchange for a fat paycheck.  When you've had a job in industry, you'll 
> see
> what I mean.  It may take you some time to find a job where people 
> actually
> give a shit about the kinds of 'brainy' problems you entertain regularly. 
> I
> hope you find the right kind of job for you quickly, otherwise you're 
> gonna
> be one miserable sonofabitch.
>
dunno here.

>> maybe if I am lucky I can actually get people to care about my
>> efforts, though it hasn't really worked thus far. now I have a secret
>> weapon though: c style syntax...
>
> Which is so secret that... C# uses it, Java uses it.  Sorry, this is not a
> competitive advantage.  You need something so great about your language 
> that
> it rises above being Yet Another Language.  Nobody's interested in YAL. 
> The
> language has to do something that's not getting done, or getting done 
> badly.
>
well, the advantage of c like systax is that it lowers the requiremets 
needed to understand it, and increases the likelyness that a typical 
programmer will look into it.

this would be an advantage over many scripting languages, where c-style 
syntax is much less often used (excepting a lot of project-specific 
languages and such). most of the languages that use c-style syntax are not 
scripting languages.

I am also seeing if there is any advantage to overloading the crap out of 
the builtin operators.

the only other real features I have is those that are ripped off from other 
languages.

at present there is nothing that makes it not just yet-another-language 
anyways, that is a task for later...



0
cr88192355 (1928)
8/12/2004 9:42:37 AM
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@ps.uni-sb.de

Let's get rid of those possible thingies!  -- TB

0
Andreas
8/12/2004 9:46:03 AM
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@ps.uni-sb.de

Let's get rid of those possible thingies!  -- TB

0
rossberg (600)
8/12/2004 9:49:29 AM
In article <egekmclw3u.fsf@ii.uib.no>, ketil@ii.uib.no says...
> Peter Ashford <me@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













0
gerryq (1329)
8/12/2004 10:48:19 AM
In article <cffef9$7c8vg$4@hades.rz.uni-saarland.de>, rossberg@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






0
gerryq (1329)
8/12/2004 10:53:09 AM
In article <2o0mglF572svU1@uni-berlin.de>, Stefan Axelsson <crap1234@hotmail.com> wrote:
>> I think a MUCH more practical approach is simply to make the packaging 
>> glow a different hue or play a quiet simple tune when you pick up the 
>> container. Major chords for fresh and minor chords for stale.
>
>Sure, today that would be. But there are several problems with that. The 
>first is that then you've introduced an interface that has to be learned 
>again. And not many are going to bother with that when it comes to a 
>carton of milk. Second while I'm musical (and you obviously) I know a 
>few tone deaf people who would have a problem even distinguishing your 
>chords. :-)

OK (OBGames) substitute the Super Mario Brothers coin pickup sound for 
fresh, and the Donkey Kong grinding girder smash sound for stale...


>area is visualisation after all :-). But I am saying that the majority 
>of interaction with computers in the future will probably be by voice. 
>And that these 'computers' won't be thought of as computers in that they 
>will have been embedded in everyday objects, everywhere, and that 
>speaking to your e.g door will have become second nature.

To each his own, I suppose. But I think expressions like "silence is 
golden" exist for a reason.

Alan
0
amonroejj (18)
8/12/2004 11:04:39 AM
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@ps.uni-sb.de

Let's get rid of those possible thingies!  -- TB

0
rossberg (600)
8/12/2004 11:29:32 AM
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@ps.uni-sb.de

Let's get rid of those possible thingies!  -- TB

0
rossberg (600)
8/12/2004 11:36:35 AM
Stefan Axelsson wrote:
>
> With workable voice recognition and speech synthesis you could put
> computers *everywhere*. Carton of milk: "Milk how old are you?" Or
> "Milk, tell the fridge when you're one day away from expiration."
> Coupled with a biological sensor to actually determine when the milk's
> actually gone bad you could forget about the "use by" date. You could
> even have the milk tell you: "Please put me back in the fridge now if
> you want me to last three more days". And that's just one very silly
> example.

Actually it leads to Hitchhiker's Guide style marketing horrors all too
quickly.  "Mmm, Milk!  You like milk, Billy, don't you?"  "I thought so.
Did you know that milk is one of the 4 food groups, Billy?"

Another big paradigm shift would be printable monitor displays.  Read an
article about that in Wired a few years back if memory serves.  The idea is
that you could get the fiber optic technology onto sheets of paper and run
them out of things the size of newspaper printing presses.  Then the amount
of surface area you'd have for visual display would be huge and cheap.  You
could afford to put these displays on anything.

The advertizing possibilities are equally disgusting.

> When the kids that have grown up in such a surrounding enter the
> workplace, they'll find the few people how still use keyboards (I
> would probably be one of the geriatric ones) as quaint old dodgers.

Actually, speaking continuously all day might wear out the voice and lead to
new workplace injuries.  I certainly have more throat problems now that I'm
doing voter registration all the time.  I'm not speaking continuously,
unless it's a high volume area.  Someone told me the trick is to keep
drinking water, so I do.  It does help.

Well, hopefully the computers are smart enough to allow us to give them
higher level tasks.

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

"The pioneer is the one with the arrows in his back."
                          - anonymous entrepreneur

0
8/12/2004 11:52:21 AM
R. Alan Monroe wrote:
> And consider those occasions where
> you're involved with a member of the opposite sex... going to stop to
> yell at your stereo to turn the volume up or down?

I would expect kink reverberations between sex act and music play.  "Harder,
harder, louder, harder, harder!"

> I think a MUCH more practical approach is simply to make the packaging
> glow a different hue or play a quiet simple tune when you pick up the
> container. Major chords for fresh and minor chords for stale.

I don't think anything's going to change about milk expiration dates at all.
Aside from this being a solution in search of a problem, there are
governmental regulations that will be etched in stone, and no commercial
impetus to change them.

> Maybe it's just me but it seems like a lot of people that grew up on
> Star Trek and the like think that talking to a computer is useful.
> What they fail to remember is that in a scripted drama only one person
> is typically speaking at any given time. Have you ever seen the movie
> Close Encounters of the Third Kind? Imagine the air traffic control
> room scene, many times over. Noise and chatter is just not conducive
> to good concentration. Inadvertently commanding someone else's device
> is also a problem.

Enter 'The Mask'.  Everyone would have their own sound stifling hood.  Or
maybe people would just whisper in the workplace.  Might save the voice too.

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

"The pioneer is the one with the arrows in his back."
                          - anonymous entrepreneur

0
8/12/2004 11:56:33 AM
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 :o)  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 :o)

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.

0
8/12/2004 11:59:04 AM
"Andreas Rossberg" <rossberg@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...
0
cr88192355 (1928)
8/12/2004 12:23:59 PM
"cr88192" <cr88192@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
0
ketil (99)
8/12/2004 12:54:30 PM
Ketil Malde wrote:
> 
> 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.

Except that it computes a minimum, and the C version a maximum. :-) The 
devil's in the typo.

>>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?

I guess he means iteration combinators that do not deliver a result but 
only apply their argument for side effects. That's actually what I meant 
with the iter functions I mentioned. They are just an optimised variant 
of map. In SML (where they are usually called app):

   val app = ignore o map

But as we all know, a fold is all you need anyway... :-)

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

Let's get rid of those possible thingies!  -- TB

0
rossberg (600)
8/12/2004 1:11:50 PM
"Ketil Malde" <ketil@ii.uib.no> wrote in message 
news:egy8kkikjd.fsf@ii.uib.no...
> "cr88192" <cr88192@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...



0
cr88192355 (1928)
8/12/2004 2:30:59 PM
"Andreas Rossberg" <rossberg@ps.uni-sb.de> wrote in message 
news:cffqam$7gq5h$1@hades.rz.uni-saarland.de...
> Ketil Malde wrote:
>>
>> 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.
>
> Except that it computes a minimum, and the C version a maximum. :-) The 
> devil's in the typo.
>
>>>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?
>
> I guess he means iteration combinators that do not deliver a result but 
> only apply their argument for side effects. That's actually what I meant 
> with the iter functions I mentioned. They are just an optimised variant of 
> map. In SML (where they are usually called app):
>
>   val app = ignore o map
>
> But as we all know, a fold is all you need anyway... :-)
>
well, something like iter could work, as long as there is input data (and 
whatever isn't just being done by a big glob of code).


well, anyways, if loops prove non-useful then they will likely fade 
eventually anyways. for now I am skeptical, loops and assignment still have 
some life left yet...

their existance and the existance of more functional styles is not 
exclusive.



0
cr88192355 (1928)
8/12/2004 2:40:46 PM
"Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com> wrote in 
message news:2o13jkF5d1naU1@uni-berlin.de...
> R. Alan Monroe wrote:
>> And consider those occasions where
>> you're involved with a member of the opposite sex... going to stop to
>> yell at your stereo to turn the volume up or down?
>
> I would expect kink reverberations between sex act and music play. 
> "Harder,
> harder, louder, harder, harder!"
>
>> I think a MUCH more practical approach is simply to make the packaging
>> glow a different hue or play a quiet simple tune when you pick up the
>> container. Major chords for fresh and minor chords for stale.
>
> I don't think anything's going to change about milk expiration dates at 
> all.
> Aside from this being a solution in search of a problem, there are
> governmental regulations that will be etched in stone, and no commercial
> impetus to change them.
>
I have before wished there were some color changing marker on bowl ramen so 
one wouldn't have to keep track of the time to know when it was done...

it wouldn't exactly be a timer, but probably a chemical that changes color 
eventually when exposed to lots of heat.

>> Maybe it's just me but it seems like a lot of people that grew up on
>> Star Trek and the like think that talking to a computer is useful.
>> What they fail to remember is that in a scripted drama only one person
>> is typically speaking at any given time. Have you ever seen the movie
>> Close Encounters of the Third Kind? Imagine the air traffic control
>> room scene, many times over. Noise and chatter is just not conducive
>> to good concentration. Inadvertently commanding someone else's device
>> is also a problem.
>
> Enter 'The Mask'.  Everyone would have their own sound stifling hood.  Or
> maybe people would just whisper in the workplace.  Might save the voice 
> too.
>
yes, I wish I had that allready. not that I need voice commands or such, 
just more to dampen background noise.

maybe there could be small wireless microphones placed around an area, eg, 
so that a hood like that could selectively dampen off further away noise or 
focus on a specific area without interfering with peoples' general ability 
to hear stuff, and without requiring loudspeakers.

hell, people could also wear decent headphones, but that does not really 
give the ability to selectively hear what is around them...



0
cr88192355 (1928)
8/12/2004 3:01:55 PM
"Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com> wrote in 
message news:2o13boF5iv08U1@uni-berlin.de...
> Stefan Axelsson wrote:
>>
>> With workable voice recognition and speech synthesis you could put
>> computers *everywhere*. Carton of milk: "Milk how old are you?" Or
>> "Milk, tell the fridge when you're one day away from expiration."
>> Coupled with a biological sensor to actually determine when the milk's
>> actually gone bad you could forget about the "use by" date. You could
>> even have the milk tell you: "Please put me back in the fridge now if
>> you want me to last three more days". And that's just one very silly
>> example.
>
> Actually it leads to Hitchhiker's Guide style marketing horrors all too
> quickly.  "Mmm, Milk!  You like milk, Billy, don't you?"  "I thought so.
> Did you know that milk is one of the 4 food groups, Billy?"
>
hmm, yes...

when it goes stale does it start talking foul?...

or maybe they could have the packaging automatically change:
"dairy works homemade cottage cheese".

maybe different kinds of milk turn into different kinds of cheese, or the 
exact kind is chosen randomly and the package just figures out what it is: 
"extra chunky bluegreen-cheddar".
or maybe an occasional: "warning: don't eat".

> Another big paradigm shift would be printable monitor displays.  Read an
> article about that in Wired a few years back if memory serves.  The idea 
> is
> that you could get the fiber optic technology onto sheets of paper and run
> them out of things the size of newspaper printing presses.  Then the 
> amount
> of surface area you'd have for visual display would be huge and cheap. 
> You
> could afford to put these displays on anything.
>
> The advertizing possibilities are equally disgusting.
>
yes, I want cheap foldable monitors. none have really come into existance 
though...

>> When the kids that have grown up in such a surrounding enter the
>> workplace, they'll find the few people how still use keyboards (I
>> would probably be one of the geriatric ones) as quaint old dodgers.
>
> Actually, speaking continuously all day might wear out the voice and lead 
> to
> new workplace injuries.  I certainly have more throat problems now that 
> I'm
> doing voter registration all the time.  I'm not speaking continuously,
> unless it's a high volume area.  Someone told me the trick is to keep
> drinking water, so I do.  It does help.
>
> Well, hopefully the computers are smart enough to allow us to give them
> higher level tasks.
>
or maybe not:
cursor up 5 left 3 doubleclick

or hell, maybe the interface of the future will be a gamepad...
you plug your trusty gamepad into a computer, and later into your cell 
phone, ...
each gives you an onscreen keyboard with which you use to type...

or hell, maybe implantable keyboards with which you type on using your 
thoughts, or maybe just an implantable gamepad...



0
cr88192355 (1928)
8/12/2004 3:19:00 PM
"cr88192" <cr88192@hotmail.com> writes:

> well, depends on whether you want more of a functional or imperative style. 
> in general, I opt for the imperative style.

You can't "opt" for a choice that you don't fully grok, and you don't
write as if you've done much functional or declarative
programming. (Pardon me if I'm mistaken about that.) Spend a month or
two writing //only// side-effect-free code, no matter how much it
hurts, in whatever language you please (you might like
Single-Assignment C <http://www.sac-home.org>). Find out what
constitutes idiomatic code in the chosen language, and try to emulate
that style, until it becomes second-nature. Then you'll be in a
position to make an informed choice.

For me, learning Prolog thoroughly was the best thing that ever
happened to my C code.

Cheers,

-- Joe

-- 
"We sat and watched as this whole       <-- (Died Pretty -- "Springenfall")
 blue sky turned to black..."
.... Re-defeat Bush in '04.
--
pub  1024D/BA496D2B 2004-05-14 Joseph A Knapka
     Key fingerprint = 3BA2 FE72 3CBA D4C2 21E4  C9B4 3230 94D7 BA49 6D2B
If you really want to get my attention, send mail to
jknapka .at. kneuro .dot. net.
0
jknapka (107)
8/12/2004 3:59:39 PM
>
>> 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@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)
------------------------------------------------------------------------------
0
cfc (239)
8/12/2004 6:10:17 PM
Ketil Malde wrote:

> Peter Ashford <me@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. 
> 

Who ever said it was?

A class like "MapUtilities" isn't 'just a collection of functions' - 
that implies an ad hoc collection, whereas a class like that is a 
collection of conceptually related functions which work together in a 
particular domain.

It doesn't quite meet up with the idea of an object in the sense of 
being some parrallel with some kind of actual entity, but in practice 
coding is always dealing with the abstract.
0
me5036 (108)
8/12/2004 9:10:18 PM
["Followup-To:" header set to comp.lang.functional.]
Peter Ashford wrote:
>>>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. 
>
> Who ever said it was?
>
> A class like "MapUtilities" isn't 'just a collection of functions' - 
> that implies an ad hoc collection, whereas a class like that is a 
> collection of conceptually related functions which work together in a 
> particular domain.

You could easily change "class" to "module", "namespace" or "record",
and this sentence would be still valid. The point is that MapUtilities
doesn't use any object-oriented mechanisms, like subtyping, message
passing, dynamic dispatch or inheritance. Therefore usefulness of
MapUtilities-like classes is not an argument in favour of OO.

Best regards,
Tom

-- 
..signature: Too many levels of symbolic links
0
t.zielonka2 (138)
8/12/2004 9:25:26 PM
"Brandon J. Van Every" wrote:

> Of course, cr8, you are a highly unusual special case.  You code like
> bejeezus and can actually barf out all of your own 'starter code'
> quickly.
> The vast majority of people are not as prolific as you are. 
> Unfortunately,
> although you excel at breadth of output, you lack depth of focus.
	...
> I'm like your cardinal opposite.  All design and strategy, no code. 
> :-) ...

Right.  And you both have nearly the same amount of work experience.

> Well, honestly I'd be making better progress right now if the day job
> wasn't getting in the way.

Yep, that signature gathering sure can be a bummer, huh?

-- 
 __ Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
/  \ San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
\__/ My long is strong enough, you know / Strong enough to let you go
    -- Xscape
0
max78 (1220)
8/12/2004 10:33:42 PM
Tomasz Zielonka wrote:

> ["Followup-To:" header set to comp.lang.functional.]
> Peter Ashford wrote:
> 
>>>>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. 
>>
>>Who ever said it was?
>>
>>A class like "MapUtilities" isn't 'just a collection of functions' - 
>>that implies an ad hoc collection, whereas a class like that is a 
>>collection of conceptually related functions which work together in a 
>>particular domain.
> 
> 
> You could easily change "class" to "module", "namespace" or "record",
> and this sentence would be still valid. 

agreed

The point is that MapUtilities
> doesn't use any object-oriented mechanisms, like subtyping, message
> passing, dynamic dispatch or inheritance. Therefore usefulness of
> MapUtilities-like classes is not an argument in favour of OO.

it was never offered as such.
0
me5036 (108)
8/12/2004 10:45:57 PM

"Brandon J. Van Every" wrote:

> 42.  :-)
>
> And yes, it's cross-posted for a reason.
>
> I've been doing a lot of voter registration lately... which is boring, and
> low paying, which causes me to goof off once I'm done working.  So, quite a
> lot of Galactic Civilizations and not a lot of OCaml progress.  It is not a
> loss though.  I've been keeping a notebook of all the ways GalCiv is boring,
> and how I'm going to fix them.  This has led me to a profound insight on the
> nature of intelligence and searching, not to mention game design.
>
> GalCiv suffers from the "unit pushing problem."  As a human being, I spend
> the vast majority of my time futzing with whether this unit is 7 squares
> away from that enemy unit.  In a world of better game AI, it wouldn't be so
> hard to compute regions of safety from enemy units.  However, then I'd still
> have to make a lot of decisions about where to put my units.  I envision an
> architecture with lotsa set operations on regions.  While planning the
> architecture, I notice its O(bad) algorithmic behavior, where 'bad' might be
> n^4, some higher polynomial, or maybe exponential.  All depends on how much
> thinking I want to do, and how much I'm willing to limit the scope of my
> problems.  Maybe I can have my clean architecture if I settle for a board of
> only 16x16 squares.  Maybe that is what a current PC can handle.
> ....
>
> Cheers,                     www.indiegamedesign.com
> Brandon Van Every           Seattle, WA
>
> "The pioneer is the one with the arrows in his back."
>                           - anonymous entrepreneur



For your NxN (high N) collision/effect radius   problem  -- shouldnt some kind
of zonal or quadtree type mechanism  be a good way to knock down the
number of  comparisons required ???   (Zone membership sets to limit comparisons

to current zone set and any overlapped adjacent zones...  ie- your 16x16
implemented
as zones would lower required comparisons by a factor of 256...)
I favor a  cartesian zone method myself, but also make use of those zones for
rollin/rollout of a world map thats too big to fit in memory and large areas of
the
map that can run in an abstract (low detail) mode (while rolled out).

0
Eternal
8/13/2004 1:49:14 AM

cr88192 wrote:

> "Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com> wrote in
> message news:2npsk1F3gnj8U1@uni-berlin.de...
> > Gerry Quinn wrote:
> > >
> > > Of course, shortest path algorithms [or maybe for this example,
> > > influence map algorithms] are trivial, but once you have them you can
> > > start working on the trickier GetSafeLocation() functions.  At that
> > > point you'll be into real AI...
> >
> > Not really.  It's just more map crunching.  It all depends on what is
> meant
> > by 'real' here.  I did say we should embrace our inner cockroach.  "We're
> > all just crunching."
> >
> > > One reason I like C++ is that it gives you a relatively free hand with
> > > the syntax of the languages you build with it!
> >
> > I think the OCaml guys would scoff at that.  OCaml is proven at creating
> > domain-specific languages; it is definitely a "language maker's" tool.
> > That's part of why I've thought it may not be the answer, but it may lead
> me
> > to the answer.  So I'll keep going with it for awhile, even if something
> > turns sour.
> >
> or one can just use c and write their own language in the form of an
> interpreter. one is only mildly constrained by any real aspect of the host
> language in this respect, and largely things can be worked around eventually
> anyways...
> of course, making a decent language is not as easy as it might seem, and one
> is likely to fail miserably (be it in terms of performance or inflexibility
> or whatever) about as much as they are to have success.
> one might also end up relying on designs that feel, if anything, somewhat
> dubious, in which case one is left adding extra crap to notify them if the
> approach decides to blow-up in their face eventually, eg, recently in the
> type system I have been recently relying on the assumption that adler-32
> checksums are sufficiently close to unique for short strings, but given the
> way it works it might still result in conflicts (which would likely be quite
> serious if they can't be handled in a deterministic manner).
>
> I guess existing languages would work, but then you are limited to whatever
> the designer(s) could imagine, and in my experience at least existing
> interpreter sources tend to be quite messy and scary looking, so making
> changes would be difficult...
>
> or something...



Hash table with bucket chains is your only safe way (verifying checksum
for lazy match then doing a precise string match to confirm no overlap)


The question, if you dont use a precise matcher, is:  what impact of an error
that
eventually will occur.   What side effects that potentally could  snowball into
destroying
your simulation's balance could result....


On-the-fly generalized garbage cleanup mechanisms sure does force so much extra
code to
allow proper functionality.     There is no easy(or cheap) solution.

0
Eternal
8/13/2004 2:00:25 AM
> It will have its uses.  I'm in the process of wiring my house for automation
> and I have already tested out a "Star Trek"-like system where my old 733 Mhz
> machine does nothing but listen for the phrase "Computer" by itself.  When
> it does, it replies "Computer here" via SAPI 5 TTS.  Of course, I had to add
> the "I'm sorry Dave, I can't do that" clip to the 'unknown goal' responses
> ;).
> 
>     WTH:)

....which I'm sure will end up being the mandatory geek addition to such 
systems :O)
0
me5036 (108)
8/13/2004 3:10:32 AM
"Joe Knapka" <jknapka@kneuro.net> wrote in message 
news:m3d61wgxg8.fsf@localhost.localdomain...
> "cr88192" <cr88192@hotmail.com> writes:
>
>> well, depends on whether you want more of a functional or imperative 
>> style.
>> in general, I opt for the imperative style.
>
> You can't "opt" for a choice that you don't fully grok, and you don't
> write as if you've done much functional or declarative
> programming. (Pardon me if I'm mistaken about that.) Spend a month or
> two writing //only// side-effect-free code, no matter how much it
> hurts, in whatever language you please (you might like
> Single-Assignment C <http://www.sac-home.org>). Find out what
> constitutes idiomatic code in the chosen language, and try to emulate
> that style, until it becomes second-nature. Then you'll be in a
> position to make an informed choice.
>
I have done a fair amount of scheme coding, with typically a lot less 
assignment (this was forced mostly because 'set!' was awkward).

and I 'opt' for what seems most natural to me with my existing experience 
(and this sentiment is likely shared by many "uneducated" coders as well).
even if I went 'all functional', the typical rest of the coder community 
would have not, and making a lang without/with slightly more restricted 
assignment would lead quite strongly to people not using it.

this kind of thing (along with oddball syntax) was one of the things that 
drove me away eventually (more than any particular issue).
others can be viewed almost as a time dependant constant.

> For me, learning Prolog thoroughly was the best thing that ever
> happened to my C code.
>
maybe, dunno.

me using scheme did reduce the typical ammount of destructive operations 
used on data (and similarly an increased reliance on gc for my c code...).



0
cr88192355 (1928)
8/13/2004 3:27:34 AM
Peter Ashford <me@here.there.com> bored us with:

>> It will have its uses.  I'm in the process of wiring my house for
>> automation and I have already tested out a "Star Trek"-like system
>> where my old 733 Mhz machine does nothing but listen for the phrase
>> "Computer" by itself.  When it does, it replies "Computer here" via
>> SAPI 5 TTS.  Of course, I had to add the "I'm sorry Dave, I can't do
>> that" clip to the 'unknown goal' responses ;).
>>
>>     WTH:)
>
> ...which I'm sure will end up being the mandatory geek addition to
> such systems :O)

Definitely an easter egg in the one we're deploying on a cruise ship next
quarter... ;)

    WTH


0
spamsucks (63)
8/13/2004 3:44:38 AM
"Eternal Vigilance" <wotan@oneeye.com> wrote in message 
news:411C1F9C.A80A716C@oneeye.com...
>
>
> cr88192 wrote:
>
>> "Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com> wrote in
>> message news:2npsk1F3gnj8U1@uni-berlin.de...
>> > Gerry Quinn wrote:
>> > >
>> > > Of course, shortest path algorithms [or maybe for this example,
>> > > influence map algorithms] are trivial, but once you have them you can
>> > > start working on the trickier GetSafeLocation() functions.  At that
>> > > point you'll be into real AI...
>> >
>> > Not really.  It's just more map crunching.  It all depends on what is
>> meant
>> > by 'real' here.  I did say we should embrace our inner cockroach. 
>> > "We're
>> > all just crunching."
>> >
>> > > One reason I like C++ is that it gives you a relatively free hand 
>> > > with
>> > > the syntax of the languages you build with it!
>> >
>> > I think the OCaml guys would scoff at that.  OCaml is proven at 
>> > creating
>> > domain-specific languages; it is definitely a "language maker's" tool.
>> > That's part of why I've thought it may not be the answer, but it may 
>> > lead
>> me
>> > to the answer.  So I'll keep going with it for awhile, even if 
>> > something
>> > turns sour.
>> >
>> or one can just use c and write their own language in the form of an
>> interpreter. one is only mildly constrained by any real aspect of the 
>> host
>> language in this respect, and largely things can be worked around 
>> eventually
>> anyways...
>> of course, making a decent language is not as easy as it might seem, and 
>> one
>> is likely to fail miserably (be it in terms of performance or 
>> inflexibility
>> or whatever) about as much as they are to have success.
>> one might also end up relying on designs that feel, if anything, somewhat
>> dubious, in which case one is left adding extra crap to notify them if 
>> the
>> approach decides to blow-up in their face eventually, eg, recently in the
>> type system I have been recently relying on the assumption that adler-32
>> checksums are sufficiently close to unique for short strings, but given 
>> the
>> way it works it might still result in conflicts (which would likely be 
>> quite
>> serious if they can't be handled in a deterministic manner).
>>
>> I guess existing languages would work, but then you are limited to 
>> whatever
>> the designer(s) could imagine, and in my experience at least existing
>> interpreter sources tend to be quite messy and scary looking, so making
>> changes would be difficult...
>>
>> or something...
>
>
>
> Hash table with bucket chains is your only safe way (verifying checksum
> for lazy match then doing a precise string match to confirm no overlap)
>
well, in my case things have to match at compile time, and the value that is 
generated at compile time needs to match with that generated at runtime.

this is mostly because in c switch only works with constant arguments.

I have been considering a way to work around this, but the main issue is 
that it needs to be deterministic.

one possibility is that the crc's are computed entirely at build time, and 
at runtime the values are fetched from a table (undefined types thus don't 
exist in the crc system).

under this approach I could use consecutive integers if I wanted.
however, then the issue becomes how to effectively construct the tables and 
get them to the type code, and still allow for possibly multiple sets of 
tables.
probably yet more autogenerated code, just this time it has to be inited...

>
> The question, if you dont use a precise matcher, is:  what impact of an 
> error
> that
> eventually will occur.   What side effects that potentally could  snowball 
> into
> destroying
> your simulation's balance could result....
>
higher probability of incorrect type matches for code using the "type crc" 
faccilities. type related issues are particularly serious imo, as then lots 
of bad crap can happen.

>
> On-the-fly generalized garbage cleanup mechanisms sure does force so much 
> extra
> code to
> allow proper functionality.     There is no easy(or cheap) solution.
>
well, this is not for the gc.
it was trying to escape a little from the full requirement of using strings 
everywhere to identify types...



0
cr88192
8/13/2004 3:52:45 AM
cr88192 wrote:
> "Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com>
> wrote in message news:2o13boF5iv08U1@uni-berlin.de...
>> Stefan Axelsson wrote:
>>>
>>> With workable voice recognition and speech synthesis you could put
>>> computers *everywhere*. Carton of milk: "Milk how old are you?" Or
>>> "Milk, tell the fridge when you're one day away from expiration."
>>> Coupled with a biological sensor to actually determine when the
>>> milk's actually gone bad you could forget about the "use by" date.
>>> You could even have the milk tell you: "Please put me back in the
>>> fridge now if you want me to last three more days". And that's just
>>> one very silly example.
>>
>> Actually it leads to Hitchhiker's Guide style marketing horrors all
>> too quickly.  "Mmm, Milk!  You like milk, Billy, don't you?"  "I
>> thought so. Did you know that milk is one of the 4 food groups,
>> Billy?"
>>
> hmm, yes...
>
> when it goes stale does it start talking foul?...
>
> or maybe they could have the packaging automatically change:
> "dairy works homemade cottage cheese".
>
> maybe different kinds of milk turn into different kinds of cheese, or
> the exact kind is chosen randomly and the package just figures out
> what it is: "extra chunky bluegreen-cheddar".
> or maybe an occasional: "warning: don't eat".

I am envisioning so many "Bleu Cheese Of Death" MS food products.  :-)

>> Well, hopefully the computers are smart enough to allow us to give
>> them higher level tasks.
>>
> or maybe not:
> cursor up 5 left 3 doubleclick
>
> or hell, maybe the interface of the future will be a gamepad...
> you plug your trusty gamepad into a computer, and later into your cell
> phone, ...
> each gives you an onscreen keyboard with which you use to type...
>
> or hell, maybe implantable keyboards with which you type on using your
> thoughts, or maybe just an implantable gamepad...

I fear for the cock ring implants that the trendy set is going to start
piercing with.


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

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

0
8/13/2004 7:49:14 AM
Eternal Vigilance wrote:
>
> For your NxN (high N) collision/effect radius   problem  -- shouldnt
> some kind of zonal or quadtree type mechanism  be a good way to knock
> down the
> number of  comparisons required ???   (Zone membership sets to limit
> comparisons
>
> to current zone set and any overlapped adjacent zones...  ie- your
> 16x16 implemented
> as zones would lower required comparisons by a factor of 256...)
> I favor a  cartesian zone method myself, but also make use of those
> zones for rollin/rollout of a world map thats too big to fit in
> memory and large areas of the
> map that can run in an abstract (low detail) mode (while rolled out).

My study of AI map problems indicates that there's no such thing as
hierarchical compression of pathfinding.  If you want correct paths, you
must retain all information.  If you are willing to accept loss of
information, you can have a hierarchy.  That's actually militarily
realistic - you could justify units screwing up when they get to a new area
that they haven't scouted before and don't have any maps.  Still, my current
thinking is I'd like an architecture that can 'globally, flatly' handle a
map of a given size.  With that requirement, it might have to be a pretty
small map.

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

"The pioneer is the one with the arrows in his back."
                          - anonymous entrepreneur


0
8/13/2004 7:54:04 AM
Stefan Axelsson wrote:
>
> Well, to be frank, what bothers me about the Star Trek interface more
> are the control panels more than the speech recognition. They seem to
> consistently get an a awful lot of interaction from just three key
> presses or so, regardless of the problem to be solved. For the type of
> situation I've drawn up I think it actually works: "Computer open the
> door" (or some such) when someone is on the outside and you're inside,
> would actually work fairly well.

They're using a Hollywood UI.  It's a tight integration of the console, the
camera lens, the script doctor, and the actor's line card.  :-)


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

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

0
8/13/2004 7:59:05 AM
Ketil Malde wrote:
> "cr88192" <cr88192@hotmail.com> writes:
>
>> 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?

If he isn't, I am.  It's a fundamental operation.  Everyone using a given
language shouldn't be cooking up their own version of a fundamental
operation, they should all use the same fundamental operation in that
language.  I'm not interested in different software libraries having
funky_+= or kewl_+= or NIH_+= operators in them that all do the same
fundamental thing.

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

"We live in a world of very bright people building
crappy software with total shit for tools and process."
                                - Ed Mckenzie

0
8/13/2004 8:05:53 AM
"Brandon J. Van Every" wrote:

>
> If he isn't, I am.  It's a fundamental operation.  Everyone using a given
> language shouldn't be cooking up their own version of a fundamental
> operation, they should all use the same fundamental operation in that
> language.  I'm not interested in different software libraries having
> funky_+= or kewl_+= or NIH_+= operators in them that all do the same
> fundamental thing.

What other operators comes ad-hocly to your mind  which every functional
language should posses?

Fensterbrett

0
8/13/2004 8:09:31 AM
Brandon J. Van Every wrote:

> They're using a Hollywood UI.  It's a tight integration of the console, the
> camera lens, the script doctor, and the actor's line card.  :-)

Sure, to the point that in the original series they even replaced the 
keypad on the captains chair several times to fit the particular script 
of the show.

They never thought to add a seat belt though. :-)

Stefan,
-- 
Stefan Axelsson  (email at http://www.cs.chalmers.se/~sax)
0
crap1234 (43)
8/13/2004 8:13:34 AM
"Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com> writes:

>> 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?

> If he isn't, I am.  It's a fundamental operation.  Everyone using a given
> language shouldn't be cooking up their own version of a fundamental
> operation, they should all use the same fundamental operation in that
> language.  I'm not interested in different software libraries having
> funky_+= or kewl_+= or NIH_+= operators in them that all do the same
> fundamental thing.

Well, yes, I think I see your point.  It is basically the same
argument that is used for higher order functions, isn't it?

I'm just puzzled that one would prefer a language with no builtin map,
fold, scan, iterate etc, in favor of a built-in += operation, which
is trivial to implement anyway.  

In particular when said language lacks the facilities for constructing
convenient and general map and fold type functionality, and their
implementation results in clunky loops all over the place.

-kzm
-- 
If I haven't seen further, it is by standing in the footprints of giants
0
ketil (99)
8/13/2004 9:20:32 AM
Brandon J. Van Every wrote:
>>
>>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?
> 
> If he isn't, I am.  It's a fundamental operation.

Assignment and addition are fundamental operations. The combined 
operator is merely thin syntactic sugar.

If that sugar is sooo important, how can you live with C not having 
unary assignment operators like -= or ~= for negating a variable in 
place? I actually would have had use for that in my C programming.

> Everyone using a given
> language shouldn't be cooking up their own version of a fundamental
> operation, they should all use the same fundamental operation in that
> language.  I'm not interested in different software libraries having
> funky_+= or kewl_+= or NIH_+= operators in them that all do the same
> fundamental thing.

There are a lot of other equally fundamental and more important 
operations that face similar problems, so I don't see what's so special 
about += and friends that they deserve VIP treatment.

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

Let's get rid of those possible thingies!  -- TB

0
rossberg (600)
8/13/2004 9:33:31 AM
Peter Ashford <me@here.there.com> writes:

> Tomasz Zielonka wrote:

>> You could easily change "class" to "module", "namespace" or "record",
>> and this sentence would be still valid.

> agreed

[...]

> it was never offered as such.

>>>>> Exactly.  I find that in fact the world *does* devide neatly into
>>>>> objects especially when you allow abstract units like "MapUtilities"

I guess I misinterpreted it as "the world does divide neatly into
objects if you change the definition of 'objects'", but I guess
a more accurate interpretation is that "the world does divide neatly
into objects, except for the things that aren't".

-ketil
-- 
If I haven't seen further, it is by standing in the footprints of giants
0
ketil (99)
8/13/2004 10:05:45 AM
In article <slrnchno20.kq0.t.zielonka@zodiac.mimuw.edu.pl>, 
t.zielonka@zodiac.mimuw.edu.pl says...
> ["Followup-To:" header set to comp.lang.functional.]

[Followups repaired - when will people learn to stop trying to disrupt 
threads by removing crossposts, in this case to the ng on which the 
discussion started]

> Peter Ashford wrote:

> > A class like "MapUtilities" isn't 'just a collection of functions' - 
> > that implies an ad hoc collection, whereas a class like that is a 
> > collection of conceptually related functions which work together in a 
> > particular domain.
> 
> You could easily change "class" to "module", "namespace" or "record",
> and this sentence would be still valid. The point is that MapUtilities
> doesn't use any object-oriented mechanisms, like subtyping, message
> passing, dynamic dispatch or inheritance. Therefore usefulness of
> MapUtilities-like classes is not an argument in favour of OO.

The most fundamental 'object-oriented mechanism' is the encapsulation of 
functions along with any instance or static data they operate with.  
Namespaces do not encapsulate functions, at least unless you extend the 
definition of encapsulation, and records do not have functions, while 
'module' could mean anything.  But insofar as they attempt to perform 
such encapsulation, they are precisely attempting to use OO mechanisms.

Note that a class of such functions might well have instance or static 
data added at some time.  And/or it might use inheritance etc, e.g. 
HexMapUtilities and SquareMapUtilities might in principle inherit from 
MapUtilities.  Such concvepts are perfectly natural in OO.

- Gerry Quinn







0
gerryq (1329)
8/13/2004 10:46:00 AM
"Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com> wrote in 
message news:2o39frF67jleU1@uni-berlin.de...
> cr88192 wrote:
>> "Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com>
>> wrote in message news:2o13boF5iv08U1@uni-berlin.de...
>>> Stefan Axelsson wrote:
>>>>
>>>> With workable voice recognition and speech synthesis you could put
>>>> computers *everywhere*. Carton of milk: "Milk how old are you?" Or
>>>> "Milk, tell the fridge when you're one day away from expiration."
>>>> Coupled with a biological sensor to actually determine when the
>>>> milk's actually gone bad you could forget about the "use by" date.
>>>> You could even have the milk tell you: "Please put me back in the
>>>> fridge now if you want me to last three more days". And that's just
>>>> one very silly example.
>>>
>>> Actually it leads to Hitchhiker's Guide style marketing horrors all
>>> too quickly.  "Mmm, Milk!  You like milk, Billy, don't you?"  "I
>>> thought so. Did you know that milk is one of the 4 food groups,
>>> Billy?"
>>>
>> hmm, yes...
>>
>> when it goes stale does it start talking foul?...
>>
>> or maybe they could have the packaging automatically change:
>> "dairy works homemade cottage cheese".
>>
>> maybe different kinds of milk turn into different kinds of cheese, or
>> the exact kind is chosen randomly and the package just figures out
>> what it is: "extra chunky bluegreen-cheddar".
>> or maybe an occasional: "warning: don't eat".
>
> I am envisioning so many "Bleu Cheese Of Death" MS food products.  :-)
>
yep...

maybe the idea is that keeping food in your fridge could be charged as a 
service, and when it goes stale/"transforms into a different food product" 
they charge you an extra fee for the new product "purchased".

>>> Well, hopefully the computers are smart enough to allow us to give
>>> them higher level tasks.
>>>
>> or maybe not:
>> cursor up 5 left 3 doubleclick
>>
>> or hell, maybe the interface of the future will be a gamepad...
>> you plug your trusty gamepad into a computer, and later into your cell
>> phone, ...
>> each gives you an onscreen keyboard with which you use to type...
>>
>> or hell, maybe implantable keyboards with which you type on using your
>> thoughts, or maybe just an implantable gamepad...
>
> I fear for the cock ring implants that the trendy set is going to start
> piercing with.
>
hmm...



0
cr88192355 (1928)
8/13/2004 10:46:07 AM
In article <cffko3$7c8vg$6@hades.rz.uni-saarland.de>, rossberg@ps.uni-
sb.de says...
> Gerry Quinn wrote:
> > 
> > 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.

Well, walking along trees is not unusual in games programming, and most 
of us have succeeded in doing so without too much difficulty.  I assume 
FPs can express certain operations on trees elegantly, but there are 
ways of doing it in OO languages without too much trouble.

The example of a chess program comes to mind.  I'm sure minimax with 
alpha-beta pruning can be elegantly expressed in an FP, and you can 
presumably add a variable if you want to search to a certain depth - but 
these are also pretty simple to express in C++.  Let's make it more 
complicated: add quiescent search (where you keep on searching lines 
with lots of captures until the captures stop, irrespective of the 
target search depth) and transposition tables (where previously analysed 
positions are recognised and their values inserted without further 
analysis).

Are the above especially easily expressed with FP?  

- Gerry Quinn










0
gerryq (1329)
8/13/2004 10:57:50 AM
"Ketil Malde" <ketil@ii.uib.no> wrote in message 
news:egllgjgzrz.fsf@ii.uib.no...
> "Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com> writes:
>
>>> 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?
>
>> If he isn't, I am.  It's a fundamental operation.  Everyone using a given
>> language shouldn't be cooking up their own version of a fundamental
>> operation, they should all use the same fundamental operation in that
>> language.  I'm not interested in different software libraries having
>> funky_+= or kewl_+= or NIH_+= operators in them that all do the same
>> fundamental thing.
>
> Well, yes, I think I see your point.  It is basically the same
> argument that is used for higher order functions, isn't it?
>
yes.
and I have higher order functions as well.

> I'm just puzzled that one would prefer a language with no builtin map,
> fold, scan, iterate etc, in favor of a built-in += operation, which
> is trivial to implement anyway.
>
given a choice, I want everything.
not given a choice, as I am more well skilled in this kind of language.

> In particular when said language lacks the facilities for constructing
> convenient and general map and fold type functionality, and their
> implementation results in clunky loops all over the place.
>
well, yes, this is a detractor, but it is not that signifigant.



0
cr88192355 (1928)
8/13/2004 11:05:36 AM
Gerry Quinn wrote:
> 
>>>A class like "MapUtilities" isn't 'just a collection of functions' - 
>>>that implies an ad hoc collection, whereas a class like that is a 
>>>collection of conceptually related functions which work together in a 
>>>particular domain.
>>
>>You could easily change "class" to "module", "namespace" or "record",
>>and this sentence would be still valid. The point is that MapUtilities
>>doesn't use any object-oriented mechanisms, like subtyping, message
>>passing, dynamic dispatch or inheritance. Therefore usefulness of
>>MapUtilities-like classes is not an argument in favour of OO.
> 
> The most fundamental 'object-oriented mechanism' is the encapsulation of 
> functions along with any instance or static data they operate with.  

Since that's what modules do as well, it can hardly be the most 
fundamental OO mechanism.

> Namespaces do not encapsulate functions, at least unless you extend the 
> definition of encapsulation,

But there is nothing to encapsulate. You seem to envision some strange 
kind of state added at some point in time, but I don't really see that. 
Neither do I believe that you consider doing that a good idea.

> and records do not have functions,

Why should records not contain functions? Remember that you are 
cross-posting to clf here.

> while 'module' could mean anything.

Come on, the meaning of "module" in the context of PLs is at least as 
precise as the meaning of "class". If you want to split hairs: all 
concepts of modules I'm aware of are variations of the same basic idea, 
while I could enumerate at least 3 or 4 notions of class in existing 
languages that are only very loosely related.

> But insofar as they attempt to perform 
> such encapsulation, they are precisely attempting to use OO mechanisms.

I really wonder why it is such a common belief that encapsulation was 
something exclusive to, or even invented by, OO.

Cheers,

	- Andreas

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

Let's get rid of those possible thingies!  -- TB

0
rossberg (600)
8/13/2004 11:30:46 AM
Siegfried Gonzi wrote:
> "Brandon J. Van Every" wrote:
>
>>
>> If he isn't, I am.  It's a fundamental operation.  Everyone using a
>> given language shouldn't be cooking up their own version of a
>> fundamental operation, they should all use the same fundamental
>> operation in that language.  I'm not interested in different
>> software libraries having funky_+= or kewl_+= or NIH_+= operators in
>> them that all do the same fundamental thing.
>
> What other operators comes ad-hocly to your mind  which every
> functional language should posses?

Well, all the similar arithmetic operators.  I can't think of anything else
offhand.  Not being a FP purist, I don't think a FP should declare
arithmetic assignments to be evil as a matter of syntax, demanding a lot of
extraneous hoops to jump through in order to get the job done.

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

Brandon's Law (after Godwin's Law):
"As a Usenet discussion grows longer, the probability of
a person being called a troll approaches one RAPIDLY."

0
8/13/2004 11:55:38 AM
Andreas Rossberg wrote:
> Brandon J. Van Every wrote:
>>>
>>> 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?
>>
>> If he isn't, I am.  It's a fundamental operation.
>
> Assignment and addition are fundamental operations. The combined
> operator is merely thin syntactic sugar.

I don't mind syntactic sugar.  I just want the same syntactic sugar used in
*all* programs for a given langauge.  It could be part of a standard
library.

> If that sugar is sooo important, how can you live with C not having
> unary assignment operators like -= or ~= for negating a variable in
> place? I actually would have had use for that in my C programming.

In my 3D code I've used += -= *= /= far far more frequently than I've used
unary negation or bitwise NOT.

>> Everyone using a given
>> language shouldn't be cooking up their own version of a fundamental
>> operation, they should all use the same fundamental operation in that
>> language.  I'm not interested in different software libraries having
>> funky_+= or kewl_+= or NIH_+= operators in them that all do the same
>> fundamental thing.
>
> There are a lot of other equally fundamental and more important
> operations that face similar problems, so I don't see what's so
> special about += and friends that they deserve VIP treatment.

Ok, name these more important operations?

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

"We live in a world of very bright people building
crappy software with total shit for tools and process."
                                - Ed Mckenzie

0
8/13/2004 12:03:21 PM
Stefan Axelsson wrote:
> Brandon J. Van Every wrote:
>
>> They're using a Hollywood UI.  It's a tight integration of the
>> console, the camera lens, the script doctor, and the actor's line
>> card.  :-)
>
> Sure, to the point that in the original series they even replaced the
> keypad on the captains chair several times to fit the particular
> script
> of the show.
>
> They never thought to add a seat belt though. :-)

Odd, because there were so many other car parts in evidence.  Like the
odometer that goes backwards when they're going back in time!


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

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

0
8/13/2004 12:04:49 PM
On Fri, 13 Aug 2004, Andreas Rossberg wrote:

> I really wonder why it is such a common belief that encapsulation was
> something exclusive to, or even invented by, OO.
>

Because it's not common knowledge that data hiding by way of lexical scope
predates the hardware computer?

-- 
flippa@flippac.org
0
flippa (196)
8/13/2004 12:34:49 PM
Andreas Rossberg wrote:
>
> I really wonder why it is such a common belief that encapsulation was
> something exclusive to, or even invented by, OO.

It is certainly not what I learned in school, as a freshman in 1988 at
Cornell U.  They weren't teaching C++, OO programming, or anything with
classes.  We learned ADTs, typically in Pascal or pseudocode that looked
like Pascal.  C was a 1 page cheat sheet.  "You know Pascal?  Boom, now you
know C."  We didn't have courses in C, we just used it immediately.

I learned C++ on my own, after I graduated in 1992.  I never did buy into
the whole C++ 'idioms' thing.  It was never relevant to the 3D graphics
problems I was working on.  Singleton-Letter classes, WTF?  Fancy names for
bullshit to get things done.

I was certainly an OO programmer though.  I did tremendous amounts of
templated multiple inheritance hierarchies with virtual base classes and
pointers gazoo.  All in the name of conjuring up totally arbitrary 2D screen
rasters, so I could draw arbitrary triangle rasterizations on top of 'em.
It's all pretty horrid, looking back on it.  If anyone wants to see the
monstrosities that resulted, check out
http://www.indiegamedesign.com/Free3d_2004.zip
That's just my old Free3d code reissued with a MIT license.  It never did
much of anything, and I haven't tried to compile it in years.  It's probably
a really good example for how to totally drive yourself nuts in C++ though.

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

Brandon's Law (after Godwin's Law):
"As a Usenet discussion grows longer, the probability of
a person being called a troll approaches one RAPIDLY."






0
8/13/2004 12:56:02 PM
Philippa Cowderoy wrote:
> On Fri, 13 Aug 2004, Andreas Rossberg wrote:
> 
>> I really wonder why it is such a common belief that encapsulation was
>> something exclusive to, or even invented by, OO.
>> 
> 
> Because it's not common knowledge that data hiding by way of lexical
> scope predates the hardware computer?

Do tell, what's the precedent...

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

"The pioneer is the one with the arrows in his back."
                          - anonymous entrepreneur

0
8/13/2004 12:57:08 PM
kzm wrote:
> I'm just puzzled that one would prefer a language with no builtin
> map, fold, scan, iterate etc, in favor of a built-in += operation,
> which is trivial to implement anyway.

I'm not going to defend Brandon's position, at least not completely.
In that I don't think there is an argument that one shouldn't have
built in map, fold, scan, iterate, etc--especially if one's language
is functional.  However, if one's language also supports imperative
constructs (assignment in particular), then the operator assignment
forms should also be built in.  That position is defensible.  

In fact, about 20 years ago in response to what I learned from
Algol-68, it was obvious to me that the syntax for an arbitrary user
defined operation having the same operator assignment form was a
"natural" part of the language--and sat down and designed exact such a
language.  It is also just an natural for the language to have the
"reduction" forms or the operator, which combine the operator with
list iteration (if I understand correctly, fold in other words).

The point being that one should not generally [have to] invent local
versions of such constructs using some sort of macro-preprocessor,
because doing so tends to cause one to invent many potentially
slightly incompatible slang dialects for such things.

In fact, it is the same argument as why map should be a primitive, so
that people don't go off and invent their own local half-baked flavors
of map. Half the criticism of OO languages like C++ are that one tends
to end up with semantically non-rigorous partial implementations of
map (and similar concepts) because the underlying semantics of C++
don't enable/encourage one to use a rigorous version and the language
doesn't provide the function built-in.

That is not to say that one can't do such things via primitives that
combine properly.  However, in the imperative world, there is a subtle
semantic difference between x += 1 and x = x + 1, and that is worth
noting and attending to.  (The difference is due to side-effects.)
This is parallel to the differences between foldl and foldr.  For
associative operators on finite lists, they are the same.  However,
for more subtle cases, they aren't.  When you care, it is important to
be able to express the precise semantics you intend.  When doing that,
it is not good, if everyone goes off and hand-codes some common case
(that may be subtle).

Hope this helps,
-Chris

*****************************************************************************
Chris Clark                    Internet   :  compres@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)
------------------------------------------------------------------------------

0
cfc (239)
8/13/2004 4:47:00 PM
>
> I really wonder why it is such a common belief that encapsulation was 
> something exclusive to, or even invented by, OO.
>
yes, it actually came from feeding objects to birds.
if it happens to be a parrot, then you have pollymorphism, but this is just 
a matter of inheritence.
oh, such troubles living systems are... 



0
cr88192355 (1928)
8/13/2004 5:19:10 PM
In article <sddd61vnfy3.fsf@shell01.TheWorld.com>,
 Chris F Clark <cfc@shell01.TheWorld.com> wrote:
....
> I'm not going to defend Brandon's position, at least not completely.
> In that I don't think there is an argument that one shouldn't have
> built in map, fold, scan, iterate, etc--especially if one's language
> is functional.  However, if one's language also supports imperative
> constructs (assignment in particular), then the operator assignment
> forms should also be built in.  That position is defensible. 
....
> The point being that one should not generally [have to] invent local
> versions of such constructs using some sort of macro-preprocessor,
> because doing so tends to cause one to invent many potentially
> slightly incompatible slang dialects for such things.

Nor of course should they be able to do so via user defined
operator overloading, since that would lead to the same kind
of chaos.

Whatever the semantics of +=, for example, it should apply
exactly the same to any object without allowing the object
any opportunity to change those semantics.  Therefore, again
for example, in a language where assignment binds a name to
an object,

   a = 5
   b = a
   a += 1

we can see that the original object (5) is constant, and
the new value of "a" must be a different object (6), and
naturally "a" and "b" have different values.  Whatever the
subtle differences between "a = a + 1" and "a += 1", in
this respect, in this matter they're constrained to be
the same ... and it would be a shame to allow some type
to overload += to tamper with these semantics so no one
can say in principle which way it works.

   Donn Cave, donn@u.washington.edu
0
Donn
8/13/2004 5:44:42 PM
Chris F Clark wrote:
> In fact, it is the same argument as why map should be a primitive, so
> that people don't go off and invent their own local half-baked flavors
> of map. Half the criticism of OO languages like C++ are that one tends
> to end up with semantically non-rigorous partial implementations of
> map (and similar concepts) because the underlying semantics of C++
> don't enable/encourage one to use a rigorous version and the language
> doesn't provide the function built-in.

C++ provides the 'map' functionality as a standard library function
(std::transform).  I believe that this is the right approach: the core
language should not be burdened with concepts which can go into the standard
library.  (Which is not to say that I support or defend the overall design
of C++.  The language is clearly a mess.)


-- 
Rainer Deyke - rainerd@eldwood.com - http://eldwood.com


0
rainerd (86)
8/13/2004 8:03:16 PM
On Fri, 13 Aug 2004, Brandon J. Van Every wrote:

> Philippa Cowderoy wrote:
> > On Fri, 13 Aug 2004, Andreas Rossberg wrote:
> >
> >> I really wonder why it is such a common belief that encapsulation was
> >> something exclusive to, or even invented by, OO.
> >>
> >
> > Because it's not common knowledge that data hiding by way of lexical
> > scope predates the hardware computer?
>
> Do tell, what's the precedent...
>

The lambda calculus. There's probably some influences before then
(attempts to formalise quantifier notation?).

-- 
flippa@flippac.org
0
flippa (196)
8/13/2004 10:27:11 PM
"Philippa Cowderoy" <flippa@flippac.org> wrote in message 
news:Pine.WNT.4.53.0408132326370.1888@SLINKY...
> On Fri, 13 Aug 2004, Brandon J. Van Every wrote:
>
>> Philippa Cowderoy wrote:
>> > On Fri, 13 Aug 2004, Andreas Rossberg wrote:
>> >
>> >> I really wonder why it is such a common belief that encapsulation was
>> >> something exclusive to, or even invented by, OO.
>> >>
>> >
>> > Because it's not common knowledge that data hiding by way of lexical
>> > scope predates the hardware computer?
>>
>> Do tell, what's the precedent...
>>
>
> The lambda calculus. There's probably some influences before then
> (attempts to formalise quantifier notation?).
>
well, as long as you are not flogging off the "object systems should be 
constructed via use of closures" viewpoint...

this approach is just too awkward ang irregular for general practice imo.

well, yes, closures can hide data at least...
(in my lang I more often call them "annonymous functions" as that term 
sounds less threatening imo...).

ok: my lang has no implicit currying, but it does have explicit currying. I 
do not trust implicit currying, as it is a common problem that a user will 
call a function with a non-matching args list.
now that I remember, I was thinking of going to implement multimethods 
(eventually...).

at least they can give you a 'fun' time, or maybe you'll 'lambda' so hard 
you wont be able to 'return'...



0
cr88192355 (1928)
8/14/2004 1:52:44 AM
In article <cfi8p6$7gq5h$3@hades.rz.uni-saarland.de>, rossberg@ps.uni-
sb.de says...
> Gerry Quinn wrote:
> > 
> > The most fundamental 'object-oriented mechanism' is the encapsulation of 
> > functions along with any instance or static data they operate with.  
> 
> Since that's what modules do as well, it can hardly be the most 
> fundamental OO mechanism.

Why not?  'Module' is a not-very-specific term that means 'an 
independent part of a program.  Those who considered it important were 
groping towards OO.

> > Namespaces do not encapsulate functions, at least unless you extend the 
> > definition of encapsulation,
> 
> But there is nothing to encapsulate. You seem to envision some strange 
> kind of state added at some point in time, but I don't really see that. 
> Neither do I believe that you consider doing that a good idea.

Functions are not 'nothing'.  It is just as important to encapsulate 
functions as data.  And yes, I don't see anything wrong with the idea of 
possibly adding state at some time - it's a perfectly natural thing to 
happen.  I gave the example of 'MapUtilities' that you might at some 
stage want to expand into SquareMapUtilities and HexMapUtilities, and/or 
include a workspace for scratch calculations, or records of useful 
knowledge concerning a particular map that has been attached to an 
instance of it.

And the class methodology allows you to do it, with or without state.  
(Obviously it might be a small nuisance at some time to change from 
static to 'instance' functions, so if you plan to do this you should use 
non-static member functions from the start.)
 
> > But insofar as they attempt to perform 
> > such encapsulation, they are precisely attempting to use OO mechanisms.
> 
> I really wonder why it is such a common belief that encapsulation was 
> something exclusive to, or even invented by, OO.

I didn't say it was invented by OO.  I said it was fundamental to OO.

- Gerry Quinn
0
gerryq (1329)
8/14/2004 10:28:44 AM
On Fri, 13 Aug 2004 00:54:04 -0700, Brandon J. Van Every wrote:

> My study of AI map problems indicates that there's no such thing as
> hierarchical compression of pathfinding.  If you want correct paths, you

Have you looked at Hierarchical A* by Holte et al?

  http://www.csi.uottowa.ca/~holte/Publications/tr-95-18.ps

-- 
mail1dotstofanetdotdk

0
breese (255)
8/14/2004 12:46:50 PM
On Sat, 14 Aug 2004, cr88192 wrote:

>
> "Philippa Cowderoy" <flippa@flippac.org> wrote in message
> news:Pine.WNT.4.53.0408132326370.1888@SLINKY...
> > On Fri, 13 Aug 2004, Brandon J. Van Every wrote:
> >
> >> Philippa Cowderoy wrote:
> >> > On Fri, 13 Aug 2004, Andreas Rossberg wrote:
> >> >
> >> >> I really wonder why it is such a common belief that encapsulation was
> >> >> something exclusive to, or even invented by, OO.
> >> >>
> >> >
> >> > Because it's not common knowledge that data hiding by way of lexical
> >> > scope predates the hardware computer?
> >>
> >> Do tell, what's the precedent...
> >>
> >
> > The lambda calculus. There's probably some influences before then
> > (attempts to formalise quantifier notation?).
> >
> well, as long as you are not flogging off the "object systems should be
> constructed via use of closures" viewpoint...
>
> this approach is just too awkward ang irregular for general practice imo.
>

Well, you don't get any real hiding per se without a type system as well,
but:

pair = \x.\y.\f.f x y
fst = \x.\y.x
snd = \x.\y.y
fst (pair 1 2) = 1

Doesn't seem to differ much from accessor functions as commonly used in
C++. If you set the type system up so fst and snd are the only operations
you can perform on a pair directly, you have exactly the situation where
fst and snd access "private" information. The definition of pair above
neatly captures the idea that pair (and its associated type) are
responsible for deciding what can get at the contents.

> ok: my lang has no implicit currying, but it does have explicit currying. I
> do not trust implicit currying, as it is a common problem that a user will
> call a function with a non-matching args list.

I fail to see how this is a problem - it's no harder to typecheck than the
uncurried version where a function takes a tuple instead.

FWIW, one of the reasons ML-like languages have "all functions take
exactly one argument" as a hard-and-fast rule is it makes it easier to
reason about the type checker. You might find it interesting to take a
look at how type inference works in cases like this.

-- 
flippa@flippac.org
0
flippa (196)
8/14/2004 12:50:52 PM
On Sat, 14 Aug 2004, Gerry Quinn wrote:

> In article <cfi8p6$7gq5h$3@hades.rz.uni-saarland.de>, rossberg@ps.uni-
> sb.de says...
> > Gerry Quinn wrote:
> > >
> > > The most fundamental 'object-oriented mechanism' is the encapsulation of
> > > functions along with any instance or static data they operate with.
> >
> > Since that's what modules do as well, it can hardly be the most
> > fundamental OO mechanism.
>
> Why not?  'Module' is a not-very-specific term that means 'an
> independent part of a program.  Those who considered it important were
> groping towards OO.
>

I disagree - OO is something you can develop from modules, but it is not
the only thing. SML/NJ's higher-order functors (functions on modules, if
you will) demonstrate another possibility.

-- 
flippa@flippac.org
0
flippa (196)
8/14/2004 12:55:33 PM
"Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com> wrote in
news:2nti22F4k9hfU1@uni-berlin.de: 

> Hopefully you realize that us 'old farts' took our classes in things
> like Pascal and C.  In 1988..1992 Cornell U. wasn't even teaching C++! 
> I learned that on my own after college.  Anyways college is not
> vocational training, there's no mandate that anyone should learn the
> flavor-of-the-year language that industry wants to hear about.  That
> said, I think the prevailent languages should be taught if they aren't
> getting in the way of instruction. 

Out of curiosity, what are they teaching on colleges and universities? Is 
there some refference, detailed summary of classhours, or something like 
that?

> 
> I'm doing just fine starting a face-to-face OCaml discussion group in
> Seattle, and a game development mailing list.  The real challenge will
> be convincing paying clients to bite on this stuff.  I don't expect I'll
> get that to happen right away, but some AI proof-of-concept would do
> wonders for what clients are willing to buy.
> 
AI and OCaml?
AI migh need:
Recompilation at runtime.
Readable source code.
Fully lazy compilable source code.
Buffer owerflow/underflow protection build in the programming language 
definition.
Does OCaml have this?

> I don't have any problem with C for its proper domain: low level
> computation.  If I think I'm going to need to turn something into ASM
> someday, I definitely want to write it in "the portable assembler"
C++ isn't portable assembler. It has several reduction in power in 
comparisson to a reasonable assembler combined with smart IDE. 
> first. Properly, my C routines should fit on a page or so.  Functions
> have to be fairly simple and short to be worthy of ASM optimization.  If
> it's going to be more complicated than that, I want a HLL.
> 
> I do have problems with C++.  I like operator overloading and that's
Operator overloading? Even this operator ";"? ^_^ That might be funny. 

-- 
Kizutsuite 'ta ano hi kara 
0
notfor (50)
8/14/2004 2:50:04 PM
On Sat, 14 Aug 2004, Philippa Cowderoy wrote:

> Well, you don't get any real hiding per se without a type system as well,
> but:
>
> pair = \x.\y.\f.f x y
> fst = \x.\y.x
> snd = \x.\y.y
> fst (pair 1 2) = 1
>

A quick correction, as pointed out on clf but not crossposted to cgdpa:

fst = \p.p (\x.\y.x)
snd = \p.p (\x.\y.y)

My bad!

-- 
flippa@flippac.org
0
flippa (196)
8/14/2004 7:58:15 PM
In article <MPG.1b86af0dbbc04ebd98987c@news.indigo.ie>, Gerry Quinn wrote:
> 
> Well, walking along trees is not unusual in games programming, and most 
> of us have succeeded in doing so without too much difficulty.  I assume 
> FPs can express certain operations on trees elegantly, but there are 
> ways of doing it in OO languages without too much trouble.

I came to FP from OO languages, and the difference is astonishingly
large. Whenever you can represent a data structure as a term algebra
(ie, instances of the data type can be generated from a grammar), then
functional languages make writing functions that operate on these
types radically simpler than in conventional languages.

To use the design pattern jargon, any code using the Visitor,
Composite, Interpreter, or Command patterns is a lot simpler when
expressed with functional-style algebraic data types. (Actually having
first-class functions simplifies a lot of other design patterns, too,
but languages like Python and Smalltalk show that first-class
functions are not foreign to OO.)

> The example of a chess program comes to mind.  I'm sure minimax with 
> alpha-beta pruning can be elegantly expressed in an FP, and you can 
> presumably add a variable if you want to search to a certain depth - but 
> these are also pretty simple to express in C++.  Let's make it more 
> complicated: add quiescent search (where you keep on searching lines 
> with lots of captures until the captures stop, irrespective of the 
> target search depth) and transposition tables (where previously analysed 
> positions are recognised and their values inserted without further 
> analysis).
> 
> Are the above especially easily expressed with FP?  

Caveat: I haven't done much game or AI programming.

Basic alpha-beta search is about the same level of complexity as in
C++ or Java, basically because the algorithm itself is simple enough
that there's no complexity to reduce.

I just Googled for transposition tables, and I think they would be
very easy to add to an algorithm. However, from what I see, it doesn't
look like it would be very hard to add this to a search algorithm
written in in an OO language, either. We just want to memoize the
results of analyzing positions, right?

I would guess that most of the real software engineering difficulty in
adding this would be in designing data structures to store positions
in a minimum of space -- but this complexity could be hidden behind a
nice interface, regardless of programming paradigm.

Quiescent search is a little easier to express in a functional
language. That's because functional languages include support for
optimizing tail calls -- that is, when there is nothing to do in the
current function after the call returns, the compiler can de-allocate
the current function's stack frame immediately. 

This lets you write state-machine style code as a set of mutually
recursive functions without running a risk of stack overflow, and so
you can modularize your search code by placing different search modes
in different functions, which tail-call one another to switch mode.
This will get more and more useful as the complexity of your search
code increases.

-- 
Neel Krishnaswami
neelk@cs.cmu.edu
0
neelk (298)
8/14/2004 8:23:00 PM
Raghar wrote:
>
> AI and OCaml?
> AI migh need:
> Recompilation at runtime.

OCaml can be all byte compiled or all natively compiled.  You can't intermix
the two.  This might be a PITA for large systems development, but I'm hoping
it won't prove to be a big deal for the problems I'm working on.

> Readable source code.

OCaml has baroque bits, but a lot of what I see from people is readable in
practice.  The "mainline idiomatic style" that most people use for most code
is pretty clean.

> Fully lazy compilable source code.

Laziness is a religion.  OCaml does have a Lazy module, I don't know if it
suits the taste of a lazy programmer.

> Buffer owerflow/underflow protection build in the programming language
> definition.

Not sure I understand what is meant by this.  Array bounds are checked.  I
don't know about stack growth.

I know all you 'real programmers' just shake your heads at how I approach
problems, but my strategy right now is just not to write code.  Instead, I
keep reading other people's documentation and code until "something sticks."
I figure, I shouldn't have to think real hard to understand something.  I
just let stuff get waved under my nose hundreds of times until my brain just
recognizes this, that, or the other thing from sheer familiarization.  Also,
explanations from human beings are usually better than from docs.  I RTFM
repeatedly but I don't angst about it anymore.  If I don't get something
right away, I just skip it.  Someone else may come along shortly with a
better explanation.

In other words, I let mailing lists and newsgroups do a lot of my thinking
for me.

Meanwhile I'm working on more important issues like algorithms, game design,
libraries and toolchains, community growth, and business viability.  Plus I
have this artist friend of mine who pops up every several months and says,
"Hey!  I've got this new hare-brained idea for getting financing!"  So we go
at it again.  Eventually I suppose we'll actually get somewhere, by the same
rote tactics of slogging it out without thinking much, LOL!

In other words I'm a Lazy Software Architect.  Coding, as far as I'm
concerned, is an implementation detail.  It is also laborious and starts to
paint you into a corner.  What if I were to toss my hat in the ring with
Felix, for instance?  http://felix.sourceforge.net

I *do* hope this makes Xavier shake his head and think so much less of me.
;-)  I'm not sure which of the public forums he follows, or which posts of
mine made him experience the undecideability of laugher or tears.  I bet he
doesn't follow http://groups.yahoo.com/group/ocamlgames/ , which is where
the real world evaluation of OCaml's strengths and weaknesses is getting
done.

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

"We live in a world of very bright people building
crappy software with total shit for tools and process."
                                - Ed Mckenzie

0
8/14/2004 8:51:26 PM
"Bjorn Reese" <breese@see.signature> wrote in message
news:pan.2004.08.14.12.46.46.82396@see.signature...
> On Fri, 13 Aug 2004 00:54:04 -0700, Brandon J. Van Every wrote:
>
> > My study of AI map problems indicates that there's no such thing as
> > hierarchical compression of pathfinding.  If you want correct paths, you
>
> Have you looked at Hierarchical A* by Holte et al?
>
>   http://www.csi.uottowa.ca/~holte/Publications/tr-95-18.ps

That's http://www.csi.uottawa.ca/~holte/Publications/tr-95-18.ps
As in OttAwa.


0
jeu (11)
8/14/2004 11:52:41 PM
Neelakantan Krishnaswami <neelk@cs.cmu.edu> writes:

> I just Googled for transposition tables, and I think they would be
> very easy to add to an algorithm. However, from what I see, it doesn't
> look like it would be very hard to add this to a search algorithm
> written in in an OO language, either. We just want to memoize the
> results of analyzing positions, right?

Surely any pure FP language //could// memoize automatically, since
functions are referentially transparent -- once you've computed the
result for a given combination of parameters, you needn't ever do so
again (though of course it might be desirable to compute rather than
memoize in many cases). Do any FP implementations actually do that?

-- 
"We sat and watched as this whole       <-- (Died Pretty -- "Springenfall")
 blue sky turned to black..."
.... Re-defeat Bush in '04.
--
pub  1024D/BA496D2B 2004-05-14 Joseph A Knapka
     Key fingerprint = 3BA2 FE72 3CBA D4C2 21E4  C9B4 3230 94D7 BA49 6D2B
If you really want to get my attention, send mail to
jknapka .at. kneuro .dot. net.
0
jknapka (107)
8/15/2004 12:51:31 AM
"Philippa Cowderoy" <flippa@flippac.org> wrote in message 
news:Pine.WNT.4.53.0408141332360.1888@SLINKY...
> On Sat, 14 Aug 2004, cr88192 wrote:
>
>>
>> "Philippa Cowderoy" <flippa@flippac.org> wrote in message
>> news:Pine.WNT.4.53.0408132326370.1888@SLINKY...
>> > On Fri, 13 Aug 2004, Brandon J. Van Every wrote:
>> >
>> >> Philippa Cowderoy wrote:
>> >> > On Fri, 13 Aug 2004, Andreas Rossberg wrote:
>> >> >
>> >> >> I really wonder why it is such a common belief that encapsulation 
>> >> >> was
>> >> >> something exclusive to, or even invented by, OO.
>> >> >>
>> >> >
>> >> > Because it's not common knowledge that data hiding by way of lexical
>> >> > scope predates the hardware computer?
>> >>
>> >> Do tell, what's the precedent...
>> >>
>> >
>> > The lambda calculus. There's probably some influences before then
>> > (attempts to formalise quantifier notation?).
>> >
>> well, as long as you are not flogging off the "object systems should be
>> constructed via use of closures" viewpoint...
>>
>> this approach is just too awkward ang irregular for general practice imo.
>>
>
> Well, you don't get any real hiding per se without a type system as well,
> but:
>
> pair = \x.\y.\f.f x y
> fst = \x.\y.x
> snd = \x.\y.y
> fst (pair 1 2) = 1
>
hmm:
pair=fun(x)fun(y)fun(f)f(x)(y);
fst=fun(p)p(fun(x)fun(y)x);
snd=fun(p)p(fun(x)fun(y)y);

fst(pair(1)(2)) => 1

ok, yes, the notation is a lot worse.

> Doesn't seem to differ much from accessor functions as commonly used in
> C++. If you set the type system up so fst and snd are the only operations
> you can perform on a pair directly, you have exactly the situation where
> fst and snd access "private" information. The definition of pair above
> neatly captures the idea that pair (and its associated type) are
> responsible for deciding what can get at the contents.
>
yes.

however, though this can be done, typically it is preferable to use an 
object system built into the language.

>> ok: my lang has no implicit currying, but it does have explicit currying. 
>> I
>> do not trust implicit currying, as it is a common problem that a user 
>> will
>> call a function with a non-matching args list.
>
> I fail to see how this is a problem - it's no harder to typecheck than the
> uncurried version where a function takes a tuple instead.
>
well, I am going on the assumption that users may inadvertantly type f(x) 
when they mean f(x, y) or such...

> FWIW, one of the reasons ML-like languages have "all functions take
> exactly one argument" as a hard-and-fast rule is it makes it easier to
> reason about the type checker. You might find it interesting to take a
> look at how type inference works in cases like this.
>
ok.

at present my lang does not have type inferrence...
at present I also have a hangover.



0
cr88192355 (1928)
8/15/2004 2:56:21 AM
cr88192 wrote:
> 
> at present my lang does not have type inferrence...
> at present I also have a hangover.

Will this result in type inference?  :-)

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

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

0
8/15/2004 5:08:44 AM
Alan Bal jeu wrote:
> "Bjorn Reese" <breese@see.signature> wrote in message
> news:pan.2004.08.14.12.46.46.82396@see.signature...
>> On Fri, 13 Aug 2004 00:54:04 -0700, Brandon J. Van Every wrote:
>>
>>> My study of AI map problems indicates that there's no such thing as
>>> hierarchical compression of pathfinding.  If you want correct
>>> paths, you
>>
>> Have you looked at Hierarchical A* by Holte et al?
>>
>>   http://www.csi.uottowa.ca/~holte/Publications/tr-95-18.ps
>
> That's http://www.csi.uottawa.ca/~holte/Publications/tr-95-18.ps
> As in OttAwa.

I believe I have, but it has been awhile.  Does the paper say you can
hierarchize without losing path info?

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

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

0
8/15/2004 5:09:59 AM
"Neelakantan Krishnaswami" <neelk@cs.cmu.edu> wrote in message 
news:slrnchst53.4l6.neelk@gs3106.sp.cs.cmu.edu...
<snip>

> Quiescent search is a little easier to express in a functional
> language. That's because functional languages include support for
> optimizing tail calls -- that is, when there is nothing to do in the
> current function after the call returns, the compiler can de-allocate
> the current function's stack frame immediately.
>
> This lets you write state-machine style code as a set of mutually
> recursive functions without running a risk of stack overflow, and so
> you can modularize your search code by placing different search modes
> in different functions, which tail-call one another to switch mode.
> This will get more and more useful as the complexity of your search
> code increases.
>
yes, but a lot of non-functional languages also include tail call 
optimization.
similarly, my lang has this, albeit my lang does have some amount of 
functional influence though...

> -- 
> Neel Krishnaswami
> neelk@cs.cmu.edu

hmm: were you one of the dudes at LL2?...



0
cr88192355 (1928)
8/15/2004 5:16:56 AM
"Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com> wrote in 
message news:2o88qsF7hnk2U1@uni-berlin.de...
> cr88192 wrote:
>>
>> at present my lang does not have type inferrence...
>> at present I also have a hangover.
>
> Will this result in type inference?  :-)
>
type inference is a pita to implement afaik.

I haven't been able to really do any coding today either.
this is one of the worst ones recently, but I am generally up to the point 
of starting to be able to do stuff at least.



0
cr88192355 (1928)
8/15/2004 5:21:00 AM
On Sun, 15 Aug 2004 00:51:31 +0000, Joe Knapka wrote:

> Surely any pure FP language //could// memoize automatically, since
> functions are referentially transparent

It would be impractical: the program would shortly run out of memory,
and in many cases recomputation is cheaper than searching for a dictionary.

Another problem is conceptual: not every type of key can be easily looked
up in a dictionary. How to use functions as keys? How to use infinite
lists as keys?

> Do any FP implementations actually do that?

No.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

0
qrczak (1266)
8/15/2004 9:11:07 AM
In article <pan.2004.08.15.09.11.07.486749@knm.org.pl>, Marcin 'Qrczak' Kowalczyk wrote:
> On Sun, 15 Aug 2004 00:51:31 +0000, Joe Knapka wrote:
> 
>> Surely any pure FP language //could// memoize automatically, since
>> functions are referentially transparent
> 
> It would be impractical: the program would shortly run out of memory,
> and in many cases recomputation is cheaper than searching for a dictionary.

<echoes>Mooooorree'ss Lawwwwwwwwww!!!</echoes> hehe...

> Another problem is conceptual: not every type of key can be easily looked
> up in a dictionary. How to use functions as keys? How to use infinite
> lists as keys?

Well, yeah, then don't memoize the complicated stuff.

>> Do any FP implementations actually do that?
> 
> No.

But it's often claimed as a potential advantage of FP. If that's the case,
it's a bit disappointing that nobody's actually tried it. It'd be nice if a
language would let you indicate that a function should be memoized.
"defmemoize" or something... 

-- 
 .:[ dave benjamin: ramen/[sp00] -:- spoomusic.com -:- ramenfest.com ]:.
        "talking about music is like dancing about architecture."
0
ramen (337)
8/15/2004 9:42:21 AM
"Brandon J. Van Every" wrote:

>
> Not sure I understand what is meant by this.  Array bounds are checked.  I
> don't know about stack growth.
>
> I know all you 'real programmers' just shake your heads at how I approach
> problems, but my strategy right now is just not to write code.  Instead, I
> keep reading other people's documentation and code until "something sticks."

Your approach is not that bad. If I had made a similar approach to Clean I
wouldn't have had that many troubles to turn away. Surely, my time was not
wasted and Clean introduced me into the functional programming world.

How did your CommonLisp experience turn out? If I recall it right wasn't there
some flames on comp.lang.lisp?

What, just in case, if you encounter that ML/OCaml will never fullfill what you
plan to produce. Will you distain the languages then? What will you say
nowadays to someone who asks you about your opinion on CommonLisp.

Fensterbrett

0
8/15/2004 11:22:08 AM
"cr88192" <cr88192@hotmail.com> wrote:
>
> type inference is a pita to implement afaik.

It is relatively straight-forward if you design the language
approriately. It is almost impossible for OOPLs, though.

  - Andreas
0
rossberg (600)
8/15/2004 11:39:29 AM
Gerry Quinn <gerryq@DELETETHISindigo.ie> wrote:
> > > 
> > > The most fundamental 'object-oriented mechanism' is the encapsulation of 
> > > functions along with any instance or static data they operate with.  
> > 
> > Since that's what modules do as well, it can hardly be the most 
> > fundamental OO mechanism.
> 
> Why not?  'Module' is a not-very-specific term that means 'an 
> independent part of a program.

As I explained in the part of my posting you skipped this is not true
in the context of programming languages. Unlike for the the term
'class', which you feel is somehow more precise.

> Those who considered it important were 
> groping towards OO.

Now that's a sweeping generalisation that is not at all accurate.
Sometimes quite the opposite, in fact. For example, a reoccuring theme
in work on modules (definitely by people who consider encapsulation
important) has been the connection to classes and overcoming problems
and limitations found there.

> > But there is nothing to encapsulate. You seem to envision some strange 
> > kind of state added at some point in time, but I don't really see that. 
> > Neither do I believe that you consider doing that a good idea.
> 
> Functions are not 'nothing'.  It is just as important to encapsulate 
> functions as data.

But what you described is not encapsulation, it is just grouping.

> And yes, I don't see anything wrong with the idea of 
> possibly adding state at some time - it's a perfectly natural thing to 
> happen.  I gave the example of 'MapUtilities' that you might at some 
> stage want to expand into SquareMapUtilities and HexMapUtilities, and/or 
> include a workspace for scratch calculations, or records of useful 
> knowledge concerning a particular map that has been attached to an 
> instance of it.

I'm not convinced. Sounds like a design nightmare to me. YMMV.

> > > But insofar as they attempt to perform 
> > > such encapsulation, they are precisely attempting to use OO mechanisms.
> > 
> > I really wonder why it is such a common belief that encapsulation was 
> > something exclusive to, or even invented by, OO.
> 
> I didn't say it was invented by OO.  I said it was fundamental to OO.

No, and I didn't intend to imply that you did. Sorry if that was
unclear. Nevertheless, I've heard it more than once.

What you said, though, was that it actually was the "most fundamental"
aspect of OO. To me, this implies that you consider it the primary
feature that sets OO apart from other approaches. And I dispute that,
because that feature is in no way unique to OO.

What sets OO apart is that it builds a whole philosophy around a
*particular way* for achieving encapsulation, namely including
functions as part of the value.

Cheers,

  - Andreas
0
rossberg (600)
8/15/2004 12:07:12 PM
"Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com>
wrote:
> >
> > Assignment and addition are fundamental operations. The combined
> > operator is merely thin syntactic sugar.
> 
> I don't mind syntactic sugar.  I just want the same syntactic sugar used in
> *all* programs for a given langauge.  It could be part of a standard
> library.

Yes, precisely. But that requires the language to be expressive enough
to be able to implement it as a library.

> In my 3D code I've used += -= *= /= far far more frequently than I've used
> unary negation or bitwise NOT.

That may will be so, but it is domain specific, and there is no clear
line to draw for what should be built-in. So it should clearly be
considered a library issue.

But anyway, all I'm saying is that this is really really a moot point
in a sufficiently expressive language.

> > There are a lot of other equally fundamental and more important
> > operations that face similar problems, so I don't see what's so
> > special about += and friends that they deserve VIP treatment.
> 
> Ok, name these more important operations?

Well, all kinds. IMO, C's lack of tuples, lists, first-class functions
and common operations on them is much more serious, to name just a
few. And you cannot easily do those yourself (and what's in the C++
stdlib is a lame substitute).

Cheers,

  - Andreas
0
rossberg (600)
8/15/2004 12:21:03 PM
"Siegfried Gonzi" <siegfried.gonzi@kfunigraz.ac.at> wrote in message 
news:411F4760.6E557519@kfunigraz.ac.at...
> "Brandon J. Van Every" wrote:
>
>>
>> Not sure I understand what is meant by this.  Array bounds are checked. 
>> I
>> don't know about stack growth.
>>
>> I know all you 'real programmers' just shake your heads at how I approach
>> problems, but my strategy right now is just not to write code.  Instead, 
>> I
>> keep reading other people's documentation and code until "something 
>> sticks."
>
> Your approach is not that bad. If I had made a similar approach to Clean I
> wouldn't have had that many troubles to turn away. Surely, my time was not
> wasted and Clean introduced me into the functional programming world.
>
> How did your CommonLisp experience turn out? If I recall it right wasn't 
> there
> some flames on comp.lang.lisp?
>
> What, just in case, if you encounter that ML/OCaml will never fullfill 
> what you
> plan to produce. Will you distain the languages then? What will you say
> nowadays to someone who asks you about your opinion on CommonLisp.
>
hmm...
I am unsure of my oppinion of scheme and common lisp anymore...

imo they were decent, albeit the syntax was in general more of a negative 
point than a positive one (yes, cool things were possible, but at the cost 
that it is difficult to get people to use it...).
oh well, this may not matter much.

many of the other features can and have been duplicated in others (the 
syntax is one of the main distinguishing factors, well, along with "apply 
everything" and the macro system, but these are related to the syntax...).

or something...



0
cr88192355 (1928)
8/15/2004 3:18:27 PM
"Andreas Rossberg" <rossberg@ps.uni-sb.de> wrote in message 
news:b20b8d03.0408150421.423f9d56@posting.google.com...
> "Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com>
> wrote:
>> >
>> > Assignment and addition are fundamental operations. The combined
>> > operator is merely thin syntactic sugar.
>>
>> I don't mind syntactic sugar.  I just want the same syntactic sugar used 
>> in
>> *all* programs for a given langauge.  It could be part of a standard
>> library.
>
> Yes, precisely. But that requires the language to be expressive enough
> to be able to implement it as a library.
>
I would rather have it as part of the core language.

>> In my 3D code I've used += -= *= /= far far more frequently than I've 
>> used
>> unary negation or bitwise NOT.
>
> That may will be so, but it is domain specific, and there is no clear
> line to draw for what should be built-in. So it should clearly be
> considered a library issue.
>
dunno, += and friends seem pretty general to me, and have a great many uses 
(along with ++ and --).

> But anyway, all I'm saying is that this is really really a moot point
> in a sufficiently expressive language.
>
dunno.

>> > There are a lot of other equally fundamental and more important
>> > operations that face similar problems, so I don't see what's so
>> > special about += and friends that they deserve VIP treatment.
>>
>> Ok, name these more important operations?
>
> Well, all kinds. IMO, C's lack of tuples, lists, first-class functions
> and common operations on them is much more serious, to name just a
> few. And you cannot easily do those yourself (and what's in the C++
> stdlib is a lame substitute).
>
(or, to turn it around):

well, you have function pointers at least.

yes, they don't have lexical scope (this is lame, but not unworkable).

you can put them in a struct if needed:
typedef struct func_s {
void *(*func)(struct func_s *, void *, ...);
void *data;
}func_t;

(this approach is common for many of my api's and such...).

lists are not that hard to implement either imo (err, if you can tolerate 
ugly things...).
consider linked lists, and the common:
while(cur)
{
    //do-whatever
    cur=cur->next;
}
style loops.

in the case of c, these are only a minor inconvinience, for a lang that can 
do so much else (like directly using os api's, or having a fairly consistent 
assembler-level interface...).

ffi's are often only a crude immitation of this, and we don't even get full 
pointer semantics most of the time (what? no pointers, how can anything get 
done?!...).

and all it asks in return is slightly big/ugly code...



0
cr88192355 (1928)
8/15/2004 3:44:50 PM
Dave Benjamin <ramen@lackingtalent.com> wrote:
> > 
> >> Surely any pure FP language //could// memoize automatically, since
> >> functions are referentially transparent
> > 
> > It would be impractical: the program would shortly run out of memory,
> > and in many cases recomputation is cheaper than searching for a dictionary.
> 
> <echoes>Mooooorree'ss Lawwwwwwwwww!!!</echoes> hehe...

Since something equivalent to Moore's Law also applies to the size of
programs the problem would never go away. And even if you accept to
trade huge amounts of space, the net effect on time is not at all
ensured to be positive (besides costs of hash lookup itself, consider
caching issues). It highly depends on the complexity of the function
in question, and complexity cannot be analysed by a compiler.

> > Another problem is conceptual: not every type of key can be easily looked
> > up in a dictionary. How to use functions as keys? How to use infinite
> > lists as keys?
> 
> Well, yeah, then don't memoize the complicated stuff.

But wouldn't that be precisely the stuff where hashing pays off?

> >> Do any FP implementations actually do that?
> > 
> > No.
> 
> But it's often claimed as a potential advantage of FP.

Mh, I don't know of any informed person having ever claimed that.

> If that's the case,
> it's a bit disappointing that nobody's actually tried it. It'd be nice if a
> language would let you indicate that a function should be memoized.
> "defmemoize" or something...

I believe this indeed has been tried, at least I vaguely remember a
discussion about a memo combinator for Haskell some years ago.

Cheers,

- Andreas
0
rossberg (600)
8/15/2004 5:09:11 PM
On Sun, 15 Aug 2004, cr88192 wrote:

>
> "Andreas Rossberg" <rossberg@ps.uni-sb.de> wrote in message
> news:b20b8d03.0408150421.423f9d56@posting.google.com...
> > Yes, precisely. But that requires the language to be expressive enough
> > to be able to implement it as a library.
> >
> I would rather have it as part of the core language.
>

Why? If it's in a standard library people know that part of the namespace
is gone already. And by the time an optimiser's got to it there shouldn't
be any difference between a=a+b and a+=b anyway.

-- 
flippa@flippac.org
0
flippa (196)
8/15/2004 8:33:16 PM
"Siegfried Gonzi" <siegfried.gonzi@kfunigraz.ac.at> wrote in message
news:411F4760.6E557519@kfunigraz.ac.at...
> "Brandon J. Van Every" wrote:
> >
> > I know all you 'real programmers' just shake your heads at how I
approach
> > problems, but my strategy right now is just not to write code.  Instead,
I
> > keep reading other people's documentation and code until "something
sticks."
>
> Your approach is not that bad. If I had made a similar approach to Clean I
> wouldn't have had that many troubles to turn away. Surely, my time was not
> wasted and Clean introduced me into the functional programming world.
>
> How did your CommonLisp experience turn out? If I recall it right wasn't
there
> some flames on comp.lang.lisp?

I didn't put much into Lisp.  Lack of SSE instructions turned me off, but
that wasn't a dealbreaker as pretty much nobody has 'em.

Culture *surrounding* this lack definitely turned me off, i.e. "Why don't
you just pay Corman Lisp your nice money and just implement it?"  Because
I'm not interested in paying other people to do fucking work, that's why.
I'm looking for solutions, not headaches.  "It'll take a few days" is
bullshit, it'll take a few months.  This 'roll your own' mentality seemed to
pervade the Lisp community.  Lotsa fragmented implementations and C FFIs
that don't agree with each other.  Also I didn't care for the 'old grouch
has been' mentality.  Lisp *could* have gone somewhere, and it didn't.  Its
brand identity is now spent.  Someone correctly observed that they could
still sell Lisp, as long as they're willing to call it something other than
Lisp.

Oh yeah, and the Franz Lisp guy was a total ass.  Arrogant, "it's your fault
if... you haven't done your homework... you're a bad developer..." kind of
customer service ethic.  In contrast, the Intel C++ guy is a total
sweetheart.  If I can't get rid of C/C++ land, if I'm stuck with
interoperating to some degree, I will eventually check out the Intel
compiler.

The dealbreaker was no open source version that ran on Windows.  Also, no
remote chance that CMU Lisp would be easy to port (I did investigate).
Corman Lisp was only $200, but I'm not willing to pay for things I consider
incomplete.  I'm willing to help complete things if they're open source.

Also I want the open source momentum, not $200 fragmentation barriers to
harnessing other people.  $200 for something is ok when the language is
already popular, i.e. you can get lotsa C++, Java, or C# programmers and it
doesn't matter if they choose to use a tool that costs $$.  Whereas with the
Lisp community's various incompatible C FFIs, I wouldn't be working with
just the small Lisp community.  I'd be working with the even smaller Corman
Lisp community.

> What, just in case, if you encounter that ML/OCaml will never fullfill
what you
> plan to produce. Will you distain the languages then? What will you say
> nowadays to someone who asks you about your opinion on CommonLisp.

Scheme was clearly an alternative to Lisp, with several projects with much
better Windows support and licenses.  So I've earmarked Scheme if OCaml
doesn't work out.

OCaml is unified, unlike the Scheme universe.  The Standard ML universe
doesn't matter from an industrial standpoint.  They're academics, they don't
take marketing or industrialization seriously.  OCaml is an academic product
as well, but more nods have been made to practicality.  OCaml has emerged as
the language with the momentum in ML-land.  That said, OCaml has a long ways
to go before it's at Python levels of industrialization.

Python, in turn, has a long way to go before it can touch Java and C#.  If
Python could actually solve its performance problems, I wouldn't have much
interest in OCaml.  Python also can't solve its marketing problems.  Guido
and the PSF are techies and just don't understand world conquest in the
Microsoft sense.  We went round and round with trying to get decent
websites, logos, and marketing materials together, and the PSF proved to be
nothing but an obstruction.  Maybe in a few years, Python will just get
bigger than its progenitors, then real marketing will happen.

The main things bugging me about OCaml are a so-so C FFI and baroque syntax.
I'm worried about selling this to game developers as a successor to C++.
Also, the language principles and I are starting to dislike each other.
More accurately, I'm starting to dislike them; I think they've disliked me
from the outset, they're just less polite about it now.  Increasingly, for
industrialization problems, I'm seeing all academics as obstacles to be
routed around.  They don't share core concerns with a game developer or an
entrepreneur.

I'm currently looking at Felix.  http://felix.sourceforge.net  It looks like
it could solve C FFI, syntax, and "friendliness to the C/C++ developer"
issues.  It may even get a C++ FFI at some point, but that is not done.  The
author is oriented towards direct import of C/C++ libraries, and he has
tried to write games with it.  The main thing lacking, of course, is
critical mass.  One of the main things I'm trying to determine, this week,
is if the author is serious about dealing with the critical mass problem.
So many language authors just want to work on their language, rather than
spend some %X of their time promoting it.

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

When no one else sells courage, supply and demand take hold.

0
8/15/2004 11:44:10 PM
"Andreas Rossberg" <rossberg@ps.uni-sb.de> wrote in message
news:b20b8d03.0408150421.423f9d56@posting.google.com...
> "Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com>
>
> > In my 3D code I've used += -= *= /= far far more frequently than I've
used
> > unary negation or bitwise NOT.
>
> That may will be so, but it is domain specific, and there is no clear
> line to draw for what should be built-in. So it should clearly be
> considered a library issue.

Sure there's a line: the line of extant industrial practice.  Including
these operators is not controversial from a C/C++ coder's point of view.

> > > There are a lot of other equally fundamental and more important
> > > operations that face similar problems, so I don't see what's so
> > > special about += and friends that they deserve VIP treatment.
> >
> > Ok, name these more important operations?
>
> Well, all kinds. IMO, C's lack of tuples, lists, first-class functions
> and common operations on them is much more serious, to name just a
> few.

This has nothing to do with += *= operators.

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

"We live in a world of very bright people building
crappy software with total shit for tools and process."
                                - Ed Mckenzie

0
8/15/2004 11:49:28 PM
cr88192 wrote:
> ...
>>>>Assignment and addition are fundamental operations. The combined
>>>>operator is merely thin syntactic sugar.
>>>
>>>I don't mind syntactic sugar.  I just want the same syntactic sugar used 
>>>in
>>>*all* programs for a given langauge.  It could be part of a standard
>>>library.
>>
>>Yes, precisely. But that requires the language to be expressive enough
>>to be able to implement it as a library.
> 
> I would rather have it as part of the core language.

why, esp. in functional languages?  the combined operators re syntactic 
sugar for assignments, something a functional language tries to discourage.

if you expect builtin operators to generate better code, have a look at 
what a decent optimizer can do

> ...

hs
0
hs60 (77)
8/16/2004 12:07:05 AM
"Philippa Cowderoy" <flippa@flippac.org> wrote in message 
news:Pine.WNT.4.53.0408152131360.1900@SLINKY...
> On Sun, 15 Aug 2004, cr88192 wrote:
>
>>
>> "Andreas Rossberg" <rossberg@ps.uni-sb.de> wrote in message
>> news:b20b8d03.0408150421.423f9d56@posting.google.com...
>> > Yes, precisely. But that requires the language to be expressive enough
>> > to be able to implement it as a library.
>> >
>> I would rather have it as part of the core language.
>>
>
> Why? If it's in a standard library people know that part of the namespace
> is gone already. And by the time an optimiser's got to it there shouldn't
> be any difference between a=a+b and a+=b anyway.
>
maybe it is just me...

I am more used to certain things being part of the core and parts being 
library, and this here is disagreeing with the usual notion...

usually, everything syntactic is part of the core, and everything involving 
operator overloading, functions, or non-primitive types is part of the 
library.
this may not be relevant here though.

otherwise it is not much of a difference.



0
cr88192355 (1928)
8/16/2004 2:58:40 AM
"Hartmann Schaffer" <hs@hartmann.schaffernet> wrote in message 
news:HVSTc.843$H23.9825@newscontent-01.sprint.ca...
> cr88192 wrote:
>> ...
>>>>>Assignment and addition are fundamental operations. The combined
>>>>>operator is merely thin syntactic sugar.
>>>>
>>>>I don't mind syntactic sugar.  I just want the same syntactic sugar used 
>>>>in
>>>>*all* programs for a given langauge.  It could be part of a standard
>>>>library.
>>>
>>>Yes, precisely. But that requires the language to be expressive enough
>>>to be able to implement it as a library.
>>
>> I would rather have it as part of the core language.
>
> why, esp. in functional languages?  the combined operators re syntactic 
> sugar for assignments, something a functional language tries to 
> discourage.
>
well, I am comming from an imperative perspective, I expect languages to let 
me do c-like stuff with them w/o extra hassles.

if a language tries to discourage any coding approach, this seems like a 
negative point (even if the language does end up as a huge ugly mess as a 
result).
imo the point of languages is to try to let people write code, and not to 
control how they write the code or "educate" them about something.

constraining detail features of a language are implementation details that 
need to be worked around eventually, and are not intended to be a philosophy 
imo...

> if you expect builtin operators to generate better code, have a look at 
> what a decent optimizer can do
>
well, in my case it is more that the idea of needing to include a library 
for primitive operations (even if they are sugar) seems distasteful...



0
cr88192355 (1928)
8/16/2004 3:07:03 AM
> Oh yeah, and the Franz Lisp guy was a total ass.  Arrogant, "it's your fault
> if... you haven't done your homework... you're a bad developer..." kind of
> customer service ethic.  In contrast, the Intel C++ guy is a total
> sweetheart.  If I can't get rid of C/C++ land, if I'm stuck with
> interoperating to some degree, I will eventually check out the Intel
> compiler.
> 
> The dealbreaker was no open source version that ran on Windows.

Umm.... CLISP?  http://clisp.cons.org/


0
me5036 (108)
8/16/2004 3:17:57 AM
cr88192 wrote:

>
> hmm...
> I am unsure of my oppinion of scheme and common lisp anymore...
>
> imo they were decent, albeit the syntax was in general more of a negative
> point than a positive one (yes, cool things were possible, but at the cost
> that it is difficult to get people to use it...).
> oh well, this may not matter much.
>

Strange. I experienced the  opposite: I have thrown away Python in favor of
Bigloo. It is so much more pleasant to read Scheme code than Python code.

Surely, I am not a web designer or web application programmer. That could
explain why I actually rate Python upper class crap.

And again my cheerleading: Bigloo (and all the other major Scheme
distributions) has a lot more to offer than what you might get from skimming
over R5RS manuals!

Fensterbrett


0
8/16/2004 7:23:21 AM
"Brandon J. Van Every" wrote:

>  This 'roll your own' mentality seemed to
> pervade the Lisp community.  Lotsa fragmented implementations and C FFIs
> that don't agree with each other.

They lay to much attention on the CommonLisp standard. The much I applaud such
an undertaking the more one must say that it is doomed to fail.

Surely, Scheme world is much more cluttered but there  is/was never a problem
to introduce new things.

Some even do not consider Bigloo a real Scheme and vote for a single
implementation instead. We would have then: Perl, Python, Ruby, Bigloo,
DrScheme (PLT), Chicken,...

Not a bad idea I would assume.


>
> OCaml is unified, unlike the Scheme universe.  The Standard ML universe
> doesn't matter from an industrial standpoint.  They're academics, they don't
> take marketing or industrialization seriously.  OCaml is an academic product
> as well, but more nods have been made to practicality.  OCaml has emerged as
> the language with the momentum in ML-land.  That said, OCaml has a long ways
> to go before it's at Python levels of industrialization.

Just for the gossip: If you carefully study the OCaml distribution you will see
some code snippets from Manuel S. He worked during his PhD in the OCaml team, I
assume. Now he is the boss behind Bigloo. In former days -as far as I can
remember - there were even some interoperabilty between Bigloo and OCaml code.



> The main things bugging me about OCaml are a so-so C FFI and baroque syntax.
> I'm worried about selling this to game developers as a successor to C++.
> Also, the language principles and I are starting to dislike each other.

The big tradgedy in that world: Clean! Clean has all the good syntax.
Disadvantage: Clean  is used by assumingly only 20 people around the world. It
had a bright future, though.

>
> More accurately, I'm starting to dislike them; I think they've disliked me
> from the outset, they're just less polite about it now.  Increasingly, for
> industrialization problems, I'm seeing all academics as obstacles to be
> routed around.  They don't share core concerns with a game developer or an
> entrepreneur.

What I gather from fa.caml: I think they do not dislike you. But I must
honestly say that your noise and approach seems a bit odd.

Even if you do not like OCaml, you should start to program a little bit in it.
It took me around 1 year to get used to Clean (functional prohramming).
However, I have jettisoned the idea to program exclusively in functional
programming style. It is simply not true that pure functional programming style
leads to better code and readability as the proponents of the paradigm want to
make you believe. Surely a map, and fold is cool, but once they  get used  in
form of 10 different of such constructs in one single line you are lost
eventually?

From that point of view: OCaml shines due to their loops. Also Scheme shines in
that respect.

Also what functional programming proponents often forget: a good basic
understanding of general constructs or paradigms, e.g. object oriented
programming, search trees, how to organize your data and code and things like
that are often more important than to know how to implement a foldr and foldl
construct,

Fensterbrett

0
8/16/2004 7:47:35 AM
"Siegfried Gonzi" <siegfried.gonzi@kfunigraz.ac.at> wrote in message 
news:412060E8.2CAF6FD0@kfunigraz.ac.at...
> cr88192 wrote:
>
>>
>> hmm...
>> I am unsure of my oppinion of scheme and common lisp anymore...
>>
>> imo they were decent, albeit the syntax was in general more of a negative
>> point than a positive one (yes, cool things were possible, but at the 
>> cost
>> that it is difficult to get people to use it...).
>> oh well, this may not matter much.
>>
>
> Strange. I experienced the  opposite: I have thrown away Python in favor 
> of
> Bigloo. It is so much more pleasant to read Scheme code than Python code.
>
yes, an odd view it seems.

usually my experience was people whining about the parens and the prefix 
math notation:
(+ (* 3 3) (* 4 4)) vs. 3*3+4*4

> Surely, I am not a web designer or web application programmer. That could
> explain why I actually rate Python upper class crap.
>
personally I didn't like python that much, for me the main negative points 
would likely be the syntax and object systems.

> And again my cheerleading: Bigloo (and all the other major Scheme
> distributions) has a lot more to offer than what you might get from 
> skimming
> over R5RS manuals!
>
yes, bigloo had a decent c ffi afaik (or am I thinking of chicken, I can't 
remember...).

I had my own implementation that had a feature set a lot closer to r5rs 
(well, with the major exception of a lack of hygenic macros, I just had 
defmacro, and I had some amount of "weird" stuff).

mine sucked, with good reason.
now I have a new language, which I wonder if I will be able to make at least 
half-decent...

all for now.



0
cr88192355 (1928)
8/16/2004 7:58:23 AM
cr88192 wrote:

>
> usually my experience was people whining about the parens and the prefix
> math notation:
> (+ (* 3 3) (* 4 4)) vs. 3*3+4*4

Where is the problem here?

Even at lengthy formulas the Scheme code does not get into ones way.

However, how often does a web application programmer or business type
programmer  (equal the mass) have to deal with formulas?

(define (strange x y z)
   (*  (x y z)
         (+ (* (- x y)
                   (/ x z))
              (/ y (* x x x)))))

define strange x y z:
      ((x/y)/z) * ((x-y)*(x/z) + (y/(3*x))


Fensterbrett
PS: My Emacs knowledge is zero. However, I have to use it because Bigloo ships
with Bee which is based on Emacs. I use mostly the mouse under Emacs and I know
3 or 4 key combinations. But I never had to count any parenthesis.

0
8/16/2004 8:42:16 AM
"Siegfried Gonzi" <siegfried.gonzi@kfunigraz.ac.at> wrote in message 
news:41207368.5BD998EF@kfunigraz.ac.at...
> cr88192 wrote:
>
>>
>> usually my experience was people whining about the parens and the prefix
>> math notation:
>> (+ (* 3 3) (* 4 4)) vs. 3*3+4*4
>
> Where is the problem here?
>
well, the fact that the former looks different than the latter.

> Even at lengthy formulas the Scheme code does not get into ones way.
>
this depends on who is saying it.
I personally didn't have a problem with this, albeit I didn't really like 
the way s-exps looked in general though.

> However, how often does a web application programmer or business type
> programmer  (equal the mass) have to deal with formulas?
>
> (define (strange x y z)
>   (*  (x y z)
>         (+ (* (- x y)
>                   (/ x z))
>              (/ y (* x x x)))))
>
> define strange x y z:
>      ((x/y)/z) * ((x-y)*(x/z) + (y/(3*x))
>
with operator precedence, a few more parens could be eliminated:
x/y/z*((x-y)*x/z + y/3*x)

>
> Fensterbrett
> PS: My Emacs knowledge is zero. However, I have to use it because Bigloo 
> ships
> with Bee which is based on Emacs. I use mostly the mouse under Emacs and I 
> know
> 3 or 4 key combinations. But I never had to count any parenthesis.
>
parens counting becomes an issue when using notepad...

I could use emacs decently well myself.


there is not really a good/clear reason why there is a problem with 
s-expressions, one would likely need to go into more subjective realms to 
understand this...

or something.



0
cr88192355 (1928)
8/16/2004 8:55:09 AM
Peter Ashford wrote:
>> Oh yeah, and the Franz Lisp guy was a total ass.  Arrogant, "it's
>> your fault if... you haven't done your homework... you're a bad
>> developer..." kind of customer service ethic.  In contrast, the
>> Intel C++ guy is a total sweetheart.  If I can't get rid of C/C++
>> land, if I'm stuck with interoperating to some degree, I will
>> eventually check out the Intel compiler.
>> 
>> The dealbreaker was no open source version that ran on Windows.
> 
> Umm.... CLISP?  http://clisp.cons.org/

*and* compiles to native code.  Sorry, forgot that bit.

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

"We live in a world of very bright people building
crappy software with total shit for tools and process."
                                - Ed Mckenzie


0
8/16/2004 9:34:21 AM
"Brandon J. Van Every" wrote:

> It really
> disturbs me how normative the tastes of a Bayesian spam filter can
> become.
> Spam filter says something is 'not normal'.  Cranky people agree that
> I'm
> not normal and that they don't like what I post.  Non-cranky people
> don't
> say anything, but meanwhile, public perception shifts towards the idea
> that
> it's best for people to have 'normal' behavior.

That's right, it's got to be the fault of a Bayesian filter!  Nothing at
all to do with your propensity to behave like an ass.

-- 
 __ Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
/  \ San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
\__/ I dream things that never were and say, "Why not?"
    -- Robert F. Kennedy (after George Bernard Shaw)
0
max78 (1220)
8/16/2004 9:41:33 AM
Siegfried Gonzi wrote:
> "Brandon J. Van Every" wrote:
>>
>> More accurately, I'm starting to dislike them; I think they've
>> disliked me from the outset, they're just less polite about it now.
>> Increasingly, for industrialization problems, I'm seeing all
>> academics as obstacles to be routed around.  They don't share core
>> concerns with a game developer or an entrepreneur.
>
> What I gather from fa.caml: I think they do not dislike you. But I
> must honestly say that your noise and approach seems a bit odd.

Sure it's odd.  OCaml also hasn't gotten certain things done yet, so they
need someone else in their gene pool other than what's 'normal'.  It really
disturbs me how normative the tastes of a Bayesian spam filter can become.
Spam filter says something is 'not normal'.  Cranky people agree that I'm
not normal and that they don't like what I post.  Non-cranky people don't
say anything, but meanwhile, public perception shifts towards the idea that
it's best for people to have 'normal' behavior.  Maybe even that the
Bayesian filter should be praised!  This strikes me as a local minima in
some hill climbing problem of language growth.  "Trapped in the bowl," so to
speak.

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

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

0
8/16/2004 9:46:37 AM
"Brandon J. Van Every" wrote:

>
> Sure it's odd.  OCaml also hasn't gotten certain things done yet, so they
> need someone else in their gene pool other than what's 'normal'.  It really
> disturbs me how normative the tastes of a Bayesian spam filter can become.
> Spam filter says something is 'not normal'.  Cranky people agree that I'm
> not normal and that they don't like what I post.  Non-cranky people don't
> say anything, but meanwhile, public perception shifts towards the idea that
> it's best for people to have 'normal' behavior.  Maybe even that the
> Bayesian filter should be praised!  This strikes me as a local minima in
> some hill climbing problem of language growth.  "Trapped in the bowl," so to
> speak.

It is not that bad. I think. Most of your posts made it through to the OCaml
mailing list.

Take into considerations: The Clean mailing list actually is human- moderated.
I only mention this because there you wouldn't have had the chance to see
light.

>

Personllay I think it is pure insanity to moderate a Clean mailing list which
has only a few members. From that point of view: the Caml mailing list is very
open.

As I said: your apporach is a bit mad, but not unintelligent. Because it is
often better not to get involved into programming language problems   in a
first run. Nevertheless you should write some simple OCaml code.

What I do not understand: if your bussines model stands. Why don't you look for
investors and then in turn that money is spend in outsourcing the project to
paid C++ programmers? You are still the boss of the design and poject.

If your bussines model is sound and ready,  why are you sure then that you will
grasp OCaml within a couple of days? A conservative estimate would be along the
lines of 1 year for mastering  OCaml programming in production code. It is the
same when Stroustroup says that mastering C++ for production code takes one at
least 6 to 12 months provided he will programm every day in C++.

Fensterbrett
PS: Just out of curiosity: did you ever consider Haskell for your journey to
heaven?

0
8/16/2004 10:02:53 AM
On Mon, 16 Aug 2004, Siegfried Gonzi wrote:

> PS: Just out of curiosity: did you ever consider Haskell for your journey to
> heaven?
>

Too slow for Brandon's purposes at the moment, even with strictness
annotations etc all over the place.

-- 
flippa@flippac.org
0
flippa (196)
8/16/2004 10:34:26 AM
rossberg@ps.uni-sb.de (Andreas Rossberg) writes:

> I believe this indeed has been tried, at least I vaguely remember a
> discussion about a memo combinator for Haskell some years ago.

Not sure if you refer to this, but GHC ships with -package util, which
contains Memo.memo and Memo.memoSized.

----------
Prelude> :b Memo
memo :: forall a b. (a -> b) -> a -> b
memoSized :: forall a b. Int -> (a -> b) -> a -> b

Prelude> let {fib 1 = 1; fib 2 = 1; fib x = fib (x-1) + fib (x-2)}
Prelude> let z = 30

Prelude> fib z   -- long pause
832040
Prelude> fib z   -- long pause
832040

Prelude> let mfib = Memo.memo fib
Prelude> mfib z  -- long pause
832040
Prelude> mfib z  -- immediate result
832040

----------

Note that memo is based on object identity, not value, so calling mfib
with another parameter valued 30 is going to cause it to be
recalculated. 

-ketil
-- 
If I haven't seen further, it is by standing in the footprints of giants
0
ketil (99)
8/16/2004 10:38:21 AM
Brandon J. Van Every wrote:

> The main things bugging me about OCaml are a so-so C FFI and baroque syntax.
> I'm worried about selling this to game developers as a successor to C++.
> Also, the language principles and I are starting to dislike each other.
> More accurately, I'm starting to dislike them; I think they've disliked me
> from the outset, they're just less polite about it now.  Increasingly, for
> industrialization problems, I'm seeing all academics as obstacles to be
> routed around.  They don't share core concerns with a game developer or an
> entrepreneur.

Not to turn you off the 'one true path' (i.e. functional programming) 
but it just occurred to me that Cyclone 
(http://www.research.att.com/projects/cyclone/) might fit your bill. 
Have you looked at it?

 From the web page:
-----------------------------------------------------------------------
Cyclone is a programming language based on C that is safe, meaning that 
it rules out programs that have buffer overflows, dangling pointers, 
format string attacks, and so on. High-level, type-safe languages, such 
as Java, Scheme, or ML also provide safety, but they don't give the same 
control over data representations and memory management that C does 
(witness the fact that the run-time systems for these languages are 
usually written in C.) Furthermore, porting legacy C code to these 
languages or interfacing with legacy C libraries is a difficult and 
error-prone process. The goal of Cyclone is to give programmers the same 
low-level control and performance of C without sacrificing safety, and 
to make it easy to port or interface with legacy C code.

Cyclone also provides modern features for convenient programming:

     * Tagged unions
     * ML-style datatypes
     * Parametric polymorphism
     * Pattern matching
     * Exceptions
     * Anonymous structs equivalent by structure
     * Parameterized typedefs
     * An extensive library for container types and other common utilities
     * A lexer generator and parser generator
     * Function-level debugging with gdb and profiling with gprof
-----------------------------------------------------------------------

Sure, it's neither 'functional' (nor 'object oriented') but it does lend 
a healthy amount of features and techniques from functional programming 
(e.g. type inference), fitting it to 'C'-code and performance would be 
other points to stress.

Points against could be lack of a native windows environment (runs under 
cygwin though) and that's it's not that mature yet. (Though more so one 
might add than some of the other alternatives you've mentioned).

Stefan,
-- 
Stefan Axelsson  (email at http://www.cs.chalmers.se/~sax)
0
crap1234 (43)
8/16/2004 11:40:42 AM
cr88192 wrote:
>>>
>>>I don't mind syntactic sugar.  I just want the same syntactic sugar used 
>>>in
>>>*all* programs for a given langauge.  It could be part of a standard
>>>library.
>>
>>Yes, precisely. But that requires the language to be expressive enough
>>to be able to implement it as a library.
> 
> I would rather have it as part of the core language.

Why? If the language allows you to implement it in a library without you 
noticing the difference, why should you bother complicating the 
language? The compiler could still optimise it if necessary, but that's 
an implementation detail.

>>That may will be so, but it is domain specific, and there is no clear
>>line to draw for what should be built-in. So it should clearly be
>>considered a library issue.
> 
> dunno, += and friends seem pretty general to me, and have a great many uses 
> (along with ++ and --).

There are many uses for printf. In Fortran the equivalent was part of 
the language.

>>Well, all kinds. IMO, C's lack of tuples, lists, first-class functions
>>and common operations on them is much more serious, to name just a
>>few. And you cannot easily do those yourself (and what's in the C++
>>stdlib is a lame substitute).
> 
> (or, to turn it around):
> 
> well, you have function pointers at least.
> 
> yes, they don't have lexical scope (this is lame, but not unworkable).
> 
> you can put them in a struct if needed:
> typedef struct func_s {
> void *(*func)(struct func_s *, void *, ...);
> void *data;
> }func_t;
> 
> (this approach is common for many of my api's and such...).
 >
> lists are not that hard to implement either imo (err, if you can tolerate 
> ugly things...).
> consider linked lists, and the common:
> while(cur)
> {
>     //do-whatever
>     cur=cur->next;
> }
> style loops.

I don't get it. You really consider the necessity to frequently plant 
heavy noise like that into your code less of a pain than writing x=x+2 
from time to time?

> in the case of c, these are only a minor inconvinience, for a lang that can 
> do so much else (like directly using os api's, or having a fairly consistent 
> assembler-level interface...).

Don't know what OS APIs have to do with it. I agree that interfacing 
assembly language is an important issue in some domains. But be honest, 
it's a niche.

> ffi's are often only a crude immitation of this, and we don't even get full 
> pointer semantics most of the time (what? no pointers, how can anything get 
> done?!...).

True, FFIs are usually a pain. But that is no surprise, there is an 
impedance mismatch. You cannot blame the languages.

Or are you proposing to stick to low-level languages forever just to 
keep interfacing to low-level stuff easier?

> and all it asks in return is slightly big/ugly code...

Slightly?? That's what I call an understatement.

Cheers,

	- Andreas

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

Let's get rid of those possible thingies!  -- TB

0
rossberg (600)
8/16/2004 11:49:23 AM
Brandon J. Van Every wrote:
> 
> Sure there's a line: the line of extant industrial practice.  Including
> these operators is not controversial from a C/C++ coder's point of view.

If we oriented everything towards extant industrial practice only we'd 
still be stuck with assembly language, Fortran, and Cobol, wouldn't we?

>>>>There are a lot of other equally fundamental and more important
>>>>operations that face similar problems, so I don't see what's so
>>>>special about += and friends that they deserve VIP treatment.
>>>
>>>Ok, name these more important operations?
>>
>>Well, all kinds. IMO, C's lack of tuples, lists, first-class functions
>>and common operations on them is much more serious, to name just a
>>few.
> 
> This has nothing to do with += *= operators.

Er, so? It's about priorities. I originally tried to point out that CR 
has silly priorities if he uses syntactic convenience as an argument for C.

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

Let's get rid of those possible thingies!  -- TB

0
rossberg (600)
8/16/2004 11:53:53 AM
In article <b20b8d03.0408150407.4a1a4ad2@posting.google.com>, 
rossberg@ps.uni-sb.de says...
> Gerry Quinn <gerryq@DELETETHISindigo.ie> wrote:
> > 
> > Why not?  'Module' is a not-very-specific term that means 'an 
> > independent part of a program.
> 
> As I explained in the part of my posting you skipped this is not true
> in the context of programming languages. 

The term 'module' does have the meaning I said in the context of 
programming languages.  If you want to introduce jargon from some 
theoretical approach to language, define it first.  Because if you don't 
mean 'an independent part of a program' I'm sure I'm not the only one 
here who doesn't know what you mean.

> > > But there is nothing to encapsulate. You seem to envision some strange 
> > > kind of state added at some point in time, but I don't really see that. 
> > > Neither do I believe that you consider doing that a good idea.
> > 
> > Functions are not 'nothing'.  It is just as important to encapsulate 
> > functions as data.
> 
> But what you described is not encapsulation, it is just grouping.

No, putting functions in a [C++ or similar] class is encapsulation, 
because they are not only grouped, they are restricted in scope and 
accessibility.  Are you saying that in a class, member variables are 
encapsulated while member functions are merely grouped?  Doesn't make 
sense to me.

> > And yes, I don't see anything wrong with the idea of 
> > possibly adding state at some time - it's a perfectly natural thing to 
> > happen.  I gave the example of 'MapUtilities' that you might at some 
> > stage want to expand into SquareMapUtilities and HexMapUtilities, and/or 
> > include a workspace for scratch calculations, or records of useful 
> > knowledge concerning a particular map that has been attached to an 
> > instance of it.
> 
> I'm not convinced. Sounds like a design nightmare to me. YMMV.

So how would you do it?  
 
[encapsulation ]
> What you said, though, was that it actually was the "most fundamental"
> aspect of OO. To me, this implies that you consider it the primary
> feature that sets OO apart from other approaches. And I dispute that,
> because that feature is in no way unique to OO.

I see no identity between the terms "the most fundamental aspect of X" 
and "that which sets X apart".  So you are disputing with a straw horse.

> What sets OO apart is that it builds a whole philosophy around a
> *particular way* for achieving encapsulation, namely including
> functions as part of the value.

That is not a "particular way of achieving encapsulation", it is just 
encapsulating functions.  If a methodology encapsulates functions, 
encapsulation of functions is achieved, and if a methodology doesn't 
encapsulate functions, encapsulation of functions is not achieved.

The word "encapsulation" means nothing without a term describing what is 
encapsulated.

- Gerry Quinn


0
gerryq (1329)
8/16/2004 12:14:48 PM
In article <slrnchst53.4l6.neelk@gs3106.sp.cs.cmu.edu>, neelk@cs.cmu.edu 
says...
> In article <MPG.1b86af0dbbc04ebd98987c@news.indigo.ie>, Gerry Quinn wrote:
> > 
> > Well, walking along trees is not unusual in games programming, and most 
> > of us have succeeded in doing so without too much difficulty.  I assume 
> > FPs can express certain operations on trees elegantly, but there are 
> > ways of doing it in OO languages without too much trouble.
> 
> I came to FP from OO languages, and the difference is astonishingly
> large. Whenever you can represent a data structure as a term algebra
> (ie, instances of the data type can be generated from a grammar), then
> functional languages make writing functions that operate on these
> types radically simpler than in conventional languages.
> 
> To use the design pattern jargon, any code using the Visitor,
> Composite, Interpreter, or Command patterns is a lot simpler when
> expressed with functional-style algebraic data types. (Actually having
> first-class functions simplifies a lot of other design patterns, too,
> but languages like Python and Smalltalk show that first-class
> functions are not foreign to OO.)

But of course the use of such patterns is optional.  So I would say FP 
is giving you alternative ways to solve programming problems, rather 
than solving problems per se.
 
> I just Googled for transposition tables, and I think they would be
> very easy to add to an algorithm. However, from what I see, it doesn't
> look like it would be very hard to add this to a search algorithm
> written in in an OO language, either. We just want to memoize the
> results of analyzing positions, right?
> 
> I would guess that most of the real software engineering difficulty in
> adding this would be in designing data structures to store positions
> in a minimum of space -- but this complexity could be hidden behind a
> nice interface, regardless of programming paradigm.

Transposition tables were kind of a trick question, because of course 
they are a data-orrented issue.  Still, if FP has no problem with such 
things, FP is probably okay for writing chess programs.

> This lets you write state-machine style code as a set of mutually
> recursive functions without running a risk of stack overflow, and so
> you can modularize your search code by placing different search modes
> in different functions, which tail-call one another to switch mode.
> This will get more and more useful as the complexity of your search
> code increases.

Maybe if I have that problem sometime I will take a look at FP.  But 
first I'll look for ways to avoid the problem!

- Gerry Quinn

0
gerryq (1329)
8/16/2004 12:35:09 PM
In article <sddd61vnfy3.fsf@shell01.TheWorld.com>, 
cfc@shell01.TheWorld.com says...

> That is not to say that one can't do such things via primitives that
> combine properly.  However, in the imperative world, there is a subtle
> semantic difference between x += 1 and x = x + 1, and that is worth
> noting and attending to.  (The difference is due to side-effects.)

One other advantage of += occurs to me:

There's little difference between writing:
x += 1
x = x + 1

But if you often have to write
numberOfAnimals = numberOfAnimals + 1

...you'll inevitably find yourself drifting towards shorter variable 
names!  (The above is a bad example because nAnimals would be fine, but 
you know what I mean...)

- Gerry Quinn
0
gerryq (1329)
8/16/2004 12:43:39 PM
"Andreas Rossberg" <rossberg@ps.uni-sb.de> wrote in message 
news:cfq703$7mfu1$1@hades.rz.uni-saarland.de...
> cr88192 wrote:
>>>>
>>>>I don't mind syntactic sugar.  I just want the same syntactic sugar used 
>>>>in
>>>>*all* programs for a given langauge.  It could be part of a standard
>>>>library.
>>>
>>>Yes, precisely. But that requires the language to be expressive enough
>>>to be able to implement it as a library.
>>
>> I would rather have it as part of the core language.
>
> Why? If the language allows you to implement it in a library without you 
> noticing the difference, why should you bother complicating the language? 
> The compiler could still optimise it if necessary, but that's an 
> implementation detail.
>
well, mostly it seems "odd" to put something like this is a library.

>>>That may will be so, but it is domain specific, and there is no clear
>>>line to draw for what should be built-in. So it should clearly be
>>>considered a library issue.
>>
>> dunno, += and friends seem pretty general to me, and have a great many 
>> uses (along with ++ and --).
>
> There are many uses for printf. In Fortran the equivalent was part of the 
> language.
>
I think I mentioned elsewhere where I think the division lies.
things like printf don't really belong in the core language imo.

in the case of my lang, the border is messy, oh well. the distinction 
between the core language and the libraries is not entirely clear, but oh 
well...

>>>Well, all kinds. IMO, C's lack of tuples, lists, first-class functions
>>>and common operations on them is much more serious, to name just a
>>>few. And you cannot easily do those yourself (and what's in the C++
>>>stdlib is a lame substitute).
>>
>> (or, to turn it around):
>>
>> well, you have function pointers at least.
>>
>> yes, they don't have lexical scope (this is lame, but not unworkable).
>>
>> you can put them in a struct if needed:
>> typedef struct func_s {
>> void *(*func)(struct func_s *, void *, ...);
>> void *data;
>> }func_t;
>>
>> (this approach is common for many of my api's and such...).
> >
>> lists are not that hard to implement either imo (err, if you can tolerate 
>> ugly things...).
>> consider linked lists, and the common:
>> while(cur)
>> {
>>     //do-whatever
>>     cur=cur->next;
>> }
>> style loops.
>
> I don't get it. You really consider the necessity to frequently plant 
> heavy noise like that into your code less of a pain than writing x=x+2 
> from time to time?
>
I was exaggerating here, but partly to show that it also seems unreasonable 
to me to give things like this up in the name of some ideals.

>> in the case of c, these are only a minor inconvinience, for a lang that 
>> can do so much else (like directly using os api's, or having a fairly 
>> consistent assembler-level interface...).
>
> Don't know what OS APIs have to do with it. I agree that interfacing 
> assembly language is an important issue in some domains. But be honest, 
> it's a niche.
>
this is a failing of most higher level languages, and really it is difficult 
to escape.
partly I blame it on the lack of any real consistent way to define 
interfaces to an api. headers are too tied to c and c++ (and are filled with 
lots of compiler specific garbage as well, short of a meta-compiler, there 
is not much of a way to extract api info).

one would hope not to be tied to any particular platform either, as this is 
just a different kind of trap.

>> ffi's are often only a crude immitation of this, and we don't even get 
>> full pointer semantics most of the time (what? no pointers, how can 
>> anything get done?!...).
>
> True, FFIs are usually a pain. But that is no surprise, there is an 
> impedance mismatch. You cannot blame the languages.
>
yes, I blame the inability to really mine api's headers...
I am considering a new idl language though (different than my previous 
ones), in effect I would have to write out interface definitions, but 
combined with the headers they should give enough to allow wrapping.

another thing if making the language fake a lot of the aspects of c 
hopefully at least well enough to allow wrapping (faking pointers, 
simulating pointers to variables, ...).
a problem though is that my lang in many cases lacks compatible semantics (I 
need at least in/out variables, among other things).

> Or are you proposing to stick to low-level languages forever just to keep 
> interfacing to low-level stuff easier?
>
it seems almost like a possibility, and I have been generally trying to find 
somewhere to escape from c to...
c++ doesn't look worth it, and the jump to others would cost too much. my 
own languages have met this issue with minimal success (in my previous lang 
the idl language was a little too low level to really be usable).

but for the time being I am stuck in c land.
the escape from c land may lie somewhere in c land...

part of the thing though is that I believe the ability to gloss over the 
differences and interface with raw c or assembler is still a necessity, even 
if the lang is generally interpreted and has very different semantics.

this is still a standing issue though.

>> and all it asks in return is slightly big/ugly code...
>
> Slightly?? That's what I call an understatement.
>
yes.

I was only being half-serious anyways.

but yes, for one who writes in c chunks of a few kloc or such are not that 
unreasonable.

yes, a coder may have a project that is a single large space of about 80cols 
by 80kloc (possibly like acrobat when one zooms out fairly far...).

or something...



0
cr88192355 (1928)
8/16/2004 12:57:19 PM
"Gerry Quinn" <gerryq@DELETETHISindigo.ie> wrote in message 
news:MPG.1b8abc53e577a10b989885@news.indigo.ie...
> In article <sddd61vnfy3.fsf@shell01.TheWorld.com>,
> cfc@shell01.TheWorld.com says...
>
>> That is not to say that one can't do such things via primitives that
>> combine properly.  However, in the imperative world, there is a subtle
>> semantic difference between x += 1 and x = x + 1, and that is worth
>> noting and attending to.  (The difference is due to side-effects.)
>
> One other advantage of += occurs to me:
>
> There's little difference between writing:
> x += 1
> x = x + 1
>
yes, and this is where x++ comes in...

x++
x=x+1;

x--;
x=x-1;

the ++ and -- forms combine fairly well with expressions as well.

i=j=0;
while(i<10)j+=i++;
adds all numbers from 0 to 9.

i=j=0;
while(i<10)j+=++i;
adds all numbers from 1 to 10.

> But if you often have to write
> numberOfAnimals = numberOfAnimals + 1
>
> ..you'll inevitably find yourself drifting towards shorter variable
> names!  (The above is a bad example because nAnimals would be fine, but
> you know what I mean...)
>
yes, I know quite well about the single letter names...
oh wait, most of my variables (except globals) tend to have names along the 
lines of 1-3 letters...

globals tend to be long, which can be a hassle sometimes.



0
cr88192355 (1928)
8/16/2004 1:08:38 PM
Gerry Quinn wrote:
>>>Why not?  'Module' is a not-very-specific term that means 'an 
>>>independent part of a program.
>>
>>As I explained in the part of my posting you skipped this is not true
>>in the context of programming languages. 
> 
> The term 'module' does have the meaning I said in the context of 
> programming languages.  If you want to introduce jargon from some 
> theoretical approach to language, define it first.  Because if you don't 
> mean 'an independent part of a program' I'm sure I'm not the only one 
> here who doesn't know what you mean.

Come on, I'm sure you've heard of Modula. That gives you the basic idea 
of a module system, even if a bit ancient. A module basically is an 
entity with an interface and an implementation, and it contains other 
entities of the language that can be accessed by name. For a modern 
module system, see ML for example.

Now look at "classes". What does it mean? A Java/C++ class is very 
different from a CLOS-style class, for example. Or a class in Haskell.

Of course, I know what you mean from context, and I'm only nitpicking 
because you claimed "module" was vacuous, while implicitly assuming 
"class" was precise. Not so.

>>>>But there is nothing to encapsulate. You seem to envision some strange 
>>>>kind of state added at some point in time, but I don't really see that. 
>>>>Neither do I believe that you consider doing that a good idea.
>>>
>>>Functions are not 'nothing'.  It is just as important to encapsulate 
>>>functions as data.
>>
>>But what you described is not encapsulation, it is just grouping.
> 
> No, putting functions in a [C++ or similar] class is encapsulation, 
> because they are not only grouped, they are restricted in scope and 
> accessibility.

This thread is really turning into a dispute about terminology that does 
not lead anywhere. So I will just try to clarify what I mean for winding 
this up.

Encapsulation as information hiding. In OO, it is primarily the state of 
an object that is encapsulated. No obvious state exists in your 
MapUtilities example. You do not restrict accessibility. Nor, in a 
strong sense, scoping, because you just have to qualify the functions 
(that's what usually is called namespacing).

> Are you saying that in a class, member variables are 
> encapsulated while member functions are merely grouped?  Doesn't make 
> sense to me.

The state is encapsulated, while the functions provide access to it 
(they are part of the capsule, not what is encapsulated). If there is no 
state (not even conceptually) then you do not have encapsulation, and it 
is more or less an abuse of objects.

>>>And yes, I don't see anything wrong with the idea of 
>>>possibly adding state at some time - it's a perfectly natural thing to 
>>>happen.  I gave the example of 'MapUtilities' that you might at some 
>>>stage want to expand into SquareMapUtilities and HexMapUtilities, and/or 
>>>include a workspace for scratch calculations, or records of useful 
>>>knowledge concerning a particular map that has been attached to an 
>>>instance of it.
>>
>>I'm not convinced. Sounds like a design nightmare to me. YMMV.
> 
> So how would you do it?  

Extension with additional functionality is not an issue if you don't try 
to squeeze it into OO idioms to start with. Not sure what your scratch 
workspace is supposed to do, but I would rather make it an explicit 
object, because that renders it more scalable and reentrant.

>>What you said, though, was that it actually was the "most fundamental"
>>aspect of OO. To me, this implies that you consider it the primary
>>feature that sets OO apart from other approaches. And I dispute that,
>>because that feature is in no way unique to OO.
> 
> I see no identity between the terms "the most fundamental aspect of X" 
> and "that which sets X apart".  So you are disputing with a straw horse.

Then what is "fundamental" anyway? If you don't interpret it that way 
then then what remains as the most fundamental aspect of OO is executing 
statements.

But again this is becoming an argument about terminology, so I stop here.

Cheers,

   - Andreas

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

Let's get rid of those possible thingies!  -- TB

0
rossberg (600)
8/16/2004 1:39:17 PM
In article <ql2Uc.1839$6v2.513@news.flashnewsgroups.com>, cr88192
@hotmail.com says...
> "Gerry Quinn" <gerryq@DELETETHISindigo.ie> wrote in message 
> news:MPG.1b8abc53e577a10b989885@news.indigo.ie...

> >> That is not to say that one can't do such things via primitives that
> >> combine properly.  However, in the imperative world, there is a subtle
> >> semantic difference between x += 1 and x = x + 1, and that is worth
> >> noting and attending to.  (The difference is due to side-effects.)
> >
> > One other advantage of += occurs to me:
> >
> > There's little difference between writing:
> > x += 1
> > x = x + 1
> >
> yes, and this is where x++ comes in...
> 
> x++
> x=x+1;

I could live without ++.

> > But if you often have to write
> > numberOfAnimals = numberOfAnimals + 1
> >
> > ..you'll inevitably find yourself drifting towards shorter variable
> > names!  (The above is a bad example because nAnimals would be fine, but
> > you know what I mean...)
> >
> yes, I know quite well about the single letter names...
> oh wait, most of my variables (except globals) tend to have names along the 
> lines of 1-3 letters...

I'm quite a good boy in this regard - lately I've even taken to using 
long names for iterators:

for ( iBox = 0; iBox < 10; iBox++ )
{
	EmptyBox( iBox );
}

Anyway, it's bad to code fast.  Much better to take it slowly and watch 
what you're doing...

- Gerry Quinn


> globals tend to be long, which can be a hassle sometimes.



0
gerryq (1329)
8/16/2004 1:58:13 PM
"Gerry Quinn" <gerryq@DELETETHISindigo.ie> wrote in message 
news:MPG.1b8acdcd1bef8a84989888@news.indigo.ie...
> In article <ql2Uc.1839$6v2.513@news.flashnewsgroups.com>, cr88192
> @hotmail.com says...
>> "Gerry Quinn" <gerryq@DELETETHISindigo.ie> wrote in message
>> news:MPG.1b8abc53e577a10b989885@news.indigo.ie...
>
>> >> That is not to say that one can't do such things via primitives that
>> >> combine properly.  However, in the imperative world, there is a subtle
>> >> semantic difference between x += 1 and x = x + 1, and that is worth
>> >> noting and attending to.  (The difference is due to side-effects.)
>> >
>> > One other advantage of += occurs to me:
>> >
>> > There's little difference between writing:
>> > x += 1
>> > x = x + 1
>> >
>> yes, and this is where x++ comes in...
>>
>> x++
>> x=x+1;
>
> I could live without ++.
>
maybe.
hmm, it would be annoying to do c coding without ++ or -- though.

>> > But if you often have to write
>> > numberOfAnimals = numberOfAnimals + 1
>> >
>> > ..you'll inevitably find yourself drifting towards shorter variable
>> > names!  (The above is a bad example because nAnimals would be fine, but
>> > you know what I mean...)
>> >
>> yes, I know quite well about the single letter names...
>> oh wait, most of my variables (except globals) tend to have names along 
>> the
>> lines of 1-3 letters...
>
> I'm quite a good boy in this regard - lately I've even taken to using
> long names for iterators:
>
> for ( iBox = 0; iBox < 10; iBox++ )
> {
> EmptyBox( iBox );
> }
>
I don't like this, as it would require extra typing.

> Anyway, it's bad to code fast.  Much better to take it slowly and watch
> what you're doing...
>
I usually take it fast, and later get around to fixing up the resultant 
mess.

another thing is I tend to keep the naming convention fairly consistent as 
it makes copy/pasting crap all over a lot easier.

of course, I have not been doing that much coding recently though.
it is night, and I haven't gotten anything done since this morning (err, I 
finally implemented multimethods, need to get back to exceptions, and the 
idea of a ffi has come up again...).
of well, multimethods sort of suck at present (need to add crap to rename a 
lot of the types, and maybe introduce a concept of object "type", or a way 
to define relations). crap, something like a conventional typesystem would 
be a hassle (hmm, seems like a use for special variables and hackish use of 
the delegation mechanism...).

yes, exceptions should be useful. at least it would beat out my current 
approach of largely just ignoring problems of maybe giving a message ("oh 
crap, wrong args count, oh well", "oh crap, reference to unbound variable, 
oh well", ...).



0
cr88192355 (1928)
8/16/2004 2:50:04 PM
In article <clCTc.1614$6v2.373@news.flashnewsgroups.com>, cr88192 wrote:
> "Neelakantan Krishnaswami" <neelk@cs.cmu.edu> wrote in message 
> news:slrnchst53.4l6.neelk@gs3106.sp.cs.cmu.edu...
>
> yes, but a lot of non-functional languages also include tail call
> optimization.  similarly, my lang has this, albeit my lang does have
> some amount of functional influence though...

Which ones? This is an genuine question, not a rhetorical one, btw.

>> -- 
>> Neel Krishnaswami
>> neelk@cs.cmu.edu
> 
> hmm: were you one of the dudes at LL2?...

Yeah. I gave the talk on Needle. Now I'm a grad student at CMU. 

-- 
Neel Krishnaswami
neelk@cs.cmu.edu
0
neelk (298)
8/16/2004 8:50:39 PM
Neelakantan Krishnaswami wrote:
> In article <clCTc.1614$6v2.373@news.flashnewsgroups.com>, cr88192 wrote:
> 
>>"Neelakantan Krishnaswami" <neelk@cs.cmu.edu> wrote in message 
>>news:slrnchst53.4l6.neelk@gs3106.sp.cs.cmu.edu...
>>
>>yes, but a lot of non-functional languages also include tail call
>>optimization.  similarly, my lang has this, albeit my lang does have
>>some amount of functional influence though...
> 
> 
> Which ones? This is an genuine question, not a rhetorical one, btw.

I once had occasion to confirm that a C++ compiler was doing tail-call 
optimization, but I too am curious to know which languages (besides 
Scheme) require tail-call optimization as part of their standard.

-thant

0
thant (332)
8/16/2004 10:09:51 PM
Gerry Quinn wrote:
> One other advantage of += occurs to me:
> 
> There's little difference between writing:
> x += 1
> x = x + 1
> 
> But if you often have to write
> numberOfAnimals = numberOfAnimals + 1
> 
> ..you'll inevitably find yourself drifting towards shorter variable 
> names!  (The above is a bad example because nAnimals would be fine, but 
> you know what I mean...)

it becomes even more obvious if you have something like

<reference involving costly expression> += 1

granted, an optimizing compiler usually can handle that, but what if 
this costly expression has side effects that prevent it from evaluating 
to the same value on repetition?

hs
0
hs60 (77)
8/16/2004 11:56:27 PM
Gerry Quinn wrote:
>>yes, and this is where x++ comes in...
>>
>>x++
>>x=x+1;
> 
> I could live without ++.

the prefix ++ is equivalent to += 1, so discarding it wouldn't be much 
of a loss, all you have to do is replace all occurrences of ++x with 
(x+=1).  it's a bit different with the postfix:

x--

is equivalent to

(let ((t x))  (incf x 1)  t)

so you would lose some functionality that isn't quite so easy to replace

hs
0
hs60 (77)
8/17/2004 12:04:06 AM
>>
>>why, esp. in functional languages?  the combined operators re syntactic 
>>sugar for assignments, something a functional language tries to 
>>discourage.
>>
> 
> well, I am comming from an imperative perspective, I expect languages to let 
> me do c-like stuff with them w/o extra hassles.
> 
> if a language tries to discourage any coding approach, this seems like a 
> negative point (even if the language does end up as a huge ugly mess as a 
> result).
> imo the point of languages is to try to let people write code, and not to 
> control how they write the code or "educate" them about something.
> 
> constraining detail features of a language are implementation details that 
> need to be worked around eventually, and are not intended to be a philosophy 
> imo...
> 

The trouble is that your point of view leads you to include every 
possible feature you can think of so you're not 'discouraging' 
programmers.  Many people think that creeping featurism is a bad thing.

Another view is that one should include the minimal set of features that 
will get the job done and don't add any feature unless it provides 
significant benefit to the language that it wouldn't have had otherwise. 
  It's like Occam's razor for programming languages, and that's pretty 
much my point of view.
0
me5036 (108)
8/17/2004 12:39:19 AM
Gerry Quinn wrote:
> In article <slrnchst53.4l6.neelk@gs3106.sp.cs.cmu.edu>, neelk@cs.cmu.edu 
> says...
> 

[...]

>>To use the design pattern jargon, any code using the Visitor,
>>Composite, Interpreter, or Command patterns is a lot simpler when
>>expressed with functional-style algebraic data types. (Actually having
>>first-class functions simplifies a lot of other design patterns, too,
>>but languages like Python and Smalltalk show that first-class
>>functions are not foreign to OO.)
> 
> 
> But of course the use of such patterns is optional.  So I would say FP 
> is giving you alternative ways to solve programming problems, rather 
> than solving problems per se.

But in FP the "option" is so natural that these things aren't even 
perceived *as* problems any more than, say, writing "x + y" as the 
'solution' to the 'problem' of summing x and y. Consequently, the very 
notion of "design patterns" often seems a little odd from an FP 
point-of-view.

[...]

-thant
0
thant (332)
8/17/2004 2:38:30 AM
"Neelakantan Krishnaswami" <neelk@cs.cmu.edu> wrote in message 
news:slrnci27gu.of4.neelk@gs3106.sp.cs.cmu.edu...
> In article <clCTc.1614$6v2.373@news.flashnewsgroups.com>, cr88192 wrote:
>> "Neelakantan Krishnaswami" <neelk@cs.cmu.edu> wrote in message
>> news:slrnchst53.4l6.neelk@gs3106.sp.cs.cmu.edu...
>>
>> yes, but a lot of non-functional languages also include tail call
>> optimization.  similarly, my lang has this, albeit my lang does have
>> some amount of functional influence though...
>
> Which ones? This is an genuine question, not a rhetorical one, btw.
>
now this one is harder to answer.
I have heard lots of comments about various langs having it, but I have not 
looked at it in depth enough to know which ones (so I could very well be 
wrong).

I had heard rumors of tail optimization in gcc, but I have not actually 
confirmed this. info for gcc makes reference to tail optimization, so I 
guess it is done somehow.

postscript does also afaik.
I don't have a good list though.

>>> -- 
>>> Neel Krishnaswami
>>> neelk@cs.cmu.edu
>>
>> hmm: were you one of the dudes at LL2?...
>
> Yeah. I gave the talk on Needle. Now I'm a grad student at CMU.
>
yes, cool.

little interesting happens for me though, I am just a hobbyist (who is faced 
with the risk of having to get a job eventually...).

most of what I do I doubt anyone would care about (probably because I am 
mostly just ripping off ideas and doing half-assed implementations...).
sometimes I figure I should probably write more stuff (like documentation or 
whatever) but I don't like writing that much.

(or maybe I am just stupid).

oh well...



0
cr88192355 (1928)
8/17/2004 2:58:56 AM
"Peter Ashford" <me@here.there.com> wrote in message 
news:GtcUc.14044$N77.590094@news.xtra.co.nz...
>>>
>>>why, esp. in functional languages?  the combined operators re syntactic 
>>>sugar for assignments, something a functional language tries to 
>>>discourage.
>>>
>>
>> well, I am comming from an imperative perspective, I expect languages to 
>> let me do c-like stuff with them w/o extra hassles.
>>
>> if a language tries to discourage any coding approach, this seems like a 
>> negative point (even if the language does end up as a huge ugly mess as a 
>> result).
>> imo the point of languages is to try to let people write code, and not to 
>> control how they write the code or "educate" them about something.
>>
>> constraining detail features of a language are implementation details 
>> that need to be worked around eventually, and are not intended to be a 
>> philosophy imo...
>>
>
> The trouble is that your point of view leads you to include every possible 
> feature you can think of so you're not 'discouraging' programmers.  Many 
> people think that creeping featurism is a bad thing.
>
yes, maybe.

features that are just pointless though can probably be allowed to die or be 
deprecated (yes, this is bad for existing code...) or not included in the 
first place.
(I will just argue that I probably just have an 'odd' sense of what should 
be included and not).

but one should at least include all that is required from a given 
programming stance, like if comming from a c-ish stance, that requires 
things like '+= ... ++ -- ... >> << ...'.

a few operators can be dropped/reused, eg, I dropped '->' because in my lang 
it is equivalent to '.'.

yes, I changed the operator precedences around a little, but that was 
because c's table didn't make much sense to me (and my set of operators 
doesn't match exactly):
Literal values/builtin expressions
(<expr>) <expr>[<expr>] <expr>.<name>
++<name> --<name> + - ! ~ ... <name>++ <name>-- <expr>(<args>)
<expr>**<expr>
* / % \ &
+ - | ^
<< >>
< > <= >= == != <=> <<== >>==
&&
|| ^^
<expr>?<expr>:<expr>
:= :!= :< :> :<= :>= :<< :>> :<<= :>>=
= += -= *= /= \= %= &= |= ^= >>= <<=

> Another view is that one should include the minimal set of features that 
> will get the job done and don't add any feature unless it provides 
> significant benefit to the language that it wouldn't have had otherwise. 
> It's like Occam's razor for programming languages, and that's pretty much 
> my point of view.

this is different than mine.
I include most things except those that seem pointless or would be too 
painful to implement (and then some come up and point out their neccesity 
later).



0
cr88192355 (1928)
8/17/2004 3:21:26 AM
Joe Knapka <jknapka@kneuro.net> writes:
>Surely any pure FP language //could// memoize automatically, since
>functions are referentially transparent -- once you've computed the
>result for a given combination of parameters, you needn't ever do so
>again (though of course it might be desirable to compute rather than
>memoize in many cases). Do any FP implementations actually do that?

Mercury can do that, and Mercury is based as much on research on functional
programming as it is based on research in logic programming.

This is one way to define the fibonacci function on positive integers
in Mercury:

	:- func fib(int) = int.

	fib(N) = F :-
		( N < 2 ->
			F = 1
		;
			F1 = fib(N - 1),
			F2 = fib(N - 2),
			F = F1 + F2
		).

As expected, the runtime of this function increases extremely quickly
with increasing argument values.

If you add the directive

	:- pragma memo(fib/1).

then the compiler will memoize the function, and its complexity
changes to linear.

Zoltan Somogyi <zs@cs.mu.OZ.AU> http://www.cs.mu.oz.au/~zs/
Department of Computer Science and Software Engineering, Univ. of Melbourne
0
zs22 (13)
8/17/2004 7:46:56 AM
In article <ZYbUc.971$H23.10979@newscontent-01.sprint.ca>, 
hs@hartmann.schaffernet says...
> Gerry Quinn wrote:

> > I could live without ++.
> 
> the prefix ++ is equivalent to += 1, so discarding it wouldn't be much 
> of a loss, all you have to do is replace all occurrences of ++x with 
> (x+=1).  it's a bit different with the postfix:
> 
> x--
> 
> is equivalent to
> 
> (let ((t x))  (incf x 1)  t)
> 
> so you would lose some functionality that isn't quite so easy to replace

It is pretty trivial to replace.  In general, just use x where you had 
x--, and add an additional x -= 1 statement.

I doubt any situation can occur which would be in any way difficult to 
express in C/C++ without the postfix operator.

- Gerry Quinn








0
gerryq (1329)
8/17/2004 10:02:49 AM
In article <PRbUc.967$H23.10908@newscontent-01.sprint.ca>, 
hs@hartmann.schaffernet says...
> Gerry Quinn wrote:
> > One other advantage of += occurs to me:
> > 
> > There's little difference between writing:
> > x += 1
> > x = x + 1
> > 
> > But if you often have to write
> > numberOfAnimals = numberOfAnimals + 1
> > 
> > ..you'll inevitably find yourself drifting towards shorter variable 
> > names!  (The above is a bad example because nAnimals would be fine, but 
> > you know what I mean...)
> 
> it becomes even more obvious if you have something like
> 
> <reference involving costly expression> += 1
> 
> granted, an optimizing compiler usually can handle that, but what if 
> this costly expression has side effects that prevent it from evaluating 
> to the same value on repetition?

Not too hard to fix, though:

int & ref = < reference involving constant expression >;
ref = ref + 1;

- Gerry Quinn
0
gerryq (1329)
8/17/2004 10:05:50 AM
In article <slrnchst53.4l6.neelk@gs3106.sp.cs.cmu.edu>, neelk@cs.cmu.edu 
says...
> In article <MPG.1b86af0dbbc04ebd98987c@news.indigo.ie>, Gerry Quinn wrote:

[Apologies for second post on comp.lang.functional - I didn't notice 
that followups had been silently edited.  Any posts in response to my 
original one will not be read or responded to unless crossposted to 
comp.games.development.programming.algorithms, which is where I am 
reading this thread.]

> To use the design pattern jargon, any code using the Visitor,
> Composite, Interpreter, or Command patterns is a lot simpler when
> expressed with functional-style algebraic data types. (Actually having
> first-class functions simplifies a lot of other design patterns, too,
> but languages like Python and Smalltalk show that first-class
> functions are not foreign to OO.)

But of course the use of such patterns is optional.  So I would say FP 
is giving you alternative ways to solve programming problems, rather 
than solving problems per se.
 
> I just Googled for transposition tables, and I think they would be
> very easy to add to an algorithm. However, from what I see, it doesn't
> look like it would be very hard to add this to a search algorithm
> written in in an OO language, either. We just want to memoize the
> results of analyzing positions, right?
> 
> I would guess that most of the real software engineering difficulty in
> adding this would be in designing data structures to store positions
> in a minimum of space -- but this complexity could be hidden behind a
> nice interface, regardless of programming paradigm.

Transposition tables were kind of a trick question, because of course 
they are a data-orrented issue.  Still, if FP has no problem with such 
things, FP is probably okay for writing chess programs.

> Quiescent search is a little easier to express in a functional
> language. That's because functional languages include support for
> optimizing tail calls -- that is, when there is nothing to do in the
> current function after the call returns, the compiler can de-allocate
> the current function's stack frame immediately. 
> 
> This lets you write state-machine style code as a set of mutually
> recursive functions without running a risk of stack overflow, and so
> you can modularize your search code by placing different search modes
> in different functions, which tail-call one another to switch mode.
> This will get more and more useful as the complexity of your search
> code increases.

Maybe if I have that problem sometime I will take a look at FP.  But 
first I'll look for ways to avoid the problem!

- Gerry Quinn

0
gerryq (1329)
8/17/2004 10:15:00 AM
In article <cfqde6$7mfu1$3@hades.rz.uni-saarland.de>, rossberg@ps.uni-
sb.de says...
> Gerry Quinn wrote
 
> > The term 'module' does have the meaning I said in the context of 
> > programming languages.  If you want to introduce jargon from some 
> > theoretical approach to language, define it first.  Because if you don't 
> > mean 'an independent part of a program' I'm sure I'm not the only one 
> > here who doesn't know what you mean.
> 
> Come on, I'm sure you've heard of Modula. That gives you the basic idea 
> of a module system, even if a bit ancient. A module basically is an 
> entity with an interface and an implementation, and it contains other 
> entities of the language that can be accessed by name. For a modern 
> module system, see ML for example.

I've heard of Modula.  I know it was a programming language.  And that's 
about all I know about it.

> Now look at "classes". What does it mean? A Java/C++ class is very 
> different from a CLOS-style class, for example. Or a class in Haskell.
> 
> Of course, I know what you mean from context, and I'm only nitpicking 
> because you claimed "module" was vacuous, while implicitly assuming 
> "class" was precise. Not so.

Well, the difference is that I didn't know what you meant from context.

> This thread is really turning into a dispute about terminology that does 
> not lead anywhere. So I will just try to clarify what I mean for winding 
> this up.
> 
> Encapsulation as information hiding. In OO, it is primarily the state of 
> an object that is encapsulated. No obvious state exists in your 
> MapUtilities example. You do not restrict accessibility. Nor, in a 
> strong sense, scoping, because you just have to qualify the functions 
> (that's what usually is called namespacing).

As I stated, MapUtilities might easily start without state and find 
occasion to develop state during the development process.  I gave the 
example of a scratchpad as a start.  Another state might be a boolean 
variable that determines whether diagonal movement os possible.  But 
state isn't the only issue here.  There might well be functions with 
private or protected access that are not intended for use outside the 
MapUtilities class.  

In C++ and generally speaking in Java, functions and variables have 
identical access options.

> > Are you saying that in a class, member variables are 
> > encapsulated while member functions are merely grouped?  Doesn't make 
> > sense to me.
> 
> The state is encapsulated, while the functions provide access to it 
> (they are part of the capsule, not what is encapsulated). If there is no 
> state (not even conceptually) then you do not have encapsulation, and it 
> is more or less an abuse of objects.

That is nonsense.  Not all functions of a typical class are interface 
methods.  And I also pointed out that MapUtilities might easily have a 
state at some time, even if it has none now.

The 'web definition' of encapsulation seems to the point:
<QUOTE>
The localization of knowledge within a module. Because objects 
encapsulate data and implementation, the user of an object can view the 
object as a black box that provides services. Instance variables and 
methods can be added, deleted, or changed, but if the services provided 
by the object remain the same, code that uses the object can continue to 
use it without being rewritten.
<END QUOTE>

Clearly no distinction is made between variables and methods.  Nor 
should there be any such distinction.  Functions are knowledge too.

> > So how would you do it?  
> 
> Extension with additional functionality is not an issue if you don't try 
> to squeeze it into OO idioms to start with. Not sure what your scratch 
> workspace is supposed to do, but I would rather make it an explicit 
> object, because that renders it more scalable and reentrant.

Now you've got an object hanging around anyway, and a bunch of functions 
that you are vague about where they are - in a namespace maybe - and 
maybe a hanging boolean to determine whether diagonal movement is 
possible.  I don't see the benefit compared to a single object.

> >>What you said, though, was that it actually was the "most fundamental"
> >>aspect of OO. To me, this implies that you consider it the primary
> >>feature that sets OO apart from other approaches. And I dispute that,
> >>because that feature is in no way unique to OO.
> > 
> > I see no identity between the terms "the most fundamental aspect of X" 
> > and "that which sets X apart".  So you are disputing with a straw horse.
> 
> Then what is "fundamental" anyway? If you don't interpret it that way 
> then then what remains as the most fundamental aspect of OO is executing 
> statements.
 
You are mixing up description and classification.  What is fundamental 
to a swallow is flying and eating insects; what is distinctive about it 
is its forked tail.  And yes, it's a bird [the equivalent of saying a 
language executes statements].

> But again this is becoming an argument about terminology, so I stop here.

If we were to accept your terminology, we would be implicitly accepting 
an excessively limited concept of OO.  

- Gerry Quinn





0
gerryq (1329)
8/17/2004 10:39:11 AM
> cr88192 wrote:
> 
>>err, annoyingly I have come up with something that could allow really cool 
>>features (eg: the ability to handle relational db type stuff in the core 
>>language), but it will likely look quite strange.
>>
>>db[owner:="Bob", cost:<10000]
>>
>>managing things like this could be an issue though, since with types like 
>>this there is no longer really a 1d index space for such types.
>>but it just seemed too cool to not implement.

Like a lot of posts in this thread, you could look at "Concepts, 
Techniques, and Models of Computer Programming" by Van Roy and Haridi. 
This covers relational programming in some depth as well as lots more 
programming techniques and models.  Admittedly I haven't read that 
chapter thouroughly yet (Relational DB programming ala SQL hurts my 
brain, so I wasn't paying attention to the Relational Model even though 
it's not about SQL - SQL just put me off), but it does seem to be 
relevant to what you hint at above.

The book covers a lot of ground and I'm still trying to absorb the big 
picture.  It's quite stange to see how programming all fits together and 
harder still to discover what you can do with this knowledge.  The 
chapter on message passing concurrency (atleast I think it was that 
chapter) was probably the one chapter with the biggest "oh wow" for me, 
when it describes the different protocols for message passing, but the 
whole book is full of "oh wow" and "that's obvious, why didn't I see it 
before" moments.  Some of was harder to grasp what they where saying 
though.  I don't get delegation, constraint programming or

It's unsettling and satisfying that programming as we know it can be 
built from a few primitives.  Unsettling in that I didn't realise the 
big picture entirely before and satisfying in that it's not the messy 
brew of ideas and kludges some languages make it seem.

chris
0
spamoff.danx (197)
8/17/2004 7:53:40 PM
Gerry Quinn wrote:
> In article <ZYbUc.971$H23.10979@newscontent-01.sprint.ca>, 
> hs@hartmann.schaffernet says...
> 
>>Gerry Quinn wrote:
> 
> 
>>>I could live without ++.
>>
>>the prefix ++ is equivalent to += 1, so discarding it wouldn't be much 
>>of a loss, all you have to do is replace all occurrences of ++x with 
>>(x+=1).  it's a bit different with the postfix:
>>
>>x--
>>
>>is equivalent to
>>
>>(let ((t x))  (incf x 1)  t)
>>
>>so you would lose some functionality that isn't quite so easy to replace
> 
> It is pretty trivial to replace.  In general, just use x where you had 
> x--, and add an additional x -= 1 statement.

won't work whenx is an expression with side effects

> I doubt any situation can occur which would be in any way difficult to 
> express in C/C++ without the postfix operator.

wrong

hs
0
hs60 (77)
8/17/2004 9:11:31 PM
In article <cxuUc.1055$H23.12072@newscontent-01.sprint.ca>, 
hs@hartmann.schaffernet says...
> Gerry Quinn wrote:
> > In article <ZYbUc.971$H23.10979@newscontent-01.sprint.ca>, 
> > hs@hartmann.schaffernet says...
> > 
> >>x--
> >>
> >>is equivalent to
> >>
> >>(let ((t x))  (incf x 1)  t)
> >>
> >>so you would lose some functionality that isn't quite so easy to replace
> > 
> > It is pretty trivial to replace.  In general, just use x where you had 
> > x--, and add an additional x -= 1 statement.
> 
> won't work when x is an expression with side effects

XType & x = < expression >;
x += 1;

> > I doubt any situation can occur which would be in any way difficult to 
> > express in C/C++ without the postfix operator.
> 
> wrong

Care to give an example?

- Gerry Quinn


 
0
gerryq (1329)
8/17/2004 9:28:35 PM
cr88192 wrote:

> "Peter Ashford" <me@here.there.com> wrote in message 
> news:GtcUc.14044$N77.590094@news.xtra.co.nz...
> 
>>>>why, esp. in functional languages?  the combined operators re syntactic 
>>>>sugar for assignments, something a functional language tries to 
>>>>discourage.
>>>>
>>>
>>>well, I am comming from an imperative perspective, I expect languages to 
>>>let me do c-like stuff with them w/o extra hassles.
>>>
>>>if a language tries to discourage any coding approach, this seems like a 
>>>negative point (even if the language does end up as a huge ugly mess as a 
>>>result).
>>>imo the point of languages is to try to let people write code, and not to 
>>>control how they write the code or "educate" them about something.
>>>
>>>constraining detail features of a language are implementation details 
>>>that need to be worked around eventually, and are not intended to be a 
>>>philosophy imo...
>>>
>>
>>The trouble is that your point of view leads you to include every possible 
>>feature you can think of so you're not 'discouraging' programmers.  Many 
>>people think that creeping featurism is a bad thing.
>>
> 
> yes, maybe.
> 
> features that are just pointless though can probably be allowed to die or be 
> deprecated (yes, this is bad for existing code...) or not included in the 
> first place.
> (I will just argue that I probably just have an 'odd' sense of what should 
> be included and not).
> 
> but one should at least include all that is required from a given 
> programming stance, like if comming from a c-ish stance, that requires 
> things like '+= ... ++ -- ... >> << ...'.
> 
> a few operators can be dropped/reused, eg, I dropped '->' because in my lang 
> it is equivalent to '.'.
> 
> yes, I changed the operator precedences around a little, but that was 
> because c's table didn't make much sense to me (and my set of operators 
> doesn't match exactly):
> Literal values/builtin expressions
> (<expr>) <expr>[<expr>] <expr>.<name>
> ++<name> --<name> + - ! ~ ... <name>++ <name>-- <expr>(<args>)
> <expr>**<expr>
> * / % \ &
> + - | ^
> << >>
> < > <= >= == != <=> <<== >>==
> &&
> || ^^
> <expr>?<expr>:<expr>
> := :!= :< :> :<= :>= :<< :>> :<<= :>>=
> = += -= *= /= \= %= &= |= ^= >>= <<=
> 
> 
>>Another view is that one should include the minimal set of features that 
>>will get the job done and don't add any feature unless it provides 
>>significant benefit to the language that it wouldn't have had otherwise. 
>>It's like Occam's razor for programming languages, and that's pretty much 
>>my point of view.
> 
> 
> this is different than mine.
> I include most things except those that seem pointless or would be too 
> painful to implement (and then some come up and point out their neccesity 
> later).

I'm not sure how distant our viewpoints really are - I don't think that 
++ is pointless just because you can implement it another way - it's a 
nice shorthand that really helps when you want to encourage meaningfull 
(long) variable names.

I'd exclude things such as templates which I think have minimal value 
for the complexity they add (both to the compiler, code analysis tools 
and to the user)
0
me5036 (108)
8/17/2004 9:53:35 PM
Gerry Quinn wrote:
> I doubt any situation can occur which would be in any way
> difficult to express in C/C++ without the postfix operator.

Personally I have stopped using the postfix increment/decrement operators
entirely.  However, I like the prefix increment/decrement operators.  For
types some types (such as certain iterators), addition can only be
implemented through repeated incrementation.  For these types, it is natural
to use prefix '++' in preference over '+= 1'.


-- 
Rainer Deyke - rainerd@eldwood.com - http://eldwood.com


0
rainerd (86)
8/17/2004 10:01:36 PM
"Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com> wrote in
message news:2o88t7F7nst9U1@uni-berlin.de...
> Alan Bal jeu wrote:
> > "Bjorn Reese" <breese@see.signature> wrote in message
> > news:pan.2004.08.14.12.46.46.82396@see.signature...
> >> On Fri, 13 Aug 2004 00:54:04 -0700, Brandon J. Van Every wrote:
> >>
> >>> My study of AI map problems indicates that there's no such thing as
> >>> hierarchical compression of pathfinding.  If you want correct
> >>> paths, you
> >>
> >> Have you looked at Hierarchical A* by Holte et al?
> >>
> >>   http://www.csi.uottowa.ca/~holte/Publications/tr-95-18.ps
> >
> > That's http://www.csi.uottawa.ca/~holte/Publications/tr-95-18.ps
> > As in OttAwa.
>
> I believe I have, but it has been awhile.  Does the paper say you can
> hierarchize without losing path info?

It seems applicable to your problem.  It proposes abstracting parts of the
problem away, and then after a good candidate is identified put the details
back in.

To solve the influence problem on
    A B C D
    E F G H
    I J K l
    M N O P
you might replace that map with
    Q R
    S T
and a conservative influence function derived from the original data.  Run
the initial search on the abstraction, and then link that to a refining
search on the detailed map.

Holte's newer papers have even better information on how to search
effectively.


0
jeu (11)
8/18/2004 12:28:37 AM
"chris" <spamoff.danx@ntlworld.com> wrote in message 
news:8ntUc.228$nI5.4@newsfe3-gui.ntli.net...
>> cr88192 wrote:
>>
>>>err, annoyingly I have come up with something that could allow really 
>>>cool features (eg: the ability to handle relational db type stuff in the 
>>>core language), but it will likely look quite strange.
>>>
>>>db[owner:="Bob", cost:<10000]
>>>
>>>managing things like this could be an issue though, since with types like 
>>>this there is no longer really a 1d index space for such types.
>>>but it just seemed too cool to not implement.
>
> Like a lot of posts in this thread, you could look at "Concepts, 
> Techniques, and Models of Computer Programming" by Van Roy and Haridi. 
> This covers relational programming in some depth as well as lots more 
> programming techniques and models.  Admittedly I haven't read that chapter 
> thouroughly yet (Relational DB programming ala SQL hurts my brain, so I 
> wasn't paying attention to the Relational Model even though it's not about 
> SQL - SQL just put me off), but it does seem to be relevant to what you 
> hint at above.
>
link?
if the book is not downloadable and free then it doesn't do me much good...

> The book covers a lot of ground and I'm still trying to absorb the big 
> picture.  It's quite stange to see how programming all fits together and 
> harder still to discover what you can do with this knowledge.  The chapter 
> on message passing concurrency (atleast I think it was that chapter) was 
> probably the one chapter with the biggest "oh wow" for me, when it 
> describes the different protocols for message passing, but the whole book 
> is full of "oh wow" and "that's obvious, why didn't I see it before" 
> moments.  Some of was harder to grasp what they where saying though.  I 
> don't get delegation, constraint programming or
>
constraints are one of those things that seem cool, but are a poor semantic 
match for many langs and I had previously had the bad experience of kludging 
them onto a previous lang. comparatively evaluating the constraints is not 
that hard (though I had only used acyclic ones). they also didn't seem to 
mesh well with prototype object semantics.
err, unless you are talking of a different kind of "constraints".

> It's unsettling and satisfying that programming as we know it can be built 
> from a few primitives.  Unsettling in that I didn't realise the big 
> picture entirely before and satisfying in that it's not the messy brew of 
> ideas and kludges some languages make it seem.
>
hmm, yes, there are ways to generalize everything.
in the realm of c-ish langs though things are typically done in ad-hoc ways, 
and in many cases it is easier to live with redundancy than find a more 
general solution (err, like exceptions and continuations are very similar, 
and differ primarily in usage pattern and implementation...).

I don't know, you still might be talking of something different than I am 
thinking though.



0
cr88192355 (1928)
8/18/2004 1:11:48 AM
"Peter Ashford" <me@here.there.com> wrote in message 
news:i8vUc.14371$N77.602064@news.xtra.co.nz...
> cr88192 wrote:
>
<snip>
>>
>>
>> this is different than mine.
>> I include most things except those that seem pointless or would be too 
>> painful to implement (and then some come up and point out their neccesity 
>> later).
>
> I'm not sure how distant our viewpoints really are - I don't think that ++ 
> is pointless just because you can implement it another way - it's a nice 
> shorthand that really helps when you want to encourage meaningfull (long) 
> variable names.
>
yes.

> I'd exclude things such as templates which I think have minimal value for 
> the complexity they add (both to the compiler, code analysis tools and to 
> the user)

well, I had not really intended to implement them anyways.

there are features I had wanted (eg: macros) but they had presented complex 
issues that would need to be worked over (eg: wrt the syntax trees, 
compile/runtime distinction, scoping rules, ...).
c-style macros are hardely worth implementing though (but interesting 
possibilities could exist if I delayed full processing and expansion until 
compile time).
but then the issue is whether or not to try to fake the style of the c 
system, and still the mystery as to whether it would be useful vs other 
possible features...
I would probably not bother faking the c style, but instead make something 
clearly different (eg: a non-hygenic syntax-rules style system).

define_macro <NAME><PATTERN> <BODY>
define_macro <NAME> '{'[<PATTERN> <BODY>]+'}'

any vars defined in pattern are used in body, any other vars in body are 
assumed to come from the environment at the point of compilation.
crap, if I had more chars that could be used in names I could use something 
like the "implicit gensym" system I had used before, eg:
var @foo;
@foo=3;
where any occurances of @foo are renamed to some autogenerated name (this 
could also be done as a partial parser hack though).

scoping rules:
this could be a problem, given they do not exist at runtime and I am 
avoiding any occurance of "hybrid modes".
this could also require signifigant alteration to my compile loop (though 
this is an alteration that is needed anyways but I have been putting 
off...).

or something.

I don't know if there is much use to this though, or if it would just make 
things worse.



0
cr88192355 (1928)
8/18/2004 2:14:56 AM
> Which ones? This is an genuine question, not a rhetorical one, btw.

Lua, Postscript, PDScript, Slate, there are several others

Daniel Ehrenberg
0
8/18/2004 3:48:28 AM
Gerry Quinn wrote:
>
> You are mixing up description and classification.  What is fundamental
> to a swallow is flying and eating insects; what is distinctive about
> it is its forked tail.  And yes, it's a bird [the equivalent of saying a
> language executes statements].

I"m not so sure Andreas mixed things up here.

Flying and eating insects is fundamental to A BIRD.  A swallow is a
specialization of a bird, one with a forked tail.  I would say that having a
forked tail is fundamental to being A SWALLOW.  I think the term
'fundamental' will inevitably depend upon the paradigm of recombination
you're using.  It's easy to see BIRD::SWALLOW in an OO inheritance hierarchy
sense.  Now, if we can get lotsa little fucking birds to all start fucking
each other, exchanging their genetic material, maybe we'll have something
more like a Functional paradigm?  Distinctions might no longer be
fundamental; lotsa kinds of birds might have forked tails.

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

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

0
8/18/2004 8:29:33 AM
Gerry Quinn wrote:
>
> I could live without ++.

I was going to say so too, then I realized it's still the
LongTediousVariableName problem in a different guise.  Preincrement /
postincrement operators allow one to skip a statement.

* LongTediousVariableName++ = myBullshit;

vs.

* LongTediousVariableName = myBullshit;
LongTediousVariableName += 1;

Yet we could end up writing things twice in for (;;) loops anyways.  I
suppose in practice, we tend to notice monsters like

for (LongTediousVariableName = 0; LongTediousVariableName < myBullshit;
  LongTediousVariableName+++)

and instead write

for (i=LongTediousVariableName; i < myBullshit; i++)

or even use separate pointer and indexing forms for loop control

for (i=0; i < nonsenseN; i++) {
  *LongTediousVariableNamePtr++ = myBullshit;
}

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

"We live in a world of very bright people building
crappy software with total shit for tools and process."
                                - Ed Mckenzie

0
8/18/2004 8:53:34 AM
Peter Ashford wrote:
>
> Another view is that one should include the minimal set of features
> that
> will get the job done and don't add any feature unless it provides
> significant benefit to the language that it wouldn't have had
>   otherwise. It's like Occam's razor for programming languages, and
> that's pretty much my point of view.

Does any language fulfil this point of view?  OCaml doesn't; old timers
decry that it *used* to have clean syntax.  Python is as oriented towards
keeping things clean as any language can be, probably, and still it gets new
language features added to it.  Maybe it does so in a clean way, but it
seems that language design is inevitably ongoing.  People just don't want to
stop adding new stuff to a core system that's working.

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

"We live in a world of very bright people building
crappy software with total shit for tools and process."
                                - Ed Mckenzie

0
8/18/2004 8:57:01 AM
Siegfried Gonzi wrote:
>
> It is not that bad. I think. Most of your posts made it through to
> the OCaml mailing list.

It's particularly bad for my ML Seattle announces.  The Bayesian filter
judges them to be waaaay different from all my other OCaml posts, which only
need a certain .sig to get passed.  Keywords like 'beer' are highly
problematic.

What I really resent, is Xavier's recent characterization of my ML Seattle
announce as being somehow ill-formed, just because the Bayesian filter
rejects it.  It's like, rolling all antipathies / dislikes for me into one
package, then blasting me for something that isn't applicable.  Why
*shouldn't* a local user group announcement occur on caml-list?  "It's not
applicable to everyone in the world" is nonsense, what's the transmission
vector supposed to be instead?  The forum's right, the nature of the
announce is right; why *shouldn't* it mention food, parking, and nature of
venue?  This is like saying caml-list is too anal to announce a public
gathering at a conference or something.

> Take into considerations: The Clean mailing list actually is human-
> moderated. I only mention this because there you wouldn't have had
> the chance to see light.

I don't know that that's true.  It depends upon the degree of topic Nazism
vs. civility enforcement.  I agree I wouldn't survive in a topic Nazi
regime.  In a civil regime, I'd do fine.  I may post things that are pointed
about a technology, but I don't attack people personally.  I often receive
personal attacks for what I post, and that's part of what degrades a forum.
The difference is that politically speaking, I get blamed for all personal
attacks that come my way.  It's not someone else's fault for gratuitously
ragging on me or ML Seattle, it's my fault for not being the academic /
technical product that other people want to hear about.

> Personllay I think it is pure insanity to moderate a Clean mailing
> list which has only a few members. From that point of view: the Caml
> mailing list is very open.

I don't know about 'pure insanity' but it doesn't strike me as efficient.  I
think people can self-moderate in small numbers.  That said, starting
http://groups.yahoo.com/group/ocamlgames/ recently, I have reserved the
right to start moderating the group if there's a complete meltdown.  Some of
our initial debates have indeed gotten a little toasty.  So I've said, "I
don't want to end up having to moderate this list" at least twice now.  A
moderation threat does get most people to behave better, including me.  :-)

> What I do not understand: if your bussines model stands. Why don't
> you look for investors and then in turn that money is spend in
> outsourcing the project to paid C++ programmers? You are still the
> boss of the design and poject.

Because chasing investors consumes lots of time.  Time is a resource worth
money.  Talking to MBAs is not my strong suit, I'm a programmer and artist,
not a MBA.  I can do it to some degree, but only to a degree.  First and
foremost I'm a software architect and I'm going to architect things
properly.  That means not architecting stuff in timewasting languages like
C++.  I don't believe that farming it all out overseas is the best course.
First you need some money to do that, and I currently have none.  I'll play
the game differently when I do have wads of money, but I'm facing the
realities of bootstrapping right now.

Second you have control issues, you can't give the Indians your whole job
because then they'll just steal your stuff.  How are you going to sue them
overseas?  You won't be able to.  So you have to keep a core for yourself,
and that core should be something they can't do themselves.  Ergo, I need to
be the CTO 'brains', and only farm out the non-brainy, repetitive, tedious
labor stuff to overseas outfits.  That's not a trivial set of architectural
decisions to make, actually.

Finally, my strategic goal is to amplify the power of a solo programmer.  I
don't believe in this 'team mentality' the rest of the computer world has.
What I see are softwares getting written by big expensive teams that don't
accomplish all that much, because there's no will to do anything other than
throw bodies at problems.  All of industry's tools are designed with teams
in mind, never individuals.  The capital intensive approach does work,
sorta, but it can never be used by those who lack capital.  This in turn
restricts creative freedom.  The more suits holding onto the money, the more
boring your game or art project has to be.  Ultimately, I want one lone
auteur to be able to produce viable interactive works for public sale.

That's an idealistic vision.  I'm not in business for myself to just make
money, I'm in it to fulfil my ideals.  For me, that's what being an indie is
about.  I want to control the means of production, design it according to my
own terms.  Not some cattle pack's terms.  I want to make millions of
dollars doing exactly what *I* want to do.  Doing what I want to do comes
first, before any money.  I'm not getting that time back before I die, and
chasing around a bunch of MBA idiots with no vision ain't my idea of a good
time.

My problems overlap other people's problems to some degree, and that is
where Open Source business models become possible.

> If your bussines model is sound and ready,

"Sound and ready?"  That in and of itself is a contradiction in terms.
Business models that are being readied for deployment aren't sound, they're
calculated risks.

> why are you sure then
> that you will grasp OCaml within a couple of days?

Who said I thought so?  Who said I haven't put a lot of time into
understanding OCaml already?

> A conservative
> estimate would be along the lines of 1 year for mastering  OCaml
> programming in production code. It is the same when Stroustroup says
> that mastering C++ for production code takes one at least 6 to 12
> months provided he will programm every day in C++.

That's a gross overestimate for an experienced coder.  OCaml is only a
language, after all.  The main work of a project is its design and
architecture, not its language.  Languages merely facilitate or hinder the
design more or less.

> Fensterbrett
> PS: Just out of curiosity: did you ever consider Haskell for your
> journey to heaven?

I have chased down information about Haskell.  Nothing I looked at made me
take it seriously.
I see no evidence that it's anything other than an academic project.  It
doesn't have performance, and it doesn't make any nods to commercial
relevance.  Between Haskell and OCaml, for commercial purposes the choice is
bluntly obvious.  Haskell may end up having the more far reaching impact
upon academic language R&D, but that is totally irrelevant to game
developers here and now.

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

Brandon's Law (after Godwin's Law):
"As a Usenet discussion grows longer, the probability of
a person being called a troll approaches one RAPIDLY."

0
8/18/2004 10:03:05 AM
Stefan Axelsson wrote:
>
> Not to turn you off the 'one true path' (i.e. functional programming)
> but it just occurred to me that Cyclone
> (http://www.research.att.com/projects/cyclone/) might fit your bill.
> Have you looked at it?

I haven't, although I think I may have heard of it.  I'm not interested in
figuring out the dynamics of Yet Another Language Forum (YALF) at the
moment.  The main reason I'm even vaguely considering Felix in any sense at
all is because John Skaller has been on caml-list so much, and private
conversations with him have actually gone somewhere.  My current attitude
is, OCaml has to completely bite me in the ass for me to give up on it right
now.  I really haven't attempted the proof of concept yet, and that's the
only way to definitively say yea or nay.  Otherwise one risks prevarication
forever.

Duly bookmarked.

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

"Troll" - (n.) Anything you don't like.
Usage: "He's just a troll."

0
8/18/2004 10:10:15 AM
Alan Bal jeu wrote:
>>>>
>>>> Have you looked at Hierarchical A* by Holte et al?
>
> It seems applicable to your problem.  It proposes abstracting parts
> of the problem away, and then after a good candidate is identified
> put the details back in.

That would seem to assume that the terrain is classifiable into chunks whose
more abstract representations are "worth it."  I can think of scattered
twisty maze problems that would never be worth it.

An approach that I've considered, which I wouldn't call 'hierarchical', is
to just classify uniform terrain areas as convex polyhedra.  If you've got a
huge desert in Saudi Arabia then it could all be just one big uniform
terrain node.  Of course, this approach assumes you're tracing linear paths
across these polyhedra, and it isn't computationally cheap to do that sort
of thing.  Ergo I'm not worrying about it anymore, because I think
discretization into some form, like hexes, is pretty much what games have to
do in the here and now.  I suppose I could do a discrete version of the same
idea, classifying rougly convex regions of uniform hex terrain into sets.

However, there's still the problem of which way a path cuts across a region.
It could skirt the edge of a region, or go straight across it.  Thus the
notion of a region isn't so useful.  You could put a maximum bound on it,
i.e. all paths across a circle are no more than 2*r in length.  Maybe
there's a metric for minimum paths I haven't thought of, that relates to the
perimeter.  Either way, you're going to be dealing with chains of equations,
trying to guesstimate minimum and maximum path lengths with an awful lot of
flexibility.  I'm not sure this is really buying anything over just
searching directly.  It could buy something if the terrain region is 'large'
and paths aren't willy-nilly pathological, but what should we really expect
in the abstract?

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

Taking risk where others will not.

0
8/18/2004 10:22:50 AM
cr88192 wrote:
> "chris" <spamoff.danx@ntlworld.com> wrote in message 
> news:8ntUc.228$nI5.4@newsfe3-gui.ntli.net...
>>
>>Like a lot of posts in this thread, you could look at "Concepts, 
>>Techniques, and Models of Computer Programming" by Van Roy and Haridi. 
>>This covers relational programming in some depth as well as lots more 
>>programming techniques and models.  Admittedly I haven't read that chapter 
>>thouroughly yet (Relational DB programming ala SQL hurts my brain, so I 
>>wasn't paying attention to the Relational Model even though it's not about 
>>SQL - SQL just put me off), but it does seem to be relevant to what you 
>>hint at above.
>>
> 
> link?
> if the book is not downloadable and free then it doesn't do me much good...

A draft was free, but with the printing of the book this is no longer 
so.  Don't know where you are placed in the world, but the libraries 
round here (Glasgow, Scotland) will sometimes buy new books on request 
providing they don't have it already.  If you can get it out the 
library, I recommend the read.  The book website is

http://www.info.ucl.ac.be/people/PVR/book.html


>>Some of was harder to grasp what they where saying though.  I 
>>don't get delegation, constraint programming or
> 
> constraints are one of those things that seem cool, but are a poor semantic 
> match for many langs and I had previously had the bad experience of kludging 
> them onto a previous lang. comparatively evaluating the constraints is not 
> that hard (though I had only used acyclic ones). they also didn't seem to 
> mesh well with prototype object semantics.
> err, unless you are talking of a different kind of "constraints".

Constraints are kinda fuzzy to me, but as described in the book they did 
seem interesting and useful for certain problems.  Sadly the course on 
Constraint Programming isn't being run this year at uni, or I'd like to 
explore the concept furthers.  It'd be nice to solve a pratical problem 
with constraints.
0
spamoff.danx (197)
8/18/2004 11:31:38 AM
Gerry Quinn wrote:
>>
>>Encapsulation as information hiding. In OO, it is primarily the state of 
>>an object that is encapsulated. No obvious state exists in your 
>>MapUtilities example. You do not restrict accessibility. Nor, in a 
>>strong sense, scoping, because you just have to qualify the functions 
>>(that's what usually is called namespacing).
> 
> As I stated, MapUtilities might easily start without state and find 
> occasion to develop state during the development process.  I gave the 
> example of a scratchpad as a start.  Another state might be a boolean 
> variable that determines whether diagonal movement os possible.  But 
> state isn't the only issue here.  There might well be functions with 
> private or protected access that are not intended for use outside the 
> MapUtilities class.  

You proposed MapUtilities as a class, not an object. So your idea of 
adding a scratchpad either amounts to global state in the class (which 
is bad) or to a complete redesign of the class, turning formerly static 
methods into instance methods.

A class with only static methods is nothing but a simple module. Nothing 
particularly OO about it. Object-oriented encapsulation involves objects.

If you, OTOH, propose MapUtilities as an object (unlike you said 
originally), than I consider that a typical hammer+nail overkill 
example. It's not at all natural and the artificial indirection induced 
by it is pretty inconvenient.

>>The state is encapsulated, while the functions provide access to it 
>>(they are part of the capsule, not what is encapsulated). If there is no 
>>state (not even conceptually) then you do not have encapsulation, and it 
>>is more or less an abuse of objects.
> 
> That is nonsense.  Not all functions of a typical class are interface 
> methods.  And I also pointed out that MapUtilities might easily have a 
> state at some time, even if it has none now.

You are right about local functions, but that is not what I meant. What 
I (and supposedly Tomasz and Ketil) meant is what I explained above 
(admittedly, I could have been clearer before): if you don't have 
instance state, then you don't have/need an object, and hence no 
object-oriented encapsulation.

> Now you've got an object hanging around anyway, and a bunch of functions 
> that you are vague about where they are - in a namespace maybe - and 
> maybe a hanging boolean to determine whether diagonal movement is 
> possible.  I don't see the benefit compared to a single object.

I don't see the object, and you didn't say anything about an object, see 
above.

> You are mixing up description and classification.  What is fundamental 
> to a swallow is flying and eating insects; what is distinctive about it 
> is its forked tail.  And yes, it's a bird [the equivalent of saying a 
> language executes statements].

I don't think so, but Brandon already answered that one.

	- Andreas

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

Let's get rid of those possible thingies!  -- TB

0
rossberg (600)
8/18/2004 11:41:13 AM
Brandon J. Van Every wrote:
> 
>>Another view is that one should include the minimal set of features
>>that
>>will get the job done and don't add any feature unless it provides
>>significant benefit to the language that it wouldn't have had
>>  otherwise. It's like Occam's razor for programming languages, and
>>that's pretty much my point of view.
> 
> Does any language fulfil this point of view?

In fact, it is one of the things I like about SML - it pretty much 
achieves this goal. Its design probably is more radical in that respect 
than a lot of people feel comfortable with, though.

	- Andreas

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

Let's get rid of those possible thingies!  -- TB

0
rossberg (600)
8/18/2004 11:45:43 AM
"chris" <spamoff.danx@ntlworld.com> wrote in message 
news:u6HUc.341$CT4.215@newsfe3-gui.ntli.net...
> cr88192 wrote:
>> "chris" <spamoff.danx@ntlworld.com> wrote in message 
>> news:8ntUc.228$nI5.4@newsfe3-gui.ntli.net...
>>>
>>>Like a lot of posts in this thread, you could look at "Concepts, 
>>>Techniques, and Models of Computer Programming" by Van Roy and Haridi. 
>>>This covers relational programming in some depth as well as lots more 
>>>programming techniques and models.  Admittedly I haven't read that 
>>>chapter thouroughly yet (Relational DB programming ala SQL hurts my 
>>>brain, so I wasn't paying attention to the Relational Model even though 
>>>it's not about SQL - SQL just put me off), but it does seem to be 
>>>relevant to what you hint at above.
>>>
>>
>> link?
>> if the book is not downloadable and free then it doesn't do me much 
>> good...
>
> A draft was free, but with the printing of the book this is no longer so. 
> Don't know where you are placed in the world, but the libraries round here 
> (Glasgow, Scotland) will sometimes buy new books on request providing they 
> don't have it already.  If you can get it out the library, I recommend the 
> read.  The book website is
>
> http://www.info.ucl.ac.be/people/PVR/book.html
>
I am on guam.

I doubt it would be at a library here, as the libraries here tend to suck.

>
>>>Some of was harder to grasp what they where saying though.  I don't get 
>>>delegation, constraint programming or
>>
>> constraints are one of those things that seem cool, but are a poor 
>> semantic match for many langs and I had previously had the bad experience 
>> of kludging them onto a previous lang. comparatively evaluating the 
>> constraints is not that hard (though I had only used acyclic ones). they 
>> also didn't seem to mesh well with prototype object semantics.
>> err, unless you are talking of a different kind of "constraints".
>
> Constraints are kinda fuzzy to me, but as described in the book they did 
> seem interesting and useful for certain problems.  Sadly the course on 
> Constraint Programming isn't being run this year at uni, or I'd like to 
> explore the concept furthers.  It'd be nice to solve a pratical problem 
> with constraints.

I looked, oz uses a more complex constraint system than those I am fammilair 
with (acyclic, aka, "you modify inputs and outputs change").

dunno. I couldn't think of all that strong of a use for them (yes, they 
would be nice, but functions or such can do similar, albeit with a little 
more work if you want them to be cheap...).
the main issue, however, is integrating them with a language such that they 
wouldn't seem like a horrid kludge...

they could be treated like functions, but then they seem almost pointless.

yes, even good notation escapes me:
var x=input(), y=input();
var z=constraint(sqrt(x*x+y*y));

x(3);
y(4);
z() => 5

another possibility is for them to be special types that are generated in 
operations, and later "flattened out" into values:
var x=input(), y=input();
var z=sqrt(x*x+y*y);

x(3);
y(4);
z => 5

but this is much more complex for little gain.

yet another possibility, special variable type:
constraint x, y;
constraint z=sqrt(x*x+y*y);

x=3;
y=4;
z => 5

this is yet more complex, would require alterations to my interpreter 
(though these would likely be needed later anyways), and I would likely need 
multiple forms, and would pose general issues with my scoping system (would 
need 3 forms, 1 for each scoping system).

or maybe typesystem/variable "properties".

or something...

just in my case it doesn't seem to justify the work at present.



0
cr88192355 (1928)
8/18/2004 11:49:48 AM
cr88192 wrote:

> I looked, oz uses a more complex constraint system than those I am fammilair 
> with (acyclic, aka, "you modify inputs and outputs change").
>
> dunno. I couldn't think of all that strong of a use for them (yes, they 
> would be nice, but functions or such can do similar, albeit with a little 
> more work if you want them to be cheap...).
> the main issue, however, is integrating them with a language such that they 
> wouldn't seem like a horrid kludge...

I wasn't suggesting you implement Constraints, just that it might be 
worth a look at the Relational Programming chapter in the book if you 
can.  From what I read it provided what seemed to be a good model for 
working with databases and relations in general which seemed to fit with 
the idea you presented in the earlier post.

Constraint programming seems related to their model of relational 
programming (a generalisation) but it is another level of complexity of 
implementation (quite an involved one) and perhaps not  useful for the 
problems your language is designed to solve (if so, there is no point in 
having it).  The book covers both relational and constraint programming 
but the presentation of relational programming is iirc separate from 
constraint programming (the constraint stuff, which I haven't finished 
reading, builds on the relational stuff in some ways, but not vice versa).


Chris
0
spamoff.danx (197)
8/18/2004 1:28:12 PM
"chris" <spamoff.danx@ntlworld.com> wrote in message 
news:MPIUc.420$k57.87@newsfe6-gui.ntli.net...
> cr88192 wrote:
>
>> I looked, oz uses a more complex constraint system than those I am 
>> fammilair with (acyclic, aka, "you modify inputs and outputs change").
>>
>> dunno. I couldn't think of all that strong of a use for them (yes, they 
>> would be nice, but functions or such can do similar, albeit with a little 
>> more work if you want them to be cheap...).
>> the main issue, however, is integrating them with a language such that 
>> they wouldn't seem like a horrid kludge...
>
> I wasn't suggesting you implement Constraints, just that it might be worth 
> a look at the Relational Programming chapter in the book if you can.  From 
> what I read it provided what seemed to be a good model for working with 
> databases and relations in general which seemed to fit with the idea you 
> presented in the earlier post.
>
ok, makes sense.

> Constraint programming seems related to their model of relational 
> programming (a generalisation) but it is another level of complexity of 
> implementation (quite an involved one) and perhaps not  useful for the 
> problems your language is designed to solve (if so, there is no point in 
> having it).  The book covers both relational and constraint programming 
> but the presentation of relational programming is iirc separate from 
> constraint programming (the constraint stuff, which I haven't finished 
> reading, builds on the relational stuff in some ways, but not vice versa).
>
ok.

actually, I had thought about it some and I had figured the relational idea 
I came up with seemed a little hackish, so I decided to lay off for the time 
being...



0
cr88192355 (1928)
8/18/2004 1:30:05 PM
Andreas Rossberg wrote:
> Gerry Quinn wrote:
>> That is nonsense.  Not all functions of a typical class are interface 
>> methods.  And I also pointed out that MapUtilities might easily have a 
>> state at some time, even if it has none now.
>
> You are right about local functions, but that is not what I meant. What 
> I (and supposedly Tomasz and Ketil) meant is what I explained above 
> (admittedly, I could have been clearer before): if you don't have 
> instance state, then you don't have/need an object, and hence no 
> object-oriented encapsulation.

I was commenting on this particular example. I don't have anything
against objects without state in general - I use such things quite often
myself.

I will assume that stateless means ,,no fields/attributes/data
members'', and not ,,immutable state''. Objects with immutable state is
a bit different topic.

There are many uses for stateless objects in OOP. After all the sole
virtual table (or dictionary of methods) can be a useful state (but you
won't call a C++ object stateful just because it contains a vtable).
The ability to provide various implementations for methods allows to
parametrize behavior (policies, algoritms, etc.), also at runtime. Maybe
this MapUtilities class could be used in such a context, but it's name
suggests just a bunch of functions.

When I am programming in C++ and I introduce an abstract class (hmmm,
no state here too), it is often natural to provide some minimal
implementation. Think about streams (not C++ iostreams) and an "empty
stream" implementation which has no state - such classes often allow
to simplify code.

Best regards,
Tomasz

-- 
..signature: Too many levels of symbolic links
0
t.zielonka2 (138)
8/18/2004 6:46:25 PM
In article <2oghnbFajanlU1@uni-berlin.de>, 
try_vanevery_at_mycompanyname@yahoo.com says...
> Gerry Quinn wrote:
> >
> > You are mixing up description and classification.  What is fundamental
> > to a swallow is flying and eating insects; what is distinctive about
> > it is its forked tail.  And yes, it's a bird [the equivalent of saying a
> > language executes statements].
> 
> I"m not so sure Andreas mixed things up here.
> 
> Flying and eating insects is fundamental to A BIRD.  A swallow is a
> specialization of a bird, one with a forked tail.  I would say that having a
> forked tail is fundamental to being A SWALLOW.  I think the term
> 'fundamental' will inevitably depend upon the paradigm of recombination
> you're using.  It's easy to see BIRD::SWALLOW in an OO inheritance hierarchy
> sense.  Now, if we can get lotsa little fucking birds to all start fucking
> each other, exchanging their genetic material, maybe we'll have something
> more like a Functional paradigm?  Distinctions might no longer be
> fundamental; lotsa kinds of birds might have forked tails.

You're missing the point: what distinguishes something and what's 
fundamental to something are different categories.  If you approach 
matters from a purely classification-oriented point of view, this can be 
missed, because what is fundamental to YOU is the distinction.

But from a programming point of view, what is fundamental to OO is not 
affected by any other approaches that may need to be distinguished from 
it.  You cannot say "X is not fundamental to OO" by declaring an 
alternative approach (OO*) that also contains X.  When such an approach 
is declared, X no longer distinguishes OO, but whether it is fundamental 
to OO is unaffected.

- Gerry Quinn




0
gerryq (1329)
8/19/2004 8:28:02 AM
In article <cfvf8q$7osv1$1@hades.rz.uni-saarland.de>, rossberg@ps.uni-
sb.de says...
> Gerry Quinn wrote:
> >>
> >>Encapsulation as information hiding. In OO, it is primarily the state of 
> >>an object that is encapsulated. No obvious state exists in your 
> >>MapUtilities example. You do not restrict accessibility. Nor, in a 
> >>strong sense, scoping, because you just have to qualify the functions 
> >>(that's what usually is called namespacing).
> > 
> > As I stated, MapUtilities might easily start without state and find 
> > occasion to develop state during the development process.  I gave the 
> > example of a scratchpad as a start.  Another state might be a boolean 
> > variable that determines whether diagonal movement os possible.  But 
> > state isn't the only issue here.  There might well be functions with 
> > private or protected access that are not intended for use outside the 
> > MapUtilities class.  
> 
> You proposed MapUtilities as a class, not an object. So your idea of 
> adding a scratchpad either amounts to global state in the class (which 
> is bad) or to a complete redesign of the class, turning formerly static 
> methods into instance methods.

Again you seem to be confusing the issue by interpreting things I say in 
your own way.  I called MapUtilities a class, but I said from the start 
that such a class might or might not have state, and I gave examples of 
how the state might relate to a particular map.  At no point did I ever 
imply that it could not be instantiated - indeed I implied (see below 
for example) that instantiation was likely.  In short, when I propose 
something as a class, unless I say otherwise, I am not even remotely 
implying that it is not an object.  [Actually it can be argued that all 
classes with state are intrinsically objects; a class with only static 
members is effectively, albeit implicitly, instantiated once anyway.]

<QUOTE>
And the class methodology allows you to do it, with or without state.  
(Obviously it might be a small nuisance at some time to change from 
static to 'instance' functions, so if you plan to do this you should use 
non-static member functions from the start.)
<UNQUOTE>

> A class with only static methods is nothing but a simple module. Nothing 
> particularly OO about it. Object-oriented encapsulation involves objects.
> 
> If you, OTOH, propose MapUtilities as an object (unlike you said 
> originally), than I consider that a typical hammer+nail overkill 
> example. It's not at all natural and the artificial indirection induced 
> by it is pretty inconvenient.

I like the brackets "unlike you said originally".  When did I suggest it 
could not be an object?  But anyway it is very natural.  Consider the 
object as a little man who knows about map calculations, who may or may 
not have made a careful study of a particular map.  What's non-object-
like about that?  

> You are right about local functions, but that is not what I meant. What 
> I (and supposedly Tomasz and Ketil) meant is what I explained above 
> (admittedly, I could have been clearer before): if you don't have 
> instance state, then you don't have/need an object, and hence no 
> object-oriented encapsulation.

I think that is nonsense.  Objects can have state or they can be without 
state - it is immaterial to their status as objects.

> > Now you've got an object hanging around anyway, and a bunch of functions 
> > that you are vague about where they are - in a namespace maybe - and 
> > maybe a hanging boolean to determine whether diagonal movement is 
> > possible.  I don't see the benefit compared to a single object.
> 
> I don't see the object, and you didn't say anything about an object, see 
> above.

You weren't reading my posts very well - I certainly implied that 
instantiation of the class was likely.

Now I have one object - a little man who has studied a map, and who has 
a workpad for scratch calculations (he doesn't want to draw on the map).  
He can remember what I told him about whether diagonal movement is 
possible, or any other spacial issues to do with finding paths on the 
map.

You, by contrast, have a separate object for the scratch pad, and 
another boolean object for whether diagonal movement can occur, and a 
lot of functions I know not where, all presumably exposed which will 
cause problems if you change the implementation.  That seems a totally 
unsatisfactory approach.

- Gerry Quinn
0
gerryq (1329)
8/19/2004 8:50:22 AM
In article <slrnci78vs.ur0.t.zielonka@zodiac.mimuw.edu.pl>, 
t.zielonka@zodiac.mimuw.edu.pl says...
> Andreas Rossberg wrote:

> There are many uses for stateless objects in OOP. After all the sole
> virtual table (or dictionary of methods) can be a useful state (but you
> won't call a C++ object stateful just because it contains a vtable).
> The ability to provide various implementations for methods allows to
> parametrize behavior (policies, algoritms, etc.), also at runtime. Maybe
> this MapUtilities class could be used in such a context, but it's name
> suggests just a bunch of functions.

Actually I implied that it might have state and indeed multiple 
instantiations (if there are multiple maps and it has states relevant to 
a particular map).

I think it may be helpful to consider a second metaphor for objects 
other than the 'physical object' metaphor we are all familiar with.  I 
consider that many types of objects are better described as a bureaucrat 
behind a desk who can answer questions or pass messages about a 
particular subject.  He may or may not have state.  He might even be a 
bunch of functions.

If I need the capabilities such a bureaucrat can supply, I bring him in.  
Whether he is instantiated isn't really the most immediate question as 
far as I am concerned, if in his current state it doesn't matter.  

- Gerry Quinn
0
gerryq (1329)
8/19/2004 9:00:13 AM
In article <4fvUc.175650$eM2.133361@attbi_s51>, rainerd@eldwood.com 
says...
> Gerry Quinn wrote:
> > I doubt any situation can occur which would be in any way
> > difficult to express in C/C++ without the postfix operator.
> 
> Personally I have stopped using the postfix increment/decrement operators
> entirely.  However, I like the prefix increment/decrement operators.  For
> types some types (such as certain iterators), addition can only be
> implemented through repeated incrementation.  For these types, it is natural
> to use prefix '++' in preference over '+= 1'.

Each to his own.  Prefix never looks natural to me, so I avoid it almost 
entirely.

- Gerry Quinn
0
gerryq (1329)
8/19/2004 9:08:54 AM
In article <i8vUc.14371$N77.602064@news.xtra.co.nz>, me@here.there.com 
says...
> 
> I'd exclude things such as templates which I think have minimal value 
> for the complexity they add (both to the compiler, code analysis tools 
> and to the user)

I don't think templates have any place in 'normal' programming, but they 
are great for libraries where there will be massive re-use.

- Gerry Quinn
 
0
gerryq (1329)
8/19/2004 9:11:14 AM
"Brandon J. Van Every" wrote:

>
> I don't know that that's true.  It depends upon the degree of topic Nazism
> vs. civility enforcement.  I agree I wouldn't survive in a topic Nazi
> regime.  In a civil regime, I'd do fine.  I may post things that are pointed
> about a technology, but I don't attack people personally.  I often receive
> personal attacks for what I post, and that's part of what degrades a forum.
> The difference is that politically speaking, I get blamed for all personal
> attacks that come my way.  It's not someone else's fault for gratuitously
> ragging on me or ML Seattle, it's my fault for not being the academic /
> technical product that other people want to hear about.

Wit all due respect I do not think that the "Nazi" jargon is applicable here.
You can test it for yourself:

a) Write in comp.lang.functional that OCaml sucks big ass and that every man at
INRIA is an idiot. If you like I can report it to them. Nothing will happen
then neither will they hunt you nor will they bring you to court.

b) Write in Nazi-land that all the shit fucking Nazis suck and that AH is an
idiot. If you like I can report it to the imaginative SS headquarters.  I will
give you then a few days were you may enjoy your life until to your
death-penalty.

I for myself have been brought up in Nazi land, though, I am young (30 years
old)  and only had to cope with shit fucking Nazis when I had to talk to old
retired men who actually played the Nazi game.  However, I do not think that
the youth in Germany or Austria is susceptible for a revival of old Nazi land.

>
>
> > why are you sure then
> > that you will grasp OCaml within a couple of days?
>
> Who said I thought so?  Who said I haven't put a lot of time into
> understanding OCaml already?
>
> > A conservative
> > estimate would be along the lines of 1 year for mastering  OCaml
> > programming in production code. It is the same when Stroustroup says
> > that mastering C++ for production code takes one at least 6 to 12
> > months provided he will programm every day in C++.
>
> That's a gross overestimate for an experienced coder.  OCaml is only a
> language, after all.  The main work of a project is its design and
> architecture, not its language.  Languages merely facilitate or hinder the
> design more or less.

I am not objecting and questionating your ambitions but you shoudn't make the
mistake to underestimate the "getting used to new paradigm" time. It is as
simple as this: watching tennis players is easy and one can get a good feeling
for the sports in question; but it will be even harder to take the racket and
playing it.

Why I would wish that you would write some OCaml is the fact that I deeply
believe that not everybody can easily cope with a type system. That refers not
so much to understanding it rather to use it every day in ones own projects.
Surely, people will always say to you that a good type system is your friend,
but my experience actually is the more often it is your worst enemy.

You only can get such a feeling if you write own code.

But to something completely different: I would be more interested whether
people really believe that sucking up functional programming thinking is a
matter of a few days. Yes I know such discussions get bogged down quickly
because they will always say to you that this has been discussed to death.
However, in my google there is no eveidence for such a claim.


>
> I have chased down information about Haskell.  Nothing I looked at made me
> take it seriously.
> I see no evidence that it's anything other than an academic project.  It
> doesn't have performance, and it doesn't make any nods to commercial
> relevance.  Between Haskell and OCaml, for commercial purposes the choice is
> bluntly obvious.  Haskell may end up having the more far reaching impact
> upon academic language R&D, but that is totally irrelevant to game
> developers here and now.
>

What would you haved Python used for?

Fensterbrett

0
8/19/2004 9:19:01 AM
Gerry Quinn wrote:
> In article <i8vUc.14371$N77.602064@news.xtra.co.nz>, 
> me@here.there.com says...
> 
>> I'd exclude things such as templates which I think have minimal 
>> value for the complexity they add (both to the compiler, code 
>> analysis tools and to the user)
> 
> 
> I don't think templates have any place in 'normal' programming, but 
> they are great for libraries where there will be massive re-use.

Reuseability (composability, modularity, etc.) is a good property for 
any code to have. My suspicion is that the distinction between 'normal' 
programming and designing libraries is particular to C++ because writing 
good reuseable code in C++ demands uncommon expertise in the language.


Elsewhere Gerry Quinn wrote:

> In article <slrnchst53.4l6.neelk@gs3106.sp.cs.cmu.edu>, 
> neelk@cs.cmu.edu says...
> 

[...]

>> To use the design pattern jargon, any code using the Visitor, 
>> Composite, Interpreter, or Command patterns is a lot simpler when 
>> expressed with functional-style algebraic data types. (Actually 
>> having first-class functions simplifies a lot of other design 
>> patterns, too, but languages like Python and Smalltalk show that 
>> first-class functions are not foreign to OO.)
> 
> 
> 
> But of course the use of such patterns is optional.  So I would say 
> FP is giving you alternative ways to solve programming problems, 
> rather than solving problems per se.


But in FP the "option" is so natural that these things aren't even
perceived *as* problems any more than, say, writing "x + y" as the
'solution' to the 'problem' of summing x and y. Consequently, the very
notion of "design patterns" often seems a little odd from an FP
point-of-view.

-thant

0
thant (332)
8/19/2004 4:19:35 PM
Gerry Quinn wrote:
> In article <i8vUc.14371$N77.602064@news.xtra.co.nz>, me@here.there.com 
> says...
> 
>>I'd exclude things such as templates which I think have minimal value 
>>for the complexity they add (both to the compiler, code analysis tools 
>>and to the user)
> 
> 
> I don't think templates have any place in 'normal' programming, but they 
> are great for libraries where there will be massive re-use.

Well I'd have to agree since the facts bare that out - witness the STL. 
  Yet, it's precisely the example of the STL that makes me dislike 
templates.

What the STL *does* is great, *how* it does it is appalling.  The syntax 
is baroque, the error messages generated from it are appalling.  In 
addition, it bloats your code and compiles like molassess.  Of these 
issues, the readability of templated code is my biggest complaint. 
That, and the fact that it requires you to hardcode types throughout 
your code (given a vector, you can't just grab an iterator for it, you 
must know the generic type of the vector and use that for creating the 
iterator - all of which radically tightens the coupling between your 
generic types and code which uses them.  Very ugly.

It's not the idea of generic programming that I object to per se, but 
templates make me hurl.

Of course, each to their own, It seems that the maintainers of the C++ 
standard are enjoying making new ways to (ab)use the template mechanism 
to "enhance" the language.
0
me5036 (108)
8/19/2004 10:32:51 PM
Brandon J. Van Every wrote:

> Peter Ashford wrote:
> 
>>Another view is that one should include the minimal set of features
>>that
>>will get the job done and don't add any feature unless it provides
>>significant benefit to the language that it wouldn't have had
>>  otherwise. It's like Occam's razor for programming languages, and
>>that's pretty much my point of view.
> 
> 
> Does any language fulfil this point of view?  OCaml doesn't; old timers
> decry that it *used* to have clean syntax.  Python is as oriented towards
> keeping things clean as any language can be, probably, and still it gets new
> language features added to it.  Maybe it does so in a clean way, but it
> seems that language design is inevitably ongoing.  People just don't want to
> stop adding new stuff to a core system that's working.
> 

I think that Java until 1.5 had been resonably consistent about keeping 
the language simple and avoided adding features for the sake of it (in 
the core language NOT the APIs!!).
0
me5036 (108)
8/19/2004 10:34:34 PM
Siegfried Gonzi wrote:
> "Brandon J. Van Every" wrote:
>
>>
>> I don't know that that's true.  It depends upon the degree of topic
>> Nazism vs. civility enforcement.  I agree I wouldn't survive in a
>> topic Nazi regime.  In a civil regime, I'd do fine.  I may post
>> things that are pointed about a technology, but I don't attack
>> people personally.  I often receive personal attacks for what I
>> post, and that's part of what degrades a forum. The difference is
>> that politically speaking, I get blamed for all personal attacks
>> that come my way.  It's not someone else's fault for gratuitously
>> ragging on me or ML Seattle, it's my fault for not being the
>> academic / technical product that other people want to hear about.
>
> Wit all due respect I do not think that the "Nazi" jargon is
> applicable here. You can test it for yourself:
>
> a) Write in comp.lang.functional that OCaml sucks big ass and that
> every man at INRIA is an idiot. If you like I can report it to them.
> Nothing will happen then neither will they hunt you nor will they
> bring you to court.

That's abusive posting, not topic Nazism.  If you feel a need to do
experiments of this sort, using your own name and on your own time, by all
means who am I to stop you?

> b) Write in Nazi-land that all the shit fucking Nazis suck and that
> AH is an idiot. If you like I can report it to the imaginative SS
> headquarters.  I will give you then a few days were you may enjoy
> your life until to your death-penalty.
>
> I for myself have been brought up in Nazi land, though, I am young
> (30 years old)  and only had to cope with shit fucking Nazis when I
> had to talk to old retired men who actually played the Nazi game.
> However, I do not think that the youth in Germany or Austria is
> susceptible for a revival of old Nazi land.

"Topic Nazi" just means someone who's rather anal about whether things are
on-topic or not.  Compare "Soup Nazi" from Seinfeld, where you had to wait
in line in *exactly* the right way or NO SOUP FOR YOU!!!

> But to something completely different: I would be more interested
> whether people really believe that sucking up functional programming
> thinking is a matter of a few days. Yes I know such discussions get
> bogged down quickly because they will always say to you that this has
> been discussed to death. However, in my google there is no eveidence
> for such a claim.

I don't think there's anything credible in claiming FP only takes a few days
to understand, and I haven't heard anyone make that claim.

> What would you haved Python used for?

Funny you should ask that.  It turns out I need a production pipeline
immediately, so I'm back to worrying about Nebula2
http://nebuladevice.cubik.org , C++, and Python.  I will work with these
until I have time to add OCaml support.  Also I think non-technical people
will do way better with Python than with OCaml, so I might keep it for
artist written scripts, even if real programmers end up using OCaml.

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

"We live in a world of very bright people building
crappy software with total shit for tools and process."
                                - Ed Mckenzie

0
8/20/2004 1:45:20 AM
"Brandon J. Van Every" wrote:

> "Topic Nazi" just means someone who's rather anal about whether things
> are
> on-topic or not.

And with a degree in sociocultural anthropology, no less.

-- 
 __ Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
/  \ San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
\__/ All I know is / I need you in my life
    -- India Arie
0
max78 (1220)
8/20/2004 4:19:54 AM
"Brandon J. Van Every" wrote:

>
>
> > What would you haved Python used for?
>
> Funny you should ask that.  It turns out I need a production pipeline
> immediately, so I'm back to worrying about Nebula2
> http://nebuladevice.cubik.org , C++, and Python.  I will work with these
> until I have time to add OCaml support.  Also I think non-technical people
> will do way better with Python than with OCaml, so I might keep it for
> artist written scripts, even if real programmers end up using OCaml.

Let me ask the following. How do you estimate your luck that your game will
really gain momentum? I played the last time on my computer 8 years ago, so I
am not representative for a player. However, I red a news the other day that
games in Germay do not hook on because as opposed to games from America they
are way too complicated. I cannot comment on this, though.

I think it must be extremly hard to forecast whether people will like my game
or not. Personally I wouldn't have such nerves.

Do you ask people in polls what they would like to play with?

Fentserbrett

>

0
8/20/2004 7:15:48 AM
> I don't know that that's true.  It depends upon the degree of topic
> Nazism vs. civility enforcement.  I agree I wouldn't survive in a
> topic Nazi regime.  In a civil regime, I'd do fine.  I may post
> things that are pointed about a technology, but I don't attack people
> personally.  I often receive personal attacks for what I post, and
> that's part of what degrades a forum. The difference is that
> politically speaking, I get blamed for all personal attacks that come
> my way.  It's not someone else's fault for gratuitously ragging on me
> or ML Seattle, it's my fault for not being the academic / technical
> product that other people want to hear about.

Brandon, you're infamous for attacking the beliefs and practices of others,
if not the others themselves, without the application of logical thought and
then participating in protracted defenses of things you should never have
said in the first place.

A perfect example was your multi-week diatribe defending your assertion that
learning C or C++ had no commercial value.

    WTH


0
spamsucks (63)
8/20/2004 8:13:39 AM
In article <cg2jud$h8$1@news.xmission.com>, thant@acm.org says...
> Gerry Quinn wrote:
> > 
> > I don't think templates have any place in 'normal' programming, but 
> > they are great for libraries where there will be massive re-use.
> 
> Reuseability (composability, modularity, etc.) is a good property for 
> any code to have. My suspicion is that the distinction between 'normal' 
> programming and designing libraries is particular to C++ because writing 
> good reuseable code in C++ demands uncommon expertise in the language.

Well, your suspicion is unfounded, because writing good re-usable code 
in C++ is perfectly possible without the use of powerful but complex / 
awkward features such as templates.  It is more accurate to say that C++ 
has these powerful features available for when they are needed.

> >> To use the design pattern jargon, any code using the Visitor, 
> >> Composite, Interpreter, or Command patterns is a lot simpler when 
> >> expressed with functional-style algebraic data types. (Actually 
> >> having first-class functions simplifies a lot of other design 
> >> patterns, too, but languages like Python and Smalltalk show that 
> >> first-class functions are not foreign to OO.)
> > 
> > But of course the use of such patterns is optional.  So I would say 
> > FP is giving you alternative ways to solve programming problems, 
> > rather than solving problems per se.
> 
> But in FP the "option" is so natural that these things aren't even
> perceived *as* problems any more than, say, writing "x + y" as the
> 'solution' to the 'problem' of summing x and y. Consequently, the very
> notion of "design patterns" often seems a little odd from an FP
> point-of-view.

I didn't say they were problems.  I said that there are certain 
programming problems that may or may not be solved using these 
particular patterns, and if the patterns are not amenable to a 
particular language, others will be used.  [I'm not one for pattern 
jargon myself, but recognisable coding patterns of various kinds do 
exist, in algorithms and in individual languages.]

In truth, your comments above appear to be verging on the sillier end of 
FP advocacy.  "Magic FP makes every problem transparent".  How come the 
list of real-world applications is so short, then?

- Gerry Quinn
0
gerryq (1329)
8/20/2004 9:49:38 AM
In article <CU9Vc.15351$N77.630040@news.xtra.co.nz>, me@here.there.com 
says...
> Gerry Quinn wrote:
> > 
> > I don't think templates have any place in 'normal' programming, but they 
> > are great for libraries where there will be massive re-use.
> 
> Well I'd have to agree since the facts bare that out - witness the STL. 
>   Yet, it's precisely the example of the STL that makes me dislike 
> templates.
> 
> What the STL *does* is great, *how* it does it is appalling.  The syntax 
> is baroque, the error messages generated from it are appalling.  In 
> addition, it bloats your code and compiles like molassess.  Of these 
> issues, the readability of templated code is my biggest complaint. 

Hang on, the syntax FOR THE USER is fine [references are a bit similar 
in a much smaller way - for the beginner functions that take reference 
as parameters are easy to use, but a little harder to write].  Error 
messages - well, maybe - it's harder for a debugger to get into a vector 
than a straight C-style array.  The bloating - nonsense, there is a 
small element of duplication, but I've never seen major bloat.  
Compiling hasn't been an issue either.  And readability?  I said it was 
for libraries, i.e. the STL user doesn't have to read it.

> That, and the fact that it requires you to hardcode types throughout 
> your code (given a vector, you can't just grab an iterator for it, you 
> must know the generic type of the vector and use that for creating the 
> iterator - all of which radically tightens the coupling between your 
> generic types and code which uses them.  Very ugly.

Now that's very dubious; all you are complaining about is a form of 
static type checking.  If you are using an iterator on something, 
presumably you know, or should know, what the heck you are using it on.  
Also, vector is (in my experience) by far the the most commonly used 
collection class, and there is usually no need to use an iterator on it 
- an array index tends to be more transparent:

for ( int i = 0; i < myVec.size(); i++ )
{
	DoStuff( myVec[ i ] );
}

You normally only want iterators when you are erasing parts of a vector.

Finally, if you don't like STL, it's possible to use something else.  
The MFC templated list classes, for example, have a standard POSITION 
type for iterators, but unlike Java, each collection is generic so you 
don't have to cast a list element to whatever it's supposed to be every 
time you use it (surely as onerous as casting iterators in STL).  The 
problem - if it's a problem - is not with templates per se, it's with a 
particular library.

> It's not the idea of generic programming that I object to per se, but 
> templates make me hurl.

My whole point was: templates should be used only by highly-skilled 
programmers to provide library services that will be re-used very 
extensively.  You shouldn't ever have to look at them unless you're in 
this position.  

- Gerry Quinn
0
gerryq (1329)
8/20/2004 10:06:48 AM
In article <4125A524.39F63892@kfunigraz.ac.at>, 
siegfried.gonzi@kfunigraz.ac.at says...

> Let me ask the following. How do you estimate your luck that your game will
> really gain momentum? I played the last time on my computer 8 years ago, so I
> am not representative for a player. However, I red a news the other day that
> games in Germay do not hook on because as opposed to games from America they
> are way too complicated. I cannot comment on this, though.

You aren't a player!  That news almost certainly refers to board games, 
not computer games.  (In board games there is a 'German games' genre, 
which, whether due to good taste or snobbishness, are considered by 
afficionados to be greatly superior to those favoured by the common 
herd.)

- Gerry Quinn
0
gerryq (1329)
8/20/2004 10:09:59 AM
Gerry Quinn wrote:
> In article <cg2jud$h8$1@news.xmission.com>, thant@acm.org says...
> 
>>Gerry Quinn wrote:
>>
>>>I don't think templates have any place in 'normal' programming, but 
>>>they are great for libraries where there will be massive re-use.
>>
>>Reuseability (composability, modularity, etc.) is a good property for 
>>any code to have. My suspicion is that the distinction between 'normal' 
>>programming and designing libraries is particular to C++ because writing 
>>good reuseable code in C++ demands uncommon expertise in the language.
> 
> 
> Well, your suspicion is unfounded, because writing good re-usable code 
> in C++ is perfectly possible without the use of powerful but complex / 
> awkward features such as templates.  It is more accurate to say that C++ 
> has these powerful features available for when they are needed.

Templates are the single best thing about C++. Yes, their syntax is 
ugly. Yes, the error messages are incomprehensible. But their power to 
facilitate code reuse in C++ is unmatched. They also allow for 
programming techniques that are otherwise very impractical. My point was 
that although templates are considered by many to be a complex feature 
reserved for experts for use in library building, this is because C++ is 
complex, not because the ideas which motivated the creation of templates 
are complex. That is, parameterized types are not complex. Their 
manifestation as templates in C++ is monstrously complex. The tragic 
result is that C++ will forever poison people against these otherwise 
extremely valuable concepts.

[...]

> In truth, your comments above appear to be verging on the sillier end of 
> FP advocacy.  "Magic FP makes every problem transparent".

FP makes many of the programming tasks addressed by so-called "design 
patterns" transparent--most notably the ones mentioned by Neel 
Krishnaswami quoted above.


>  How come the 
> list of real-world applications is so short, then?

Culture, infrastructure, network effects, prejudice. Let me turn the 
question around. How come the advanced C++ community puts so much effort 
into incorporating the lessons of FP into C++ even though the results 
are always compromised? Issues like garbage collection and threading 
weigh heavily on the minds of those who wish to influence C++'s future, 
but the state of the art has long since moved on.

Elsewhere:

> Also, vector is (in my experience) by far the the most commonly used 
> collection class, and there is usually no need to use an iterator on it 
> - an array index tends to be more transparent:
> 
> for ( int i = 0; i < myVec.size(); i++ )
> {
> 	DoStuff( myVec[ i ] );
> }
> 
> You normally only want iterators when you are erasing parts of a vector.

Here's an example of how you write code in C++ in a way that makes it 
modular and easy to modify later:

struct MyStruct {

	typedef std::vector<Thingy> ThingyContainer;
	ThingyContainer thingy_container;

};

/*...*/

for (ThingyContainer::const_iterator i = thingy_container.begin();
      i!=thingy_container.end();
      ++i) {

	DoStuff(*i);
}

This will allow you to replace the vector with a deque or list or set if 
you need to by changing a single line of code.

-thant



0
thant (332)
8/20/2004 3:09:37 PM
On Tue, 17 Aug 2004, Gerry Quinn wrote:

> And yes, it's a bird [the equivalent of saying a
> language executes statements].
>

A significant proportion of functional languages (arguably all depending
on your definition) /don't/ execute statements, that being a fundamental
property of them.

-- 
flippa@flippac.org
0
flippa (196)
8/20/2004 4:13:20 PM
Siegfried Gonzi wrote:
> "Brandon J. Van Every" wrote:
>>
>>> What would you haved Python used for?
>>
>> Funny you should ask that.  It turns out I need a production pipeline
>> immediately, so I'm back to worrying about Nebula2
>> http://nebuladevice.cubik.org , C++, and Python.  I will work with
>> these until I have time to add OCaml support.  Also I think
>> non-technical people will do way better with Python than with OCaml,
>> so I might keep it for artist written scripts, even if real
>> programmers end up using OCaml.
>
> Let me ask the following. How do you estimate your luck that your
> game will really gain momentum?

We aren't leaving it to luck.  When it's time, we'll make a proper marketing
effort.

Right now I'm only concerned with proving that we have a production pipeline
that can absorb art, audio, and code.  I want a 5 minute interactive art
piece, not even a game.  If we can reach this milestone then I'll consider
my partnership with my art-business friend to be viable.  Also we would have
something to hand off to some MBA friends of his.  They'd shop it around and
use it to get funding.

> I played the last time on my computer
> 8 years ago, so I am not representative for a player. However, I red
> a news the other day that games in Germay do not hook on because as
> opposed to games from America they are way too complicated. I cannot
> comment on this, though.
>
> I think it must be extremly hard to forecast whether people will like
> my game or not. Personally I wouldn't have such nerves.

I'm too arrogant to care whether people like my game or not.  What I mean by
that is, it's not my job as a Game Designer to wring my hands.

It *is* my job to make accomodation both to my business partner and to the
tastes of the general public, to the degree that I want to make money and
establish notoriety.  For instance his tastes run more towards twitchy FPS
than to wargames.  Also I don't think he has any idea how to bootstrap, he
seems to think in terms of "get money people and go big big big."  Also he
is more of an artist than a gamer, I have a lot more experience with many
kinds of games than he does.  That's ok; he can be the Art Director and CEO,
I'll be the Game Designer and CTO.  We each have some skill in the other's
area, so that's a check and balance.  Well, he doesn't know much of anything
about programming, so that puts me in a good position right now.

Anyways, that means as Game Designer and CTO I'm going to make some tough
decisions about what direction we're going to take, game design-wise.  You
might not "have the nerves," but I am sure of what I can inflict upon the
world.  I only worry about how much time and money it will take.  I
definitely have a bootstrapping mentality, as well as an exit strategy
mentality if the partnership fizzles.

> Do you ask people in polls what they would like to play with?

Nope.  I do go to the game stores, look at what's on the shelves, and roll
my eyes, however.  Also I make it a point to eventually play any game that
has wild commercial success, so that I'm conversant with the mainstream
industry trends.

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

Taking risk where others will not.

0
8/20/2004 5:16:42 PM
"Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com> wrote in
message news:2ogoipFacjhsU1@uni-berlin.de...
> Alan Bal jeu wrote:
> >>>>
> >>>> Have you looked at Hierarchical A* by Holte et al?
> >
> > It seems applicable to your problem.  It proposes abstracting parts
> > of the problem away, and then after a good candidate is identified
> > put the details back in.
>
> That would seem to assume that the terrain is classifiable into chunks
whose
> more abstract representations are "worth it."  I can think of scattered
> twisty maze problems that would never be worth it.

This just shows that your problem is more complex than the samples
discussed in the paper.  A simple mapping may be difficult to achieve
for your case.  But it's worth trying anyway.

>
> An approach that I've considered, which I wouldn't call 'hierarchical', is
> to just classify uniform terrain areas as convex polyhedra.
That still qualifies as hierarchical.  'Uniform' may not be necessary.
Mostly uniform can still be approximated pretty well.

>
> However, there's still the problem of which way a path cuts across a
region.
> It could skirt the edge of a region, or go straight across it.  Thus the
> notion of a region isn't so useful.  You could put a maximum bound on it,
> i.e. all paths across a circle are no more than 2*r in length.  Maybe
> there's a metric for minimum paths I haven't thought of, that relates to
the
> perimeter.  Either way, you're going to be dealing with chains of
equations,
> trying to guesstimate minimum and maximum path lengths with an awful lot
of
> flexibility.  I'm not sure this is really buying anything over just
> searching directly.  It could buy something if the terrain region is
'large'
> and paths aren't willy-nilly pathological, but what should we really
expect
> in the abstract?

It's all up to you to decide what works or doesn't.  You can try an
abstraction where
the choices are "around" and "through" for some larger terrain.  Maybe you
can make it work, or maybe you can't.



0
jeu (11)
8/21/2004 3:33:08 AM
"Philippa Cowderoy" <flippa@flippac.org> wrote in message 
news:Pine.WNT.4.53.0408201712290.1316@SLINKY...
> On Tue, 17 Aug 2004, Gerry Quinn wrote:
>
>> And yes, it's a bird [the equivalent of saying a
>> language executes statements].
>>
>
> A significant proportion of functional languages (arguably all depending
> on your definition) /don't/ execute statements, that being a fundamental
> property of them.
>
yes, and a functional language is not a bird.

maybe more like a large insect (a lot smaller with well defined properties, 
but somewhat lacking in "mass", and largely uninterested in being like a 
bird).

presently there are no mammals in this world though...



0
cr88192355 (1928)
8/21/2004 8:04:12 AM
In article <Pine.WNT.4.53.0408201712290.1316@SLINKY>, flippa@flippac.org 
says...
> On Tue, 17 Aug 2004, Gerry Quinn wrote:
> 
> > And yes, it's a bird [the equivalent of saying a
> > language executes statements].
> >
> A significant proportion of functional languages (arguably all depending
> on your definition) /don't/ execute statements, that being a fundamental
> property of them.

No argument there.  So they are something other than birds.

- Gerry Quinn
0
gerryq (1329)
8/21/2004 9:38:58 AM
"Gerry Quinn" <gerryq@DELETETHISindigo.ie> wrote in message 
news:MPG.1b91288cf7af95c59898b0@news.indigo.ie...
> In article <Pine.WNT.4.53.0408201712290.1316@SLINKY>, flippa@flippac.org
> says...
>> On Tue, 17 Aug 2004, Gerry Quinn wrote:
>>
>> > And yes, it's a bird [the equivalent of saying a
>> > language executes statements].
>> >
>> A significant proportion of functional languages (arguably all depending
>> on your definition) /don't/ execute statements, that being a fundamental
>> property of them.
>
> No argument there.  So they are something other than birds.
>
Cicada!!!



0
cr88192355 (1928)
8/21/2004 9:56:47 AM
In article <cg5477$urg$1@news.xmission.com>, thant@acm.org says...
> Gerry Quinn wrote:

> Templates are the single best thing about C++. Yes, their syntax is 
> ugly. Yes, the error messages are incomprehensible. But their power to 
> facilitate code reuse in C++ is unmatched. They also allow for 
> programming techniques that are otherwise very impractical. My point was 

Object orientation provides more code re-use than templates IMO.  I 
think they are cool, but not the be-all and end-all of C++.  At the end 
of the day, C++ is successful because it is (or contains) C with 
objects.

> that although templates are considered by many to be a complex feature 
> reserved for experts for use in library building, this is because C++ is 
> complex, not because the ideas which motivated the creation of templates 
> are complex. That is, parameterized types are not complex. Their 
> manifestation as templates in C++ is monstrously complex. The tragic 
> result is that C++ will forever poison people against these otherwise 
> extremely valuable concepts.

Library building is not for beginners.  As for the complexity of 
implementation, I guess it's a pity you weren't there to point out the 
easy way to do it without throwing out essential elements of the 
language.

> > In truth, your comments above appear to be verging on the sillier end of 
> > FP advocacy.  "Magic FP makes every problem transparent".
> 
> FP makes many of the programming tasks addressed by so-called "design 
> patterns" transparent--most notably the ones mentioned by Neel 
> Krishnaswami quoted above.

Sure, but those are somewhat gossamer patterns.  I think this relates to 
a point about FP that I will come to later.

> >  How come the 
> > list of real-world applications is so short, then?
> 
> Culture, infrastructure, network effects, prejudice. Let me turn the 
> question around. How come the advanced C++ community puts so much effort 
> into incorporating the lessons of FP into C++ even though the results 
> are always compromised? Issues like garbage collection and threading 
> weigh heavily on the minds of those who wish to influence C++'s future, 
> but the state of the art has long since moved on.

Firstly, I don't pay too much heed to the thoughts of the "advanced C++ 
community".  Like the "advanced art community" they seem to have lost 
track of - or care little for - issues that the less advanced thinkers 
among us would see as fundamental.  [Incidentally, I don't know what 
threading and GC have particularly to do with FP.]

Secondly, I looked up "functional programming real world" in Google. I 
found a page http://homepages.inf.ed.ac.uk/wadler/realworld/ [not 
working this morning] and frankly it was pretty unimpressive.  If even 
the work of a single C++ shareware author such as myself (or many 
another) were added to it, it would look a lot better.  Seriously, there 
must be literally *thousands* of you FP enthusiasts out there, you claim 
your languages work miracles in eradicating the complexities of more-
commonly used ones, there are themes that could surely be relevant and 
don't need much graphic support - a good Go player for example - so 
where is the software?  It just ain't good enough, folks.

But thirdly, I thought about this, and about a functional language of 
sorts that I have used ("Zillions Rules File Language", a language that 
describes the rules of games for the Zillions-of-Games 
engine/processor), and I came to an interesting conclusion: FUNCTIONAL 
LANGUAGES ARE NOT REALLY GENERAL PURPOSE PROGRAMMING LANGUAGES.  The 
title of the "OO vs FP" thread, from which this one came, is a sham.

ZRFL is a good example of an effective functional language, with over a 
thousand user-contributed games. They refer to it as a scripting 
language, but its nature is functional.  But it needs an engine to 
interpret it.  Zillions of Games is written in C or C++, and the idea of 
trying to write it in a FP would have been silly.  Where ZRFL comes in 
is writing down a series of 'algorithms' describing how pieces move in a 
straightforward way.   

That, IMO, is where functional languages belong.  Somewhere on the 
programming / data interface.  In scripting certain types of operation 
such as the rules of chess-like games, or rules for parsing languages.  
But not as competition for genuine general-purpose programming 
languages.  In that sphere, they just don't cut the mustard.

Some points to back up my thesis:

1. Your argument that FP makes design patterns vanish.  Sure - they are 
to do with programming languages!

2. "Pure" FP is often accepted to be incapable of general-purpose 
programming - no side effects, and you *need* side effects.  You see, 
what I'm telling you here, you really knew all along...


> Elsewhere:
> 
> Here's an example of how you write code in C++ in a way that makes it 
> modular and easy to modify later:
>
[using iterator on a vector]
> 
> This will allow you to replace the vector with a deque or list or set if 
> you need to by changing a single line of code.

I am well aware that STL was designed in such a way as to make that 
possible.  And again, if you are building a library on top of 
generalised collection iterators, it is no doubt very useful.  But in 
day-to-day code, all it saves is a trivial refactoring in rare 
circumstances. If I start with a vector, and it's probably going to stay 
a vector, I will generally use the familiar C-style pattern.

Incidentally, in all but the simplest cases I would modify your code and 
mine to get rid of the pointer dereference or array index in the middle 
(which might be repeated at several points):

for ( ThingyContainer::const_iterator i = thingy_container.begin();
		i != thingy_container.end(); i++ ) 
{
	// At the start
	Thingy & thing = *i;
	DoStuff( thing );
}

My version could be similarly modified by writing:
	Thingy & thing = myVec[ i ];

The point being that refactoring becomes entirely trivial anyway with 
care to such issues.

- Gerry Quinn






0
gerryq (1329)
8/21/2004 10:50:09 AM
"Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com> wrote
in news:2ompblFc81dbU1@uni-berlin.de: 

>> Do you ask people in polls what they would like to play with?
> 
> Nope.  I do go to the game stores, look at what's on the shelves, and
> roll my eyes, however.  Also I make it a point to eventually play any
> game that has wild commercial success, so that I'm conversant with the
> mainstream industry trends.

Hmmm plain spoken, and above board. Interesting.

I probably spend too much time in the gaming newsgroups but that comment 
definetly would heat up a discussion there. The present mainstream 
industry is considered to be in reversal. Few new games, even fewer 
decent ones. Mostly new versions of older games that did wellm even 
though the new version is done by a lesser team and teribly 
disappointing. More work done on the packaging of the box and the ads 
than on the game itself. But you make it sound like thats the direction 
you are knowingly headed down so I guess thats OK. Kindof the fast-food 
of gaming.

The hot topics in the newsgroups at the moment have shifted strongly 
toward indie games that are published but available thru online sites 
only. Even games which were released years ago. I would call them 
successes but not what would be considered "wild commercial success"

But then you should consider me biased since Im on the publishing side 
with a definate preference for good long-life strategic games even if 
they arent as glitzy as the usual shelfware. 

Gandalf  Parker
-- most of "my favorite sites" includes
ShrapnelGames.com, Dom2minions.com, SDmud.org,
Community.Net, Techno-Mage.com, and Alt-Hacker.org, 

0
gandalf6 (51)
8/21/2004 2:05:32 PM
[En-t�te "Followup-To:" positionn� � comp.lang.functional.]
Le 10-08-2004, Brandon J. Van Every <try_vanevery_at_mycompanyname@yahoo.com> a �crit�:
> Siegfried Gonzi wrote:
>> "Brandon J. Van Every" wrote:
>>
>>> I get closer to understanding the performance implications of OCaml
>>> and how
>>> to tie it to low level C code.  The C FFI is not so great, it's kinda
>>> clunky.
>>
>> Can you elaborate a bit on that. What do you miss from the FFI?
>
> Ocaml does not natively understand 32-bit integers!  It only uses 31-bit
> integers, keeping 1 bit for garbage collection purposes.  Personally I'm not
> at all pleased with this language design choice.  

This is not exactly accurate. Ocaml does provide the Int32 (and also
Int64 & NativeInt) module, which gives *boxed* 32 bits integers (boxed
means that you pass a pointer to a box containing the 32 integer).

Of course, you pay for the 32nd bit thru the boxing. The 31bit
integers are unboxed (because they are tagged).

So the choice between 31 and 32 bits integers is (as usual) a
price/performance tradeoff.

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/ 
email: basile<at>starynkevitch<dot>net 
aliases: basile<at>tunes<dot>org = bstarynk<at>nerim<dot>net
8, rue de la Fa�encerie, 92340 Bourg La Reine, France
0
8/21/2004 3:16:50 PM
In article <Xns954C487792B7Bgandalfparker@208.201.224.154>, 
gandalf@most.of.my.favorite.sites says...
> 
> I probably spend too much time in the gaming newsgroups but that comment 
> definetly would heat up a discussion there. The present mainstream 
> industry is considered to be in reversal. Few new games, even fewer 
> decent ones. Mostly new versions of older games that did wellm even 
> though the new version is done by a lesser team and teribly 
> disappointing. More work done on the packaging of the box and the ads 
> than on the game itself. But you make it sound like thats the direction 
> you are knowingly headed down so I guess thats OK. Kindof the fast-food 
> of gaming.

"considered to be in reversal" seems too strong.  People bitch about 
games, always have done, always will do.

- Gerry Quinn
0
gerryq (1329)
8/21/2004 4:37:10 PM
On Sat, 21 Aug 2004, Gerry Quinn wrote:
> 2. "Pure" FP is often accepted to be incapable of general-purpose
> programming - no side effects, and you *need* side effects.  You see,
> what I'm telling you here, you really knew all along...
>

Ah. That's why I've got code for an IRC bot in Haskell on my HD. It all
depends on your values of "pure" and/or "side effect" - if you accept that
a functional language may include functions that cannot be defined in it,
it's perfectly possible to make them behave purely.

-- 
flippa@flippac.org
0
flippa (196)
8/21/2004 4:46:51 PM
Gerry Quinn <gerryq@DELETETHISindigo.ie> wrote in
news:MPG.1b918a8f6c44dd869898b5@news.indigo.ie: 

> In article <Xns954C487792B7Bgandalfparker@208.201.224.154>, 
> gandalf@most.of.my.favorite.sites says...
>> 
>> I probably spend too much time in the gaming newsgroups but that
>> comment definetly would heat up a discussion there. The present
>> mainstream industry is considered to be in reversal. Few new games,
>> even fewer decent ones. Mostly new versions of older games that did
>> wellm even though the new version is done by a lesser team and
>> teribly disappointing. More work done on the packaging of the box and
>> the ads than on the game itself. But you make it sound like thats the
>> direction you are knowingly headed down so I guess thats OK. Kindof
>> the fast-food of gaming.
> 
> "considered to be in reversal" seems too strong.  People bitch about 
> games, always have done, always will do.

Yes but usually there is some back and forth traffic on both sides about 
new games. Lately there have been more questions about why there is NO 
traffic about the new games. WHen someone posts "whats the latest xxxxxxx 
game you would recommend" the replies tend to be games that have been out 
for almost a year.

Many of the glitzy-package/full-page-ad type of publishers seem to be 
downsizing, dropping projects, or even going under completely. Not all, 
but there seems to be more bad news than good about the big favorites for 
6 months or so.

Again, I may be biased since those are the companies that some of our 
indie developers have pointed at and say "why dont you do that for me?" 
but lately we have had hard examples we can reply back with as "did you 
see what is happening with xxxxx?"

Gandalf  Parker
0
gandalf6 (51)
8/21/2004 5:47:51 PM
cr88192 wrote:
> "Philippa Cowderoy" <flippa@flippac.org> wrote in message
>> 
> yes, and a functional language is not a bird.
> 
> maybe more like a large insect (a lot smaller with well defined
> properties, but somewhat lacking in "mass", and largely uninterested
> in being like a bird).
> 
> presently there are no mammals in this world though...

I hereby propose a new language to be called ALBATROSS.

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

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

0
8/21/2004 6:39:18 PM
cr88192 wrote:
> "Gerry Quinn" <gerryq@DELETETHISindigo.ie> wrote in message
>> 
>> No argument there.  So they are something other than birds.
>> 
> Cicada!!!

EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE


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

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

0
8/21/2004 6:40:18 PM
Alan Bal jeu wrote:
> "Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com>
> wrote in message news:2ogoipFacjhsU1@uni-berlin.de...
>> Alan Bal jeu wrote:
>>>>>>
>>>>>> Have you looked at Hierarchical A* by Holte et al?
>>>
>>> It seems applicable to your problem.  It proposes abstracting parts
>>> of the problem away, and then after a good candidate is identified
>>> put the details back in.
>>
>> That would seem to assume that the terrain is classifiable into
>> chunks whose more abstract representations are "worth it."  I can
>> think of scattered twisty maze problems that would never be worth it.
>
> This just shows that your problem is more complex than the samples
> discussed in the paper.

I'm not that interested in papers that can't deal with 'soup'.  One might
say that limiting the scope of a problem is academically valid, to better
understand something, or put bounds on what can or can't be done.  But, one
might also view it as a way to generate papers without taking much risk.  A
promotion of seeming consequence, i.e. careerism, rather than actual
consequence.  Or maybe a damage control strategy when one's research blows
up in one's face.  "Shit I gotta publish *something*...."

> A simple mapping may be difficult to achieve
> for your case.  But it's worth trying anyway.

Um, *why* is it worth trying anyway?  If you sit down with pencil and paper,
and determine that complicated topologies cannot actually be represented
hierarchically without loss of information, why on Earth should you try to
implement it anyways?  Don't trust your algorithmic design skills?

>> An approach that I've considered, which I wouldn't call
>> 'hierarchical', is to just classify uniform terrain areas as convex
>> polyhedra.
>
> That still qualifies as hierarchical.

I don't see why.  It's just an unequal area representation.

> 'Uniform' may not be necessary.
> Mostly uniform can still be approximated pretty well.

A difficulty for game purposes is how many units get in the way of movement
and keep changing the terrain around.  Moving 1 guy through a completely
empty landscape is a much easier problem.  For instance, a field with large
boulders in it is easy to pass if you're alone, and difficult to pass if
enemies are positioning themselves between the boulders.  One could make
guesses about how many enemies are going to prevent one's movement.  One
could also make guesses about one's ability to kill them.  We're rapidly
getting into a realm of guessing.  An abstraction of terrain might be
acceptable as 'base case' knowledge, but that knowledge doesn't scale.

>> However, there's still the problem of which way a path cuts across a
>> region. It could skirt the edge of a region, or go straight across
>> it.  Thus the notion of a region isn't so useful.
>
> It's all up to you to decide what works or doesn't.  You can try an
> abstraction where
> the choices are "around" and "through" for some larger terrain.
> Maybe you can make it work, or maybe you can't.

There's no 'maybe' about it.  It doesn't work.  Where 'works' == actually
generates reachable paths, actually generates shortest paths.  If you don't
do full analysis, you get what you pay for.  Hierarchization is loss of
information.  Sorry if that torpedoes a whole class of academic research,
but them's the breaks.  They could all work on 'better guesses' instead, but
guesses in the absence of information can only be so good.  Not much work to
be done there, except to write the definitive paper that says "these are the
bounds of the problem's solveability."

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

20% of the world is real.
80% is gobbledygook we make up inside our own heads.



0
8/21/2004 7:01:47 PM
Gandalf Parker wrote:
> "Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com> wrote
> in news:2ompblFc81dbU1@uni-berlin.de:
>
>>> Do you ask people in polls what they would like to play with?
>>
>> Nope.  I do go to the game stores, look at what's on the shelves, and
>> roll my eyes, however.  Also I make it a point to eventually play any
>> game that has wild commercial success, so that I'm conversant with
>> the mainstream industry trends.
>
> Hmmm plain spoken, and above board. Interesting.
>
> I probably spend too much time in the gaming newsgroups but that
> comment definetly would heat up a discussion there. The present
> mainstream industry is considered to be in reversal. Few new games,
> even fewer decent ones. Mostly new versions of older games that did
> wellm even though the new version is done by a lesser team and teribly
> disappointing. More work done on the packaging of the box and the ads
> than on the game itself.

That sounds like what I see in the stores.

> But you make it sound like thats the
> direction you are knowingly headed down so I guess thats OK. Kindof
> the fast-food of gaming.

WTF??!? how do you conclude that because I observe the mainstream industry,
I embrace it?

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

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

0
8/21/2004 7:05:44 PM
Gerry Quinn wrote:
>
> But thirdly, I thought about this, and about a functional language of
> sorts that I have used ("Zillions Rules File Language", a language
> that describes the rules of games for the Zillions-of-Games
> engine/processor), and I came to an interesting conclusion: FUNCTIONAL
> LANGUAGES ARE NOT REALLY GENERAL PURPOSE PROGRAMMING LANGUAGES.  The
> title of the "OO vs FP" thread, from which this one came, is a sham.
>
> ZRFL is a good example of an effective functional language, with over
> a thousand user-contributed games. They refer to it as a scripting
> language, but its nature is functional.  But it needs an engine to
> interpret it.  Zillions of Games is written in C or C++, and the idea
> of trying to write it in a FP would have been silly.

You haven't said what this engine does.

>Where ZRFL comes in
> is writing down a series of 'algorithms' describing how pieces move
> in a straightforward way.
>
> That, IMO, is where functional languages belong.  Somewhere on the
> programming / data interface.  In scripting certain types of operation
> such as the rules of chess-like games, or rules for parsing languages.

Ok, fine, this is sorta tangible in a hand-wavy sorta way.  You seem to be
saying that FP is suitable for 'algorithms'.  But...

> But not as competition for genuine general-purpose programming
> languages.  In that sphere, they just don't cut the mustard.

You haven't said what this general-purpose programming task is.  Is it IO?
Is it UI?  Is it crunching stuff really really fast?  Something else?

If you thought you explained it, well I have to say your explanation was not
terribly clear.  N.B. We don't need to discuss 'Pure' FP.  Plenty of FP
languages are impure and have side effects available, like OCaml.  They're
just highlighted as "Please think before you do this, you might be better
off without the side effect."  I agree that having no side effects is a
cumbersome straitjacket, much as I'd be annoyed if I was forced to write
every problem in a cute recursive style.

I think the recombinative features of FP are what's potentially relevant
about them.  "Better templates," in a nutshell.

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

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

0
8/21/2004 7:22:42 PM
Gerry Quinn wrote:
> Secondly, I looked up "functional programming real world" in
> Google. I found a page
> http://homepages.inf.ed.ac.uk/wadler/realworld/ [not
> working this morning] and frankly it was pretty unimpressive.  If
> even
> the work of a single C++ shareware author such as myself (or many
> another) were added to it, it would look a lot better.
> Seriously, there must be literally *thousands* of you FP
> enthusiasts out there, you claim your languages work miracles in
> eradicating the complexities of more- commonly used ones, there
> are themes that could surely be relevant and don't need much
> graphic support - a good Go player for example - so
> where is the software?  It just ain't good enough, folks.

http://sint.sourceforge.net/


-- 
Rainer Deyke - rainerd@eldwood.com - http://eldwood.com


0
rainerd (86)
8/21/2004 7:35:21 PM
Gerry Quinn wrote:

[...]


> [...] As for the complexity of implementation, I guess it's a pity 
> you weren't there to point out the easy way to do it without throwing
>  out essential elements of the language.

It is hard to argue that C++ could have been designed better given the
goal of extending C. It is, however, easy in hindsight to question the
wisdom of the original decision to maintain C compatibility in the first
place given the length to which it has been taken and the value of what
has been given up in the process. And my purpose in participating in
this thread is to draw attention exactly to what has been given up. But 
you can't know it unless and until you do significant development in 
other languages for yourself.


> Firstly, I don't pay too much heed to the thoughts of the "advanced 
> C++ community".  Like the "advanced art community" they seem to have 
> lost track of - or care little for - issues that the less advanced 
> thinkers among us would see as fundamental.  [Incidentally, I don't 
> know what threading and GC have particularly to do with FP.]

Memory management and threading are examples of tasks that even
non-expert C/C++ programmers typically have to deal with. The "advanced
C++ community" are those non-beginners you talk about trying to design
libraries to make dealing with these issues easier. But threading and
memeory management are also examples of issues that don't have to be 
difficult.

[...I responded to more, but it was a distraction...]


> I am well aware that STL was designed in such a way as to make that 
> possible.  And again, if you are building a library on top of 
> generalised collection iterators, it is no doubt very useful.  But in
>  day-to-day code, all it saves is a trivial refactoring in rare 
> circumstances. [...]

It was merele meant to provide an example of a much more general style
that should permeate all of your code and at many levels. At that point
the "refactoring" benefits are not at all trivial. More than that, one
should try to match idioms with semantics. If you're iterating, use
iterators. If you're indexing randomly, use indexing notation. They are
different tasks. Besides facilitating "refactoring" as you put it, it
makes the intention more transparent. An artifical distinction between
library-design and 'normal' coding should not be used as an excuse to
shrug off good style, even if C++ makes it difficult for beginners.


-thant
0
thant (332)
8/21/2004 8:18:15 PM
Andreas Rossberg <rossberg@ps.uni-sb.de> wrote in message news:<cfcoi0$7c8vg$1@hades.rz.uni-saarland.de>...
> Mutable state is the GOTO of data structures.
> 
> 	- Andreas

No, this is not true in our experience.  Mutable state is essential for
reasons of program modularity, in a much deeper way than GOTO,
which can be replaced sufficiently, e.g., by control structures
including nonlocal exit.  Mutable state cuts much deeper.  See the
following discussion on Lambda the Ultimate:
  http://lambda-the-ultimate.org/classic/message9361.html
You can also see my book "Concepts, Techniques, and Models of
Computer Programming", where the advantages and disadvantages
of mutable state are explained at length.

Peter Van Roy
0
pvr (28)
8/21/2004 8:26:12 PM
Gandalf Parker wrote:

> Yes but usually there is some back and forth traffic on both sides
> about
> new games. Lately there have been more questions about why there is NO
> traffic about the new games. WHen someone posts "whats the latest
> xxxxxxx
> game you would recommend" the replies tend to be games that have been
> out
> for almost a year.

So wait, you're judging the health of the computer gaming industry based
on the activity in newsgroups?

-- 
 __ Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
/  \ San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
\__/ Who shall stand guard to the guards themselves?
    -- Juvenal
0
max78 (1220)
8/21/2004 10:18:13 PM
Peter Van Roy wrote:

> You can also see my book "Concepts, Techniques, and Models of
> Computer Programming", where the advantages and disadvantages
> of mutable state are explained at length.

I love that book.  It's really very readable and illuminating!  I 
especially liked the chapters on concurrency and also the discussions of 
polymorphism and inheritence.  From the background in programming I came 
from it wasn't clear exactly how they separate.  It's clear now that 
they are separate ideas that they can be used together, unlike before 
were they seemed to be tightly coupled.  The book gives a lot of 
insights and clarifications like this, which is why I enjoyed reading it.

Thanks for a good read!


Chris
0
spamoff.danx (197)
8/22/2004 1:14:26 AM
Erik Max Francis <max@alcyone.com> wrote in
news:4127CA25.B38A1C6B@alcyone.com: 

> Gandalf Parker wrote:
> 
>> Yes but usually there is some back and forth traffic on both sides
>> about new games. Lately there have been more questions about why
>> there is NO traffic about the new games. WHen someone posts "whats
>> the latest xxxxxxx game you would recommend" the replies tend to be
>> games that have been out for almost a year.
> 
> So wait, you're judging the health of the computer gaming industry
> based on the activity in newsgroups?

No I tend to judge the quality of the gaming industry based on the 
newsgroups. And trends also. I judge the health of the gaming industry 
based on the industries inside magazines.

Gandalf  Parker
0
gandalf6 (51)
8/22/2004 2:25:24 AM
"Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com> wrote
in news:2opk42Fd9738U1@uni-berlin.de: 

>> But you make it sound like thats the
>> direction you are knowingly headed down so I guess thats OK. Kindof
>> the fast-food of gaming.
> 
> WTF??!? how do you conclude that because I observe the mainstream
> industry, I embrace it?

Im sorry. I admit I did jump in the middle of the thread. I got the 
impression that you were seeking it as a path to pursue. Im glad to hear 
that you dont.

Gandalf  Parker
0
gandalf6 (51)
8/22/2004 2:29:47 AM
"Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com> wrote in 
message news:2opikbFc9cncU1@uni-berlin.de...
> cr88192 wrote:
>> "Gerry Quinn" <gerryq@DELETETHISindigo.ie> wrote in message
>>>
>>> No argument there.  So they are something other than birds.
>>>
>> Cicada!!!
>
> EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
>
yep.

[storm... may lose power or net...]
0
cr88192355 (1928)
8/22/2004 5:16:03 AM
Thant Tessman wrote:
>
> It is hard to argue that C++ could have been designed better given the
> goal of extending C. It is, however, easy in hindsight to question the
> wisdom of the original decision to maintain C compatibility in the
> first place given the length to which it has been taken and the value
> of what has been given up in the process.

Nonsense.  C is the only thing that can *still* talk to all the languages
out there.  The question is why stick with C++ when better options are
available, not whether C++ should have had C compatibility.

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

"Trollhunt" - (n.) A searching out for persecution
of persons accused of Trolling. (c.f. witch-hunt)

0
8/22/2004 8:03:43 AM
Gandalf Parker wrote:
> "Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com> wrote
> in news:2opk42Fd9738U1@uni-berlin.de:
>
>>> But you make it sound like thats the
>>> direction you are knowingly headed down so I guess thats OK. Kindof
>>> the fast-food of gaming.
>>
>> WTF??!? how do you conclude that because I observe the mainstream
>> industry, I embrace it?
>
> Im sorry. I admit I did jump in the middle of the thread. I got the
> impression that you were seeking it as a path to pursue. Im glad to
> hear that you dont.

I'm a diehard Independent Games Festival judge, for that matter.
http://www.igf.com .  The "innovation * execution" scoring system has the
word 'innovation' in it because I thought it would be best to wave that word
under everyone's nose constantly, and the contest chair agreed.  It is Noah
Falstein's scoring system, and it has proven to be a good one, but
originally his categories were "conception * execution."  Once the IGF
decided its primary mission was to reward innovation, and all the awards got
renamed from "Best So-and-So" to "Innovation in So-and-So," I thought it
fairly evident that conception always meant innovation.  So, an incremental
change.  But it's best to iron out these political intents and repeat them
often.

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

When no one else sells courage, supply and demand take hold.

0
8/22/2004 8:18:38 AM
cr88192 wrote:
> "Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com>
> wrote in message news:2opikbFc9cncU1@uni-berlin.de...
>> cr88192 wrote:
>>> "Gerry Quinn" <gerryq@DELETETHISindigo.ie> wrote in message
>>>>
>>>> No argument there.  So they are something other than birds.
>>>>
>>> Cicada!!!
>>
>> EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
>>
> yep.
>
> [storm... may lose power or net...]

Speaking of power, when my Dad first went to North Carolina to look for
houses, he thought something was wrong with the electrical lines.  But of
course it was just a thousand cicadas...

I never really liked the things.  They're so 'armored'.  They're like the
stubby dwarves of the insect world.  I think I tortured them once or twice.
But I didn't do it nearly so often as some other things, because there was
something about the way they made that sound that seemed sorta human-like.
Too much vibration.  Like they were really pathetic, helpless, and deserving
pity.  They weren't a nasty-feeling insect, and they were big and vibrating
a bunch, so somehow that made it seem less like a bug and more like an
animal.  Sorta.

I'd probably feel better about 'em nowadays, but it's been many years since
I've seen 'em.  My folks retired in South Carolina, so I guess I just
haven't been down there at the right time of year.

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

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

0
8/22/2004 8:26:57 AM
In article <2opl3tFde93uU1@uni-berlin.de>, 
try_vanevery_at_mycompanyname@yahoo.com says...
> Gerry Quinn wrote:

> > ZRFL is a good example of an effective functional language, with over
> > a thousand user-contributed games. They refer to it as a scripting
> > language, but its nature is functional.  But it needs an engine to
> > interpret it.  Zillions of Games is written in C or C++, and the idea
> > of trying to write it in a FP would have been silly.
> 
> You haven't said what this engine does.

Well, you could have visited the site or downloaded the trial version!  
Basically, you use ZRFL to define the rules (piece moves, goals, 
graphics etc.) of a game - it is ideally made for chess-like games but 
can handle a wide variety, though you couldn't really do Monopoly.

Then the Zillions engine reads this and uses minimax searching and I 
suppose various basic heuristics to do with general mobility and 
mobility-based piece values etc. to play the game.  You can also play 
network games with other humans.

There are over 1000 user-contributed games, some with variants.

> > But not as competition for genuine general-purpose programming
> > languages.  In that sphere, they just don't cut the mustard.
> 
> You haven't said what this general-purpose programming task is.  Is it IO?
> Is it UI?  Is it crunching istuff really really fast?  Something else?

Just making a big old desktop application such as a game.

> If you thought you explained it, well I have to say your explanation was not
> terribly clear.  N.B. We don't need to discuss 'Pure' FP.  Plenty of FP
> languages are impure and have side effects available, like OCaml.  

Looks very 'impure' - I glanced at some code and it seems like there's 
lots of procedural stuff in there.

- Gerry Quinn
0
gerryq (1329)
8/22/2004 10:02:31 AM
In article <ZtNVc.50090$mD.12225@attbi_s02>, rainerd@eldwood.com says...
> Gerry Quinn wrote:
> > Secondly, I looked up "functional programming real world" in
> > Google. I found a page
> > http://homepages.inf.ed.ac.uk/wadler/realworld/ [not
> > working this morning] and frankly it was pretty unimpressive.  If
> > even
> > the work of a single C++ shareware author such as myself (or many
> > another) were added to it, it would look a lot better.
> > Seriously, there must be literally *thousands* of you FP
> > enthusiasts out there, you claim your languages work miracles in
> > eradicating the complexities of more- commonly used ones, there
> > are themes that could surely be relevant and don't need much
> > graphic support - a good Go player for example - so
> > where is the software?  It just ain't good enough, folks.
> 
> http://sint.sourceforge.net/

Well, fair dues - they should let the author of the FP page know, as it 
doesn't look good at present, yet seems widely referenced.

Though a glance at the source doesn't fill me with enthusiasm for the 
role of FP in games...

- Gerry Quinn

0
gerryq (1329)
8/22/2004 10:04:12 AM
In article <cg8am9$fi6$1@news.xmission.com>, thant@acm.org says...
> Gerry Quinn wrote:
[--]

> It is hard to argue that C++ could have been designed better given the
> goal of extending C. It is, however, easy in hindsight to question the
> wisdom of the original decision to maintain C compatibility in the first
> place given the length to which it has been taken and the value of what
> has been given up in the process. And my purpose in participating in

The fundamental basis of C++ was "C with objects".  The name of the 
language itself implies C-compatibility.  If C++ had not been C-
compatible, it would (i) have been completely fundamentally different, 
and (ii) had a different name.  According to any of the common 
metaphysical schools of thought, it would not have been C++ at all.  

> this thread is to draw attention exactly to what has been given up. But 
> you can't know it unless and until you do significant development in 
> other languages for yourself.

Nothing was 'given up' by the fact of C++ development.  There are 
hundreds of languages, and perhaps some of them are closer to what you 
see as desirable.  Your objection to C++ would appear to be based on its 
popularity, as I don't see you saying that anything was 'given up' 
whenever an obscure language was invented.

"Significant development" - but you ducked the issue when I pointed out 
that little enough has been developed in FPs even by their advocates.  
Again, if the benefits are so great, why don't you FP-ers show up us 
stick-in-the-muds by developing stunning applications - if FP actually 
does make things radically better, that should be easy.  Unless, as I 
suspect, FP provides solutions mainly where there are no particular 
problems.

> > Firstly, I don't pay too much heed to the thoughts of the "advanced 
> > C++ community".  Like the "advanced art community" they seem to have 
> > lost track of - or care little for - issues that the less advanced 
> > thinkers among us would see as fundamental.  [Incidentally, I don't 
> > know what threading and GC have particularly to do with FP.]
> 
> Memory management and threading are examples of tasks that even
> non-expert C/C++ programmers typically have to deal with. The "advanced
> C++ community" are those non-beginners you talk about trying to design
> libraries to make dealing with these issues easier. But threading and
> memeory management are also examples of issues that don't have to be 
> difficult.

Well, if they design better libraries we will use them when appropriate, 
and if they don't we'll continue to do as we have been doing, with 
reasonable success.  But IIRC the names of some of those involved in 
such things coincide with the names of some who, for example, are 
unaware or have forgotten that objects in C++ encapsulate functions - 
basic issues like that.

> > I am well aware that STL was designed in such a way as to make that 
> > possible.  And again, if you are building a library on top of 
> > generalised collection iterators, it is no doubt very useful.  But in
> >  day-to-day code, all it saves is a trivial refactoring in rare 
> > circumstances. [...]
> 
> It was merele meant to provide an example of a much more general style
> that should permeate all of your code and at many levels. At that point
> the "refactoring" benefits are not at all trivial. More than that, one
> should try to match idioms with semantics. If you're iterating, use
> iterators. If you're indexing randomly, use indexing notation. They are
> different tasks. Besides facilitating "refactoring" as you put it, it
> makes the intention more transparent. An artifical distinction between
> library-design and 'normal' coding should not be used as an excuse to
> shrug off good style, even if C++ makes it difficult for beginners.

I certainly would not wish my code to be permeated with the style you 
recommend.  Your code was longwinded and obscure, and must contain 
either extra name definitions or redefinitions of templated classes, and 
[overloaded] pointer dereferences.

By contrast the for..[] pattern also encapsulates an iteration pattern 
which is common, well-known, and simply and briefly expressed.

But perhaps obscurity in the service of some ill-defined and un-needed 
flexibility is seen as a virtue by some.
 
- Gerry Quinn

0
gerryq (1329)
8/22/2004 10:35:42 AM
"Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com> wrote in 
news:2or2ioFdj7q7U1@uni-berlin.de:

> I'm a diehard Independent Games Festival judge, for that matter.
> http://www.igf.com

Good to know. Love the site. 

I will probably come to the convention (being about an hour away). 
Do I need to duck and lurk? Are publishers "welcome" or would they be 
considered the way lawyers who are called "ambulance chasers" would be?

Gandalf  Parker


0
gandalf6 (51)
8/22/2004 5:01:08 PM
Gerry Quinn wrote:
> In article <2opl3tFde93uU1@uni-berlin.de>,
> try_vanevery_at_mycompanyname@yahoo.com says...
>> Gerry Quinn wrote:
>
>>> ZRFL is a good example of an effective functional language, with
>>> over
>>> a thousand user-contributed games. They refer to it as a scripting
>>> language, but its nature is functional.  But it needs an engine to
>>> interpret it.  Zillions of Games is written in C or C++, and the
>>> idea of trying to write it in a FP would have been silly.
>>
>> You haven't said what this engine does.
>
> Well, you could have visited the site or downloaded the trial version!

Gerry, I'm a busy man.  :-)  That's why I post so much!  And regardless of
what I can observe the engine to do, the question is what *you* think it
does.

> Then the Zillions engine reads this and uses minimax searching and I
> suppose various basic heuristics to do with general mobility and
> mobility-based piece values etc. to play the game.  You can also play
> network games with other humans.

So why mustn't these tasks be done with FP?

I'm currently building an AI architecture based upon the notion of a HexSet.
It's simply a set with 1 bit per hex.  It will be a trivial amount of C
code, and thus trivial to optimize in ASM.  I think I'll be able to use this
HexSet for just about everything.  Probably I'll be using FP to recombine
what you can do with various HexSets.  All efficiency concerns taken care of
just with 1 simple C type, though.

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

"witch-hunt" - (noun) (Date: 1885)
1: a searching out for persecution of persons accused
   of witchcraft
2: the searching out and deliberate harassment of
   those (as political opponents) with unpopular views
- witch-hunter (noun)
- witch-hunting (noun or adjective)

0
8/22/2004 5:15:21 PM
Brandon J. Van Every wrote:
> Thant Tessman wrote:
> 
>>It is hard to argue that C++ could have been designed better given the
>>goal of extending C. It is, however, easy in hindsight to question the
>>wisdom of the original decision to maintain C compatibility in the
>>first place given the length to which it has been taken and the value
>>of what has been given up in the process.
> 
> 
> Nonsense.  C is the only thing that can *still* talk to all the languages
> out there.  

This is backwards. C has become the de facto calling convention for 
operating system and hardware interfaces. Consequently, there is a huge 
incentive for other languages to support C calling conventions. In other 
words, it's not that C talks to all the other languages, it's that all 
the other languages talk to C. And just to be clear, what I meant by 
"maintain C compatibility" was the goal of extending C in a (mostly) 
backwards-compatible way, not just the ability to call C functions.


> The question is why stick with C++ when better options are
> available, not whether C++ should have had C compatibility.

Yes, one would think that this is exactly the question. But the 
conventional wisdom (as uttered by, for example, Gerry Quinn) is that 
the exact strength of C++ is that it is C with classes. This was in fact 
my own view when I first decided to learn C++.

-thant

0
thant (332)
8/22/2004 7:21:43 PM
Thant Tessman wrote:
> Brandon J. Van Every wrote:
>> Thant Tessman wrote:
>>
>>> It is hard to argue that C++ could have been designed better given
>>> the goal of extending C. It is, however, easy in hindsight to
>>> question the wisdom of the original decision to maintain C
>>> compatibility in the
>>> first place given the length to which it has been taken and the
>>> value
>>> of what has been given up in the process.
>>
>>
>> Nonsense.  C is the only thing that can *still* talk to all the
>> languages out there.
>
> This is backwards. C has become the de facto calling convention for
> operating system and hardware interfaces. Consequently, there is a
> huge incentive for other languages to support C calling conventions.
> In other words, it's not that C talks to all the other languages,
> it's that all the other languages talk to C.

You put a fine point on it, but how could it be any other way?  "Category
X," aka "Lingua Franca," ain't ever gonna talk to all the other languages.
All the other languages are going to talk to it.

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

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

0
8/22/2004 7:38:04 PM
Gerry Quinn wrote:

[...]

> "Significant development" - but you ducked the issue when I pointed out 
> that little enough has been developed in FPs even by their advocates.  
> Again, if the benefits are so great, why don't you FP-ers show up us 
> stick-in-the-muds by developing stunning applications - if FP actually 
> does make things radically better, that should be easy.  Unless, as I 
> suspect, FP provides solutions mainly where there are no particular 
> problems.

My most significant FP programming experince was on this project:

	http://makeashorterlink.com/?S40512C19

We used Chez Scheme as the foundation for the scripting language, and 
yes it made things radically better. I've worked on a few other things 
since then using Scheme and SML, but it would be inappropriate for me to 
talk about them. And in fact, I suspect most functional programmers 
simply don't care about C and C++, but the sad truth is that in my 
field, no one uses anything other than C or C++ because, in my 
experience, and with the possible exception of Java, no one even 
contemplates using anything other than C or C++. The issue simply never 
comes up.

[...]

-thant
0
thant (332)
8/22/2004 7:51:58 PM
"Brandon J. Van Every" wrote:

> Gerry Quinn wrote:
>
> > Well, you could have visited the site or downloaded the trial
> > version!
> 
> Gerry, I'm a busy man.  :-)  That's why I post so much!

That doesn't make the slightest bit of sense.

-- 
 __ Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
/  \ San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
\__/ Don't try to confuse me with the facts.
    -- Bill McNeal
0
max78 (1220)
8/22/2004 10:02:12 PM