f



FP tutorial for OO programmers?

Please assume a FP language that doesn't have OO capabilities.  For example,
Standard ML.  I'm looking for a no-nonsense, practical, concise, results
oriented tutorial that explains:

1) how to do things in FP that people typically do, or think they need to
do, in OO.
2) how to design FP programs that use underlying OO libraries.

I am not looking for airy fairy theoretical articles about the supposed
advantages of FP.  The real world is not usually clean slate architecture:
one ends up running into OO libraries and OO programmers.  For instance read
"Why no one uses functional languages."
http://portal.acm.org/citation.cfm?id=286387&dl=ACM&coll=portal

There's clearly a problem of paradigm shift here.  So, what are the
pragmatic solutions?

-- 
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
6/19/2004 8:41:54 PM
comp.lang.functional 2791 articles. 0 followers. Post Follow

444 Replies
2642 Views

Similar Articles

[PageSpeed] 16

Brandon J. Van Every wrote:

> I am not looking for airy fairy theoretical articles about the supposed
> advantages of FP.  The real world is not usually clean slate architecture:
> one ends up running into OO libraries and OO programmers.  For instance
> read "Why no one uses functional languages."
> http://portal.acm.org/citation.cfm?id=286387&dl=ACM&coll=portal

Is it possible to download this article for free somewhere?

Sincerely,
Gour


-- 
Gour                    | gour@mail.inet.hr
Registered Linux User   | #278493
GPG Public Key          | 8C44EDCD
0
gour (44)
6/20/2004 5:57:40 AM
Gour <gour@mail.inet.hr> writes:

>> advantages of FP.  The real world is not usually clean slate architecture:
>> one ends up running into OO libraries and OO programmers.  For instance
>> read "Why no one uses functional languages."
>> http://portal.acm.org/citation.cfm?id=286387&dl=ACM&coll=portal
>
> Is it possible to download this article for free somewhere?

Google is your friend...

www2-data.informatik.unibw-muenchen.de/ Lectures/FP/sigplan-why.pdf
0
rambam (304)
6/20/2004 6:30:25 AM
I R T wrote:

> Gour <gour@mail.inet.hr> writes:
> 
>>> advantages of FP.  The real world is not usually clean slate
>>> architecture:
>>> one ends up running into OO libraries and OO programmers.  For instance
>>> read "Why no one uses functional languages."
>>> http://portal.acm.org/citation.cfm?id=286387&dl=ACM&coll=portal
>>
>> Is it possible to download this article for free somewhere?
> 
> Google is your friend...
> 
> www2-data.informatik.unibw-muenchen.de/ Lectures/FP/sigplan-why.pdf

Thanks. I've found this version googling, but thought it's some shorted
version since the one on portal.acm.org says it's around 500K, but maybe
it's just complete journal issue.

Sincerely,
Gour

-- 
Gour                    | gour@mail.inet.hr
Registered Linux User   | #278493
GPG Public Key          | 8C44EDCD
0
gour (44)
6/20/2004 9:41:36 AM
Brandon J. Van Every wrote:
> Please assume a FP language that doesn't have OO capabilities.  For
> example, Standard ML.  I'm looking for a no-nonsense, practical,
> concise, results oriented tutorial that explains:

Hi Brandon,

I'm currently facing the same problem. I'm in charge of a rather
complicated, real-world, SML project (actually an SML .Net project) and
I have tried to find articles and books that could help me understand
the language and understand the source code I have to maintain. I didn't
find anything really helpful. Everything that has been written about SML
has been written by scientists for scientists, or rather by
mathematicians for mathematicians. SML *is* a language for researchers
and scientists, and as such it certainly does the job. But it's
certainly not a production tool for mainstream applications (this is
just my opinion and I'm not saying that SML is a "bad" language, though)

I found only one book : ML for the working programmer, Paulson,
Cambridge University Press
Although it's certainly a good book, I couldn't use it to solve the
practical problems I had (still have) understanding the project's code.

I also found a limited number of web sites:
http://www.dcs.napier.ac.uk/course-notes/sml/manual.html
http://www.dcs.ed.ac.uk/home/stg/NOTES/
http://www.lfcs.inf.ed.ac.uk/software/ML/
http://sml.sourceforge.net/Basis/
http://www.smlnj.org//index.html
http://burks.bton.ac.uk/burks/language/ml/

But this didn't solve my problems either.

I'd like to add the following comments too:

- SML is *extremely* difficult to debug and retro-document. Even though
SML .Net is better than the standard tools because Visual Studio .Net
provides some support for debugging, it's almost impossible to
understand and analyze existing code by stepping through it. The
recursive nature of SML makes this very difficult.

- I tried to find some support on Usenet. I found 2 newsgroups:
comp.lang.functional and comp.lang.ml. The level of activity in these
groups makes me wonder how much developers are using the language. You
can't produce without support and obviously, support for SML is scarce.

- Beside the compiler and the standard libraries, it's hard to find
tools that could help program and maintain SML code in a productive way.
For example, I needed a source code beautifier to reformat the SML
source code that I received from my customer. Such a tool just doesn't
exist (Emacs has an SML mode but this is clearly not enough - and after
all, we are now in the 21th century and don't see any good reason for
using Emacs - well, ok, I'm a Windows developer :-)) ). The only advice
that I got about this issue was: "It's easy to find an MSL parser and to
add code behind it to produce reformatted source code". I agree
(actually, I had the same idea), but my concern is productivity. This
answer is technically correct but typical from a researcher. I have
deadlines to meet, however. So I spent two days reformatting the code
manually.

- I'm still trying to understand what can be done in SML (or with any
functional programming language) that I couldn't do with an OOP language
that has introspection capabilities. Although I read a lot of documents,
I didn't find any feature in SML that has no equivalent in the OOP
world.

- About 20 years ago, when I was still working at IBM, I had to write
code using the APL language. A very powerful language with a big
drawback: when you go back to your code 10 days after you've written it,
you have difficulties understanding what you wanted to do at that time.
I have the exact same feeling with SML. So imagine when you've *not*
written the code yourself.

- Someone told me that the OCaml language was better supported (OCaml is
the OO version of Caml). This is not my feeling (not much books, only
one newsgroup).

For these reasons, an although I'm trying hard to analyze this SML code,
I'm considering switching to an OOP language and rewriting the code from
the specs using C#.

Greetings from Paris.
PS: I have spent a week in Seattle 2 months ago. Nice city.

-- 
Patrick Philippot - Microsoft MVP [.Net]
MainSoft Consulting Services
www.mainsoft.fr


0
6/20/2004 10:54:33 AM
Patrick Philippot wrote:
> 
> - SML is *extremely* difficult to debug and retro-document. Even 
> though SML .Net is better than the standard tools because Visual 
> Studio .Net provides some support for debugging, it's almost 
> impossible to understand and analyze existing code by stepping 
> through it. The recursive nature of SML makes this very difficult.
> 
> - About 20 years ago, when I was still working at IBM, I had to write
>  code using the APL language. A very powerful language with a big 
> drawback: when you go back to your code 10 days after you've written 
> it, you have difficulties understanding what you wanted to do at that
>  time. I have the exact same feeling with SML. So imagine when you've
>  *not* written the code yourself.

This is a question of being used to the standard idioms.
I had the same difficulties initially. After a while, I found myself
documenting less and less, and "seeing through" the idioms more and more.

> - I tried to find some support on Usenet. I found 2 newsgroups: 
> comp.lang.functional and comp.lang.ml. The level of activity in these
>  groups makes me wonder how much developers are using the language. 
> You can't produce without support and obviously, support for SML is 
> scarce.

Agreed.
There's currently no "large developer base".

> - Beside the compiler and the standard libraries, it's hard to find 
> tools that could help program and maintain SML code in a productive 
> way. For example, I needed a source code beautifier to reformat the 
> SML source code that I received from my customer. Such a tool just 
> doesn't exist (Emacs has an SML mode but this is clearly not enough -
>  and after all, we are now in the 21th century and don't see any good
>  reason for using Emacs - well, ok, I'm a Windows developer :-)) ). 
> The only advice that I got about this issue was: "It's easy to find 
> an MSL parser and to add code behind it to produce reformatted source
>  code". I agree (actually, I had the same idea), but my concern is 
> productivity. This answer is technically correct but typical from a 
> researcher. I have deadlines to meet, however. So I spent two days 
> reformatting the code manually.

Writing a beautifier shouldn't have taken more than 2 days either :-)
.... with the understanding that it takes a full day to find an SML
parser and understand how to use the hooks that need to be used for
producing formatted output, so there's a full day left to write the
actual beautifier.
(Heck, I've done this kind of work as a kid, and it didn't take me more
than a day using an imperative language. I didn't have to do a full
parse though, so I added the day - as such estimates go, your mileage
will certainly vary considerably.)

Of course, it would have been better to have a formatter readily available.

> - I'm still trying to understand what can be done in SML (or with any
>  functional programming language) that I couldn't do with an OOP 
> language that has introspection capabilities. Although I read a lot 
> of documents, I didn't find any feature in SML that has no equivalent
>  in the OOP world.

Closures.

I.e. the ability to take two functions submitted as parameters, place
the call to one of them in the parameter position of another one (if the
functions had N and M parameters, this gives me a new function of N+M-1
parameters), fill in a few other parameter positions with values, and
then return the whole thing so that other parts of the program execute
it if and when they need it.
Oh, and the ability to write down an expression that uses locals, and
return the entire thing - those locals are transferred into the closure
so that it will still work long after the function that houses the
expressions has finished running.

Java's inner classes can be used to mimick closures, though in an
extremely cumbersome way. (Closures were proposed as an alternative, and
were rejected on the basis that inner classes are "more OO".
Technically, they were right, but closures would still have been far,
far easier to use for event handlers and such.)

Of course, you can also construct a closure using a class. You "just"
need to write about 50 lines to handle class syntax, constructor, and an
"execute" function that houses the expression proper. Oh, and find a
good name for the class, write the JavaDoc stuff, make a unit test -
what's a single line of code not even worthy a second thought in a
functional language takes two full days in an OO language.


There's a more indirect advantage.
The more restricted a piece of code is, the easier it is to read - you
have less assumptions to check when it comes to understand why it does
what it does.
FPLs don't overwrite data (usually), so if you're chasing a bug, you
don't have to check your assumptions whether some data stays the same,
sparing you a lot of thought and and code-sifting effort.


Just my 2c.


Regards,
Jo
0
jo427 (1164)
6/20/2004 11:55:14 AM
Patrick Philippot wrote:
>
> I also found a limited number of web sites:
> But this didn't solve my problems either.

Thanks for the links, and I feel your pain.

> - I tried to find some support on Usenet. I found 2 newsgroups:
> comp.lang.functional and comp.lang.ml. The level of activity in these
> groups makes me wonder how much developers are using the language. You
> can't produce without support and obviously, support for SML is
> scarce.

I think mailing list archives are a fairer test.
SML/NJ's archive is puny.
https://sourceforge.net/mailarchive/forum.php?forum_id=10073
MLton's archive is a little better, but still quiet.
http://www.mlton.org/pipermail/mlton-user/
OCaml's is robust.
http://caml.inria.fr/caml-list-eng.html

I had forgotten about the "community viability" problem because OCaml has a
viable community.  Hrm.  Well, the reality is right now *I* have to write my
code, not a community.  What I really want is OCaml with 32-bit ints, 32-bit
floats, and a straightforward C FFI.  But I fear the amount of work I'd have
to do to implement that (quite possibly beyond my skills), and also that the
changes wouldn't ever make it into the official OCaml.

> - I'm still trying to understand what can be done in SML (or with any
> functional programming language) that I couldn't do with an OOP
> language that has introspection capabilities. Although I read a lot
> of documents, I didn't find any feature in SML that has no equivalent
> in the OOP world.

My problem is actually the other way around.  I want to understand how to do
FP, dispensing with anything I thought I needed OOP for.

> Greetings from Paris.
> PS: I have spent a week in Seattle 2 months ago. Nice city.

Yes, especially right now in the summer!  I did a 14 week stretch in Paris
one summer, great city.

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

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

0
6/20/2004 11:57:09 AM
"Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com> writes:

> SML/NJ's archive is puny.
> https://sourceforge.net/mailarchive/forum.php?forum_id=10073

That's because we are not using it.  We have a separate development
mailing list.  It's address is posted on www.smlnj.org.

Matthias
0
find19 (1244)
6/20/2004 3:04:29 PM
Patrick Philippot <patrick.philippot@mainsoft.xx> wrote:

> - SML is *extremely* difficult to debug and retro-document. Even though
> SML .Net is better than the standard tools because Visual Studio .Net
> provides some support for debugging, it's almost impossible to
> understand and analyze existing code by stepping through it. The
> recursive nature of SML makes this very difficult.

Like everything, it's a matter of getting used to a certain style.
An advantage of functional programs is that they don't have side
effects; so you can test each of the old functions in isolation.
Also, just looking at the type some the function often gives a lot
of information about what it is supposed to to.

> - I tried to find some support on Usenet. I found 2 newsgroups:
> comp.lang.functional and comp.lang.ml. The level of activity in these
> groups makes me wonder how much developers are using the language. 

Try asking here or in clm, and see if the answers help you. There are
also mailing lists (not sure about SML, but certainly for the other FP
languages).

> - I'm still trying to understand what can be done in SML (or with any
> functional programming language) that I couldn't do with an OOP language
> that has introspection capabilities. 

All languages are Turing complete, so every language can do everything
else another language can. But some things work better in FP than in
OO, and lots of programs are a lot shorter in FP.

> For these reasons, an although I'm trying hard to analyze this SML code,
> I'm considering switching to an OOP language and rewriting the code from
> the specs using C#.

As with everything, there is a learning curve, for OOP and for FP.
Somebody who hasn't been trained in OOP will have as much trouble
with your code as you have with the FP code.

Still, a rewrite might be the better alternative, if you are having
a hard time switching to FP thinking, and if it's a one-time job.

But if you do have the specs, the SML code shouldn't be so hard to figure
out...

- Dirk
0
dthierbach (210)
6/20/2004 3:05:44 PM
Joachim Durchholz wrote:
> Patrick Philippot wrote:

[...]

>> - I'm still trying to understand what can be done in SML (or with any
>>  functional programming language) that I couldn't do with an OOP 
>> language that has introspection capabilities. Although I read a lot of 
>> documents, I didn't find any feature in SML that has no equivalent
>>  in the OOP world.
> 
> 
> Closures. [...]

When I was learning Scheme, the first thing I did was build two or three 
object systems to prove to myself I could live with the language. I 
eventually came to realize that the tools I used to build these object 
systems (higher-order functions by way of closures) were by far the more 
powerful concept.

Also, I will add that what SML gives me that neither Scheme nor C++ has 
given me is a type system so well-designed that if a program compiles, 
it very likely just works. This may be contradicted by the experiences 
of Patrick Philippot, but the whole concept of SML .net hurts my brain.

-thant

0
thant (332)
6/20/2004 7:41:14 PM
Matthias Blume wrote:
> "Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com>
> writes:
>
>> SML/NJ's archive is puny.
>> https://sourceforge.net/mailarchive/forum.php?forum_id=10073
>
> That's because we are not using it.  We have a separate development
> mailing list.  It's address is posted on www.smlnj.org.

Ok, here's the problem.  Your web page says you have a new mailing list
hosted by SourceForge.  Those of us experienced with SourceForge, assumes
that means the mailing list is accessible and archived from its SourceForge
project page.  2 mailing lists are given: smlnj-commits and smlnj-list.  I
would point out that the list given by scanned image on the website is not
listed on the SourceForge page, and that I didn't notice this in the course
of events.  Maybe that's by deliberate design to defeat spammers, but you've
also created obscurity for people trying to determine the viability of
SML/NJ.  It's not like the homepage is extensive or looks like a big user
community, so maybe X% of people stop looking when they 'accidentally'
peruse a (seemingly empty) mailing list archive.

I think if you boldly highlighted all relevant info about hunting and
pecking the mailing list, in its own clearly defined header section rather
than a line interspersed in a list of other stuff, it would alleviate the
problem.

You might also put something about how to find the 'secret' mailing list on
the SourceForge project page.

Also, do you archive the 'secret' mailing list?  Not being able to
immediately view an archive reduces the radar profile of a shopped-for
language.  I can't, for instance, quickly determine the health of the SML/NJ
community.  Maybe you will have obscure mailserv commands I can use, if I
have knowledge of such arcane technologies and am willing to futz with them
(i.e. more barriers).  Maybe you won't.

At least you are here though, so that's a partial antidote.

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

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



0
6/20/2004 8:03:27 PM
Brandon J. Van Every wrote:
>
> I think if you boldly highlighted all relevant info about hunting and
> pecking the mailing list, in its own clearly defined header section
> rather than a line interspersed in a list of other stuff, it would
> alleviate the problem.

Incidentally, you also have no instructions about how to subscribe to the
list.  Those of us who know about these technologies will try things like
"subscribe" in the header and the body of the message, seeing as how you
could be using either schema.  I just sent one of those, but I have not
gotten any kind of an immediate reply message.  This could mean either your
mail server is slow, you hand moderate all replies, your mail server is
broken, or there's some double secret SourceForge subscribing mechanism I
wouldn't initially think about.  It seems I won't know until 'later',
whenever that turns out to be.  More futz factors to keep people, not just
spammers, away from SML/NJ.

It is also not a good sign that apparently these problems have been allowed
to persist for some time.  I don't know how much time, whether you moved
over to a new mailing list a week ago or a year ago.  www.smlnj.org shows
Copyright 2003 on its various webpages, right by where it says the 'secret'
mailing list address.  Maybe you in fact just changed over last week, but in
a higher volume community, I believe these problems would have been noticed
and addressed right away.

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

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

0
6/20/2004 8:18:29 PM
Joachim Durchholz wrote:

>> - I'm still trying to understand what can be done in SML (or with any
>>  functional programming language) that I couldn't do with an OOP 
>> language that has introspection capabilities. Although I read a lot of 
>> documents, I didn't find any feature in SML that has no equivalent
>>  in the OOP world.
> 
> 
> Closures.

While I am sympathetic for Phillipe's problems (SML or Ocaml are simply 
not up to widespread industrial usage - the few exceptions are in fact 
companies founded by former language designers and researchers), I have 
to reject what Joachim is saying. Closures are readily available in 
Smalltalk under the name of blocks and behave virtually identical. They 
are in no way unique to FP and are not contradictory to OO, so arguably 
this is not a feature that augments SML.

What is really different between OO and FP is that the formers focuses 
on an extensible datatype model, whereas the latter focuses on 
side-effect free expressions. That is no "theoretical" notion, but has 
tremendous practical consequences in program development and debugging 
(for good and for bad if you throw in lazyness). Now, mind you, to date, 
this has not been quantified properly and the statement is based on 
personal experiences in the two paradigms. Also, in a purely functional 
style, having first-class functions (aka closures) is pretty much a 
must-have!

What is likely the more distinguishing feature of Standard ML is its 
functors. There is no OO-language to date that has a similar powerful 
module concept, except for mixin-based languages. They are, however, 
even rarer than SML.

As for a practical point of view, I would not even think of starting a 
real-world project ("real world" simply means 1) hard deadlines and 2) 
real money down the line) in SML or Ocaml unless I can do it in 
isolation (just me and maybe a few other FP-savy programmers), do not 
have to rely on the product a few years down the line (you never know if 
your compiler will still be around, and less so, if there are 
programmers who can follow-up what you did), and do not require too much 
interdependencies with other software written in other environments and 
languages (interoperability is often restricted, unreliable, or 
experimental). Of course, it is hard to imagine a real-world project 
that satifies these constraints.

> Java's inner classes can be used to mimick closures, though in an
> extremely cumbersome way. (Closures were proposed as an alternative, and
> were rejected on the basis that inner classes are "more OO".
> Technically, they were right, but closures would still have been far,
> far easier to use for event handlers and such.)

While I agree, you have to be careful. The ability to override methods 
in inner-classes extends their ability in comparison with a normal 
closure and this idiom is very common in Java. I am not sure if I 
actually like it because it makes the spagethi even worse...

> Of course, you can also construct a closure using a class. You "just"
> need to write about 50 lines to handle class syntax, constructor, and an
> "execute" function that houses the expression proper. Oh, and find a
> good name for the class, write the JavaDoc stuff, make a unit test -
> what's a single line of code not even worthy a second thought in a
> functional language takes two full days in an OO language.
> 
> 
> There's a more indirect advantage.
> The more restricted a piece of code is, the easier it is to read - you
> have less assumptions to check when it comes to understand why it does
> what it does.
> FPLs don't overwrite data (usually), so if you're chasing a bug, you
> don't have to check your assumptions whether some data stays the same,
> sparing you a lot of thought and and code-sifting effort.

That is of course the other side of the coin. The single-most 
problematic thing I am currently experiencing while writing OO is that I 
  never know what has been overridden where and I am almost permanently 
lost in bizarrly interacting class-hierarchies. This may well be my lack 
of experience but I seriously doubt that this increases error-shy 
programming. In fact, I darely need an IDE like Eclipse to help me find 
my way in just about any OO program. With good old SML, (X)emacs will do 
the job.

	Regards,

	Simon
0
Simon
6/21/2004 4:18:54 PM
Simon Helsen wrote:
> 
>> Java's inner classes can be used to mimick closures, though in an
>> extremely cumbersome way. (Closures were proposed as an alternative, and
>> were rejected on the basis that inner classes are "more OO".
>> Technically, they were right, but closures would still have been far,
>> far easier to use for event handlers and such.)
> 
> While I agree, you have to be careful. The ability to override methods 
> in inner-classes extends their ability in comparison with a normal 
> closure and this idiom is very common in Java. I am not sure if I 
> actually like it because it makes the spagethi even worse...

On the other hand, Java's inner classes are not closures. They cannot 
capture variables from surrounding scope. That makes them almost useless.

Last time I looked something along these lines was proposed for C#, but 
required pretty ad-hoc rules for variable life-time, because variables 
are not first-class as they are in ML or other impure FPLs.

	- Andreas

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

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

0
rossberg (600)
6/21/2004 4:31:13 PM
Simon Helsen wrote:
>
> As for a practical point of view, I would not even think of starting a
> real-world project ("real world" simply means 1) hard deadlines and 2)
> real money down the line) in SML or Ocaml unless I can do it in
> isolation (just me and maybe a few other FP-savy programmers), do not
> have to rely on the product a few years down the line (you never know
> if your compiler will still be around, and less so, if there are
> programmers who can follow-up what you did), and do not require too
> much interdependencies with other software written in other
> environments and languages (interoperability is often restricted,
> unreliable, or experimental). Of course, it is hard to imagine a
> real-world project that satifies these constraints.

An indie game project with a small, sharp team fits the bill.  :-)

> That is of course the other side of the coin. The single-most
> problematic thing I am currently experiencing while writing OO is
>   that I never know what has been overridden where and I am almost
> permanently lost in bizarrly interacting class-hierarchies. This may
> well be my lack of experience but I seriously doubt that this
> increases error-shy programming. In fact, I darely need an IDE like
> Eclipse to help me find my way in just about any OO program. With
> good old SML, (X)emacs will do the job.

In my own designs, which were for rendering planetary geometry, I found
myself spending too much time creating OO abstractions at too fine a grain.
I was thinking in terms of all my objects being reusable components, so that
I could build up more complicated geometric operations.  But, ultimately
this severe degree of 'bottom up' coding was not justifiable.  It would tend
to be confusing and somewhat error prone to spread functionality across a 3-
or 4-deep object hierarchy.  It would usually not be quite the right design.
Relationships of ownership and invocation were often problematic, i.e. ISA
vs. USES.  I conclude, oddly enough, that inheritance at too fine a grain
actually violates encapsulation.  I would have been better off making my
objects much more coarse, not trying to reuse them, and simply rewriting
them wholesale when/if they proved to be inadequate in their design.

Because of my negative practical experiences with OO, I'm more open to other
paradigms, such as FP.  I really don't believe all the FPers bullshit about
how great it's supposed to make life, however.  It's all theoretical
handwaving, I see no evidence of proven utility.  FP's failure to capture
industry mindshare is clear enough.  Rather, I take a modest view that FP is
probably useful for something, and probably not any more harmful than OO.
In particular, FP may be a better fit to some of my 3D graphics and AI
problems, if not all of them.

-- 
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
6/21/2004 5:55:19 PM
Andreas Rossberg wrote:
> Simon Helsen wrote:
> 
>>
>>> Java's inner classes can be used to mimick closures, though in an
>>> extremely cumbersome way. (Closures were proposed as an alternative, and
>>> were rejected on the basis that inner classes are "more OO".
>>> Technically, they were right, but closures would still have been far,
>>> far easier to use for event handlers and such.)
>>
>>
>> While I agree, you have to be careful. The ability to override methods 
>> in inner-classes extends their ability in comparison with a normal 
>> closure and this idiom is very common in Java. I am not sure if I 
>> actually like it because it makes the spagethi even worse...
> 
> 
> On the other hand, Java's inner classes are not closures. They cannot 
> capture variables from surrounding scope. That makes them almost useless.

I think you have relativate this a little-bit.

1) There is entirely normal lexical scoping for "fields" of 
encapsulating classes for both inner and local classes.

2) For local variables (and parameters, etc), yes, they have to be final 
(i.e. normal bindings) for them to be available in the inner class. This 
is because javac makes a copy of the used local variable. A trick to get 
around that is to create an array with the rhs as its element and of 
course, each reference to it in the local block has to access the local 
variable via the array element. While ackward, it behaves like a 
closure. In fact, this is not so different from what happens in SML. 
Only in Java, there is no such thing as a ref constructor, so you have 
to use an array for that instead.

I do not see what you mean by "that makes them useless".
If you would try (bad idea) to program entirely functional in Java, you 
do not want destructive updates, so you just as well may define your 
local bindings as final. If you want to be imperative in SML you have to 
use ref, so use array in Java (with bloated syntax, I agree). Finally, 
if you program in an OO fashion in Java (quite likely!) you do not face 
these problems in the first place. Local variable updates in the local 
class are not likely and enclosing field updates, being most common, are 
allowed.

> because variables are not first-class as they are in ML or other impure FPLs.


What do you mean by variables are (or are not) first-class? Could you 
explain exactly what the difference is here? The only difference I see 
is that SML (like all impure FPLs) makes a distinction between bindings 
(by default) and assignments (requiring extra syntax). In Java, that 
happens "the other way around" by having assignments by default and 
bindings by annotation.

	Simon
0
Simon
6/21/2004 6:12:51 PM
Brandon J. Van Every wrote:
>
> Incidentally, you also have no instructions about how to subscribe to
> the list.

After 48 hours of receiving no reply, I correctly guessed that a *-request
suffix was needed to get anything to happen.  My 1st post is going to be
about how invisible the list is to people.

-- 
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
6/21/2004 6:29:11 PM
Simon Helsen wrote:

[...]

> What is likely the more distinguishing feature of Standard ML is its 
> functors. There is no OO-language to date that has a similar powerful 
> module concept, except for mixin-based languages. They are, however, 
> even rarer than SML.

There is much in this post I disagree with, but the only claim I want to 
respond to is this one. I've become convinced that there is a similarity 
between SML's functors and C++'s templates that is not captured by a 
traditional taxonomy of programming language features. In fact, I think 
C++'s templates are superior to SML's functors (not counting syntax). I 
still think SML is by far the superior language on the whole, and 
functors are one of the reasons why. But they're not *the* reason why.


-thant

0
thant (332)
6/21/2004 7:01:39 PM
"Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com> writes:

> Brandon J. Van Every wrote:
> >
> > Incidentally, you also have no instructions about how to subscribe to
> > the list.
> 
> After 48 hours of receiving no reply, I correctly guessed that a *-request
> suffix was needed to get anything to happen.  My 1st post is going to be
> about how invisible the list is to people.

The list is not supposed to be public.  It is for developers, and if
you want to become one, you could have asked to be put on the list
nicely (if you can't figure out how to do it yourself).

So don't bother telling us about it.  It is going to be a waste of
everybody's time.

(In case you didn't notice: Yes, I am a bit ticked off right now at
the tone of your previous 3 or 4 articles regarding the SML/NJ
development process.)

Matthias
0
find19 (1244)
6/21/2004 7:47:08 PM
Thant Tessman wrote:

> There is much in this post I disagree with, but the only claim I want to 
> respond to is this one. I've become convinced that there is a similarity 
> between SML's functors and C++'s templates that is not captured by a 
> traditional taxonomy of programming language features. In fact, I think 
> C++'s templates are superior to SML's functors (not counting syntax). I 
> still think SML is by far the superior language on the whole, and 
> functors are one of the reasons why. But they're not *the* reason why.

I agree that there are some similarities between SML functors and C++ 
templates. In fact, indirectly, these have been documented (there are 
papers describing dependently typed problems with functors and many use 
templates for meta-programming. Needless to say, dependent type systems 
and meta-programming are very akin).

If you disagree so much, could you please qualify yourself? Also, SML 
may well be superior as a programming language (in fact, I am strongly 
on your side there), it is simply not practical enough for the reasons 
mentioned in my earlier post (And there are others -> someone already 
referred to Phil Wadler's column).

	Simon
0
Simon
6/21/2004 7:48:27 PM
Brandon J. Van Every wrote:
> It's all theoretical
> handwaving, I see no evidence of proven utility.  FP's failure to capture
> industry mindshare is clear enough.  

I guess this is where we wave the Erlang flag again? 
(http://www.erlang.org). I'd say there's quite some evidence of proven 
utility there. Within Ericsson alone we have two *major* products both 
very successfull in their fields (market leaders). And those aren't the 
only ones.

While we also like to think that this is because of how nice and 
competent people we are :-) We also like to plug Erlang itself as a 
contributory factor.

Stefan,
-- 
Stefan Axelsson  (email at http://www.cs.chalmers.se/~sax)
0
crap1234 (43)
6/21/2004 8:59:59 PM
Brandon J. Van Every wrote:
> 
> In my own designs, [...] I found myself spending too much time
> creating OO abstractions at too fine a grain. I was thinking in terms
> of all my objects being reusable components, so that I could build up
> more complicated geometric operations.  But, ultimately this severe
> degree of 'bottom up' coding was not justifiable.  It would tend to
> be confusing and somewhat error prone to spread functionality across
> a 3- or 4-deep object hierarchy.  It would usually not be quite the
> right design. Relationships of ownership and invocation were often
> problematic, i.e. ISA vs. USES.

This is the standard staple of design problems in OO.
Welcome to the club ;-)

> I conclude, oddly enough, that inheritance at too fine a grain 
> actually violates encapsulation.

Actually inheritance violates encapsulation regardless of how you use
it: after all, the inheriting class has access to all the internal
machinery of all of its ancestors. (Unless that machinery is
"protected", but that comes with its own set of problems and limitations.)

> I would have been better off making my objects much more coarse, not
> trying to reuse them, and simply rewriting them wholesale when/if
> they proved to be inadequate in their design.

Reusable code requires throwing away at least two perfectly working (but
not-so-reusable) designs. I think that's one of the promises that OO
failed to deliver on.

> Because of my negative practical experiences with OO, I'm more open
> to other paradigms, such as FP.  I really don't believe all the FPers
> bullshit about how great it's supposed to make life, however.  It's
> all theoretical handwaving, I see no evidence of proven utility.

Hey, try it or leave it. Ranting is going to neither improve the
state of affairs, nor make anybody more willing to help you out.
You're in a very real danger of building a self-fulfilling prophecy here.
Not that I don't share your opinion that most FPLs still lack the 
support you can get for other languages. It's just that academia gets 
funding for researching new stuff, not for grunt work - and providing 
all that support is indeed grunt work with little place left for research.
If you think that programming languages should be advanced into a state 
of usability, write to your parliamentary representative and propose 
funding for that...

Regards,
Jo
0
jo427 (1164)
6/22/2004 2:28:50 AM
Stefan Axelsson wrote:

> Brandon J. Van Every wrote:
> 
>> It's all theoretical handwaving, I see no evidence of proven
>> utility.  FP's failure to capture industry mindshare is clear
>> enough.
> 
> I guess this is where we wave the Erlang flag again? 
> (http://www.erlang.org). I'd say there's quite some evidence of
> proven utility there. Within Ericsson alone we have two *major*
> products both very successfull in their fields (market leaders). And
> those aren't the only ones.
> 
> While we also like to think that this is because of how nice and 
> competent people we are :-) We also like to plug Erlang itself as a 
> contributory factor.

I have to put an ounce of salt into that.

While Erlang is all nice and dandy for the kind of environments it was
written for, it doesn't work very well if some of the basic assumptions
are wrong.
For example, my idea was to use it in a client-server setting. In that
setting, the special advantages of Erlang (network-transparent message
passing between Erlang processes) vanished: there was no way to identify
and authenticate Erlang processes, functions in a closure sent as a
message are identified by name (creating all sorts of havoc if versions
come into play), and (the final straw) there's an easy way to overflow
an internal table of the server with a DoS attack.

For the record: I like Erlang quite a bit. There's a lot of good support
available for it. It should work very well in any environment where a
known set of CPUs must interoperate for a relatively well-defined
overall task.

Regards,
Jo
0
jo427 (1164)
6/22/2004 2:39:21 AM
"Patrick Philippot" <patrick.philippot@mainsoft.xx> writes:

[...]
> I found only one book : ML for the working programmer, Paulson,
  ^^^^^^^^^^^^^^^^^^^^^
[...]
> http://www.smlnj.org//index.html
         ^^^^^^^^^^^^^^^^^^^^^^^^^
[...]
> But this didn't solve my problems either.

You didn't read past the front page of these web site(s), did you?

On the SML/NJ front page you find a section on "Documentation and
Literature".  The links lead to information on no less than 9
tutorials and 19 books.  Admittedly, quite a few of them aren't what
you are currently looking for, but to say that you weren't able to
locate more than one book is a joke.

> I'd like to add the following comments too:
> 
> - SML is *extremely* difficult to debug and retro-document.

How much experience do you have with the language?  If you are still
hunting for books that explain it to you, I guess not that much.  If
that is indeed so, and given that programming in SML feels quite
different than programming in any of the languages that you do know
(meaning that you can't just guess your way through), I am not
surprised at all that you find it difficult to debug and document SML
code written by others.  But that has nothing to do with the language
itself.

> Even though SML .Net is better than the standard tools because
> Visual Studio .Net provides some support for debugging, it's almost
> impossible to understand and analyze existing code by stepping
> through it. The recursive nature of SML makes this very difficult.

I find the idea of trying to understand a program by "stepping through
it" mind-bogglingly ill-conceived (in *any* language).

> - I tried to find some support on Usenet. I found 2 newsgroups:
> comp.lang.functional and comp.lang.ml. The level of activity in these
> groups makes me wonder how much developers are using the language. You
> can't produce without support and obviously, support for SML is scarce.

Instead of ranting here about the lack of support, why did you not try
asking a specific question?  Some people here do try to answer such
questions!  Pissing them off right from the start doesn't sound like a
great strategy.  (Not to mention the fact that a low level of quality
traffic is much preferable to the kind of thing that goes on in some
of those "more active" groups...)

> - I'm still trying to understand what can be done in SML (or with any
> functional programming language) that I couldn't do with an OOP language
> that has introspection capabilities. Although I read a lot of documents,
> I didn't find any feature in SML that has no equivalent in the OOP
> world.

Of course, that is not the point.  As others have pointed out,
programming languages tend to be equally expressive if you gloss over
the amount of work that is required to emulate one style of
programming with another.  There is (much) more to good language
design than just a pile of features.  The question should not be
whether one *can* do it, but rather how easy it is, how natural it is,
how scalable the approach is, how maintainable the results are, etc.
Unfortunately, even reading one or two books won't help you.  In the
end it takes considerable practical experience to appreciate the
benefits (if there are any) of "switching" from one language to
another.

(In language design, less is often more. The fact that you mention
"introspection facilities" when comparing FP to OO speaks volumes.)

> - About 20 years ago, when I was still working at IBM, I had to write
> code using the APL language. A very powerful language with a big
> drawback: when you go back to your code 10 days after you've written it,
> you have difficulties understanding what you wanted to do at that time.
> I have the exact same feeling with SML. So imagine when you've *not*
> written the code yourself.

I don't have this feeling about SML code at all.  (You may have
guessed that already. :-) I have written several tens of thousands of
lines of SML code which I can still maintain (after years of not
looking at certain portions). I have also worked on code several
magnitudes larger -- and written by others.  The community of people
who wrote this code was and is fairly loosely knit, so it is not
nearly as well organized as you might expect from a successful program
of that size.  I give huge credit to the language for the (amazing)
fact that one can succesfully work on such code at all.

> - Someone told me that the OCaml language was better supported (OCaml is
> the OO version of Caml). This is not my feeling (not much books, only
> one newsgroup).

Support is not the same as books and newsgroups.

> For these reasons, an although I'm trying hard to analyze this SML code,
> I'm considering switching to an OOP language and rewriting the code from
> the specs using C#.

Good luck!  (My suggestion -- and I am not kidding -- would be to
consider rewriting the code from the spec using _SML_.  This way you
get a chance to learn more of the language, you can concertrate on the
problem and don't have to learn both a language and someone else's
solution to a problem at the same time. And when you get stuck, you
even have a piece of "reference" code, the value of which -- over time
-- you will perhaps begin to appreciate as well.)

Matthias
0
find19 (1244)
6/22/2004 3:57:57 AM
"Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com> writes:

> Your web page says you have a new mailing list
> hosted by SourceForge.  Those of us experienced with SourceForge, assumes
> that means the mailing list is accessible and archived from its SourceForge
> project page.

I don't understand how you come to such an assumption.  (Granted, our
SourceForge presence -- if we decide to stick with it -- could use
some work.  But SML/NJ is much older than SF, and we use SF mainly to
host the CVS repository now.)

>  2 mailing lists are given: smlnj-commits and smlnj-list.  I
> would point out that the list given by scanned image on the website is not
> listed on the SourceForge page, and that I didn't notice this in the course
> of events.  Maybe that's by deliberate design to defeat spammers,

No "maybe".  Our web page says so quite clearly.

> but you've also created obscurity for people trying to determine the
> viability of SML/NJ.

No, we have not "created" obscurity.  Our main presence on the web is
not the SF page.  Just because we did not post the list name there
does not mean we are more "obscure" than before.  (Plus, our home page
-- including the address in question -- is only one click away from
the SF project page.)

Matthias
0
find19 (1244)
6/22/2004 4:16:34 AM
Simon Helsen <where-X=@-in-shelsenXcomputer.org> writes:

> As for a practical point of view, I would not even think of starting a
> real-world project ("real world" simply means 1) hard deadlines 

I agree, but only for the reason of being able to say 'look at all
these other projects using <imperative langauge>, they are late too'
instead of taking the blame for using weird tools.  I don't think
there's any evidence of FP programs being delivered in a less timely
fashion, and I'd expect the opposite.

> Of course, it is hard to imagine a real-world project that satifies
> these constraints. 

I probably don't live in what you consider the real world anyway.

> That is of course the other side of the coin. The single-most
> problematic thing I am currently experiencing while writing OO is that
> I never know what has been overridden where and I am almost
> permanently lost in bizarrly interacting class-hierarchies. This may
> well be my lack of experience 

The it's my lack of experience also - you accurately describe my main
gripe against OO.  It's not so hard to see why; FP is just a more
elegant form of structured programming, it focuses on the breakdown of
programs by control flow.  OO focuses on breakdown by data structure,
and consequently, control flow becomes more difficult to track.

OO was invented to solve problems that were control flow breakdown was
difficult to do (simulation), but it has gone from there to domination
in all areas, also where the fit is less good.

IMHO.

-kzm
-- 
If I haven't seen further, it is by standing in the footprints of giants
0
ketil (99)
6/22/2004 6:43:07 AM
Joachim Durchholz wrote:

> I have to put an ounce of salt into that.

As always YMMV.

> For example, my idea was to use it in a client-server setting. In that
> setting, the special advantages of Erlang (network-transparent message
> passing between Erlang processes) vanished: there was no way to identify
> and authenticate Erlang processes, functions in a closure sent as a
> message are identified by name (creating all sorts of havoc if versions
> come into play), and (the final straw) there's an easy way to overflow
> an internal table of the server with a DoS attack.

Yes as my area of research is computer security you don't have to tell 
me. However, as you say it's really outside the design parameters. 
Erlang IMHO would still make a useful tool for that setting when one 
recognises that it's really designed to build tightly (well on the lose 
end but still) systems. If you used Erlang for the server using the 
intrinsic network transparency to implement redundancy etc. and used or 
implemented standard protocols for authentication etc it would still be 
a win. (And IMHO this is where one wants to follow someone else. It's 
all too easy to get a security protocol wrong.)

Within Ericsson itself we don't (typically) use Erlang over the wire as 
the protocols over which we need to communicate are standardised, and 
there are a lot of them to boot. As a result of being developed for that 
environment I'd still say that Erlang is (perhaps) more useful than most 
other languages as it's easy to implement a protocol stack for almost 
any protocol in Erlang given the library support etc. As a for instance: 
the SNMP bug that bit almost all of our competitors (really the rest of 
the world) a few years back didn't have any effect on us. The reason was 
that the rest of the world had just incorporated the Berkley SNMP 
parsing code into their products (one would assume since 
reimplementation was considered prohibitive). Not so with the Erlang 
stack, which contains its own very much short and sweet SNMP stack. 
Being implemented in Erlang it didn't suffer from the typical buffer 
overruns that plagued the other implementations (implementation?).

So I'd say that Erlang is well suited to the client server application, 
but not applied in the naive (perhaps: straightforward?) fashion.

> For the record: I like Erlang quite a bit. There's a lot of good support
> available for it. It should work very well in any environment where a
> known set of CPUs must interoperate for a relatively well-defined
> overall task.

Incidentally. I'm in the static typing camp myself, so I'm a bit guarded 
in my praise. Still it's better than the alternatives. :-)

Stefan,
-- 
Stefan Axelsson  (email at http://www.cs.chalmers.se/~sax)
0
crap1234 (43)
6/22/2004 8:09:05 AM
Ok let's play this out.  Maybe your webpages will improve at some point
because of it.

Matthias Blume wrote:
> (In case you didn't notice: Yes, I am a bit ticked off right now at
> the tone of your previous 3 or 4 articles regarding the SML/NJ
> development process.)

I know nothing about your SML/NJ development process.  Could be the best in
the world, but frankly, how would I know?  My comments are about your
mailing list interface and your lack of a Googleable public archive.  I
definitely infer some things about the size of the SML/NJ community from
that though.

Matthias Blume wrote:
> "Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com>
> writes:
>
>> Your web page says you have a new mailing list
>> hosted by SourceForge.  Those of us experienced with SourceForge,
>> assumes that means the mailing list is accessible and archived from
>> its SourceForge project page.
>
> I don't understand how you come to such an assumption.

"We have switched over to a new mailing list hosted by SourceForge. The name
of the new list is [image of -dev- mailing list name]."

Why do you bother to advertize your 'new' mailing list as "hosted by
SourceForge" if you do not expect people to access it by standard
SourceForge interfaces?  In the quote above, you don't even link to your
specific SourceForge project.  You link to SourceForge in general.  People
may very well infer that they can get to the SML/NJ mailing list from the
SourceForge top level.  They would be wrong.  They might not notice the
error at all, as the contextual transition from SML/NJ homepage to
SourceForge homepage to SML/NJ SourceForge project page is at least 3 steps
if not more.

Meta question: do you understand the open source culture of Source Forge?
All the project activity metrics?  If you have some project with an
apparently dead mailing list, people assume your project doesn't have any
life to it.  In your quest to be rid of spam, you are negatively advertizing
SML/NJ.

How about this redraft:

"Our current mailing list is [image of new sourceforge mailing list].  The
old mailing list, smlnj-list@lists.sourceforge.net, is no longer being used.
Please be advised that to prevent spam, the current mailing list is not
listed on our SourceForge project page.  To subscribe, please send an e-mail
to [image of new sourceforge mailing list *-request address] with the word
"subscribe" in the body of the message."

And a hint on the SourceForge project page, like "Warning!  This is a
spamtrap.  See www.smlnj.org for details."

>> but you've also created obscurity for people trying to determine the
>> viability of SML/NJ.
>
> No, we have not "created" obscurity.  Our main presence on the web is
> not the SF page.  Just because we did not post the list name there
> does not mean we are more "obscure" than before.

Before *what* ?

> (Plus, our home page
> -- including the address in question -- is only one click away from
> the SF project page.)

Bottom line:
- no subscription instructions
- no public archive

You are obscure.  The fixes are trivial.

-- 
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
6/22/2004 9:33:48 AM
"Ketil Malde" <ketil@ii.uib.no> wrote in message
news:egacywqeis.fsf@havengel.ii.uib.no...
> The it's my lack of experience also - you accurately describe my main
> gripe against OO.  It's not so hard to see why; FP is just a more
> elegant form of structured programming, it focuses on the breakdown of
> programs by control flow.  OO focuses on breakdown by data structure,
> and consequently, control flow becomes more difficult to track.
I'm afraid this is a misunderstanding of OO. OO does not break down by data
structure. Whoever taught that was probably from a dataflow or DB
background. True there is a superficial similarity between tables and
classes but the similarity ends there. OO is about *non hierarchical*
breakdown of control. In traditional stepwise refinement you take a problem
to be solved and define a function/procedure for it whichi is is then
refined into subprocedures. In OO you identify classes and allocate
responsibilities for part of the task to each of the classes (Of course the
classes should have meaningful coherent responsibilities - one reason why OO
doesn't make much sense in solving small problems or algorithmic problems).
Then the classes cooperate to get the task done. They might even use
implicit invocation (events) to acheive it.

Of course despite what some people might be saying in this thread, there is
no real reason why functional programming and OO design cannot be used
together to mutual benefit.

cheers
-sri


0
s_nedunuri (52)
6/22/2004 9:40:26 AM
Stefan Axelsson wrote:
> Brandon J. Van Every wrote:
>> It's all theoretical
>> handwaving, I see no evidence of proven utility.  FP's failure to
>> capture industry mindshare is clear enough.
>
> I guess this is where we wave the Erlang flag again?
> (http://www.erlang.org).

L'excepcion qui preuve la regle!

I'd be interested in Erlang if I was writing a Massively Multiplayer Online
Game (MMOG), but I'm not.  Also I'm not sure if Erlang is proving something
about Functional languages or *Concurrent* languages.

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

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

0
6/22/2004 9:40:59 AM
Joachim Durchholz wrote:
> Brandon J. Van Every wrote:
>>
>> I conclude, oddly enough, that inheritance at too fine a grain
>> actually violates encapsulation.
>
> Actually inheritance violates encapsulation regardless of how you use
> it: after all, the inheriting class has access to all the internal
> machinery of all of its ancestors. (Unless that machinery is
> "protected", but that comes with its own set of problems and
> limitations.)

False.  Try implementing 'Private' machinery.

> Reusable code requires throwing away at least two perfectly working
> (but not-so-reusable) designs. I think that's one of the promises
> that OO failed to deliver on.

Well, I can't get a design right until I've done it 6 times.  It starts
becoming somewhat like it should be after 3 passes, so I suppose our
experiences agree.

>> Because of my negative practical experiences with OO, I'm more open
>> to other paradigms, such as FP.  I really don't believe all the FPers
>> bullshit about how great it's supposed to make life, however.  It's
>> all theoretical handwaving, I see no evidence of proven utility.
>
> Hey, try it or leave it. Ranting is going to neither improve the
> state of affairs, nor make anybody more willing to help you out.

The comments generated from my previous queries, or such a barb, are already
as much 'help' as I need.  I'm not here to please anybody, become someone's
language adherant, or pump sunshine up anyone's skirt about technology.  In
terms of industrial mindshare, FP sucks.  There are probably good tangible
reasons for that somewhere, and it's best that people look at them and
address them.  I've seen too many fora, read too many archives, of too many
FPers going on and on and on about how FP is the promised land.  But I see
no promise to industry in general.  I see people waving hands about how good
things are *supposed to* be.  *If only* everyone used my paradigm of choice,
etc.

And, we've had decades to look at this mote in our eye.

> If you think that programming languages should be advanced
> into a state of usability, write to your parliamentary representative
> and propose funding for that...

What nonsense.  If I cared *that* much, I'd write the language.  As it
stands, I care enough to survey other people's language writing efforts.  I
have no interest in NIH if someone's actually inventing what I want.

-- 
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
6/22/2004 10:01:41 AM
Matthias Blume wrote:
> "Patrick Philippot" <patrick.philippot@mainsoft.xx> writes:
>
> [...]
>> I found only one book : ML for the working programmer, Paulson,
>   ^^^^^^^^^^^^^^^^^^^^^
>
> On the SML/NJ front page you find a section on "Documentation and
> Literature".  The links lead to information on no less than 9
> tutorials and 19 books.  Admittedly, quite a few of them aren't what
> you are currently looking for, but to say that you weren't able to
> locate more than one book is a joke.

His preceding paragraph provided context.  I took his comment to mean, "I
only found one book that was oriented towards the practical matters I was
concerned with."

>> - SML is *extremely* difficult to debug and retro-document.
>
> How much experience do you have with the language?  If you are still
> hunting for books that explain it to you, I guess not that much.  If
> that is indeed so, and given that programming in SML feels quite
> different than programming in any of the languages that you do know
> (meaning that you can't just guess your way through), I am not
> surprised at all that you find it difficult to debug and document SML
> code written by others.

Fair comments.

> But that has nothing to do with the language itself.

Not quite accurate.  Python, for instance, is reputed to be easy for
beginners to learn.  I would never presume to bill C++ as a 'quick study'
for anyone.  So perhaps his learning curve does indeed have something to do
with SML itself.  For any language, it's fair to ask "What payoff justifies
its learning curve?"  Python doesn't have to justify much: its learning
curve is low.  C++, as far as I'm concerned, doesn't have any justification
anymore.  It's an evolutionary dead end.

> I find the idea of trying to understand a program by "stepping through
> it" mind-bogglingly ill-conceived (in *any* language).

Actually, it was the most successful strategy when I was writing 3D device
drivers.  But, that's a cut-and-dried problem domain.  We know how 3D
pipelines work.

I hate debugging and avoid it as much as possible.  I control errors by
micro-incremental development, rigorous testing, and fascist source control.
I also hate understanding industrial APIs, especially Microsoft APIs.  I
hate *ever* trying to understand other people's code.  It is mentally far
less taxing to write my own code.  Unfortunately, I'm not some kind of
prolific coding genius, so writing my own code is somewhat pricey.  I'm
hoping someday I find a langauge and a development environment that works
with my brain instead of against it.  It certainly isn't C++.

Nor is it any of the low performance languages.  I have always been gifted
at ASM, as it is the simplest, most elegant expression of an actual
computer.  Not that all actual computers are elegant!  Alpha was; Intel
wasn't and isn't.  Worse is better.  :-(  Anyways, my ideal language would
scale to any / all levels of abstraction or concreteness I'd choose to work
with.  This is why SML/NJ and NLFFI are of interest to me.  A lot of Higher
Level Language guys aren't interested in low level performance, and that
bugs the crap out of me.

> Instead of ranting here about the lack of support, why did you not try
> asking a specific question?  Some people here do try to answer such
> questions!  Pissing them off right from the start doesn't sound like a
> great strategy.

Do you piss off easily, instead of just taking lumps in stride that might be
partially deserved?

Has your language community evolved to the point where some camp actually
takes marketing and evangelism seriously?

Actually, I am impressed you are here though.  That's unusual for a language
author.  It is good advertizement.

I've been round and round with Guido and the Python Software Foundation on
marketing issues.  They are not worth the time.  They have pissed off a lot
of people who wanted to put proper marketing campaigns behind the language,
to fight Java and C# and so forth.  Serious efforts probably aren't going to
happen again for another 2 years.  By then, hopefully the community and the
mentality will have shifted.  Right now they are run by techies who cannot
market their way out of a paper bag.  Microsoft and Sun will continue to
crush them, using inferior technology.

> The question should not be
> whether one *can* do it, but rather how easy it is, how natural it is,
> how scalable the approach is, how maintainable the results are, etc.
> Unfortunately, even reading one or two books won't help you.  In the
> end it takes considerable practical experience to appreciate the
> benefits (if there are any) of "switching" from one language to
> another.

Grandpa, taught Dad, who taught me, there are 3 kinds of experience:
- primary: I did it
- secondary: you did it?
- tertiary: someone did it...

Not sure if those were Grandpa's terms.  But, he was a newspaperman.

Hearing all the handwaving about FP, and seeing no clear answers from any
corner, I conclude I'll probably have to read every gory detail of some FP
language to understand what it is / isn't worth.  Proving from 1st
principles like back in grade school.  Pretty much what I did with C++ 12
years ago.

-- 
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
6/22/2004 10:44:14 AM
Ketil Malde wrote:
> Simon Helsen <where-X=@-in-shelsenXcomputer.org> writes:
>
>> As for a practical point of view, I would not even think of starting
>> a real-world project ("real world" simply means 1) hard deadlines
>
> I agree, but only for the reason of being able to say 'look at all
> these other projects using <imperative langauge>, they are late too'
> instead of taking the blame for using weird tools.  I don't think
> there's any evidence of FP programs being delivered in a less timely
> fashion, and I'd expect the opposite.

Running a Seattle OCaml SIG the other week, one fellow's opinion is that
it's the people, not the language, that will make or break a project.  It is
possible for talented soloists to write incredible pieces of code.  But, it
doesn't scale up.  Once you get past a small team of very sharp people,
corporate communication and the law of averages start to affect you.

> The it's my lack of experience also - you accurately describe my main
> gripe against OO.  It's not so hard to see why; FP is just a more
> elegant form of structured programming, it focuses on the breakdown of
> programs by control flow.  OO focuses on breakdown by data structure,
> and consequently, control flow becomes more difficult to track.

So to take the inverse, in FP we'd expect the flow of data to become more
difficult to track.  Six of one, half dozen of the other?

-- 
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
6/22/2004 10:49:44 AM
I spy wrote:
>
> Of course despite what some people might be saying in this thread,
> there is no real reason why functional programming and OO design
> cannot be used together to mutual benefit.

Sure they can, as in OCaml.  But my original motivation in asking my
question, is that OCaml has a bad interface to low level code (only 31-bit
ints, no 32-bit floats, funky 2-step C calling conventions) and SML/NJ
doesn't.  The price for what I want is giving up OO.  So, I want to know how
FP languages 'do things' without OO support.

-- 
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
6/22/2004 10:59:59 AM
Stefan Axelsson wrote:
> Joachim Durchholz wrote:
> 
>> I have to put an ounce of salt into that.
> 
> Erlang IMHO would still make a useful tool for that setting when one
> recognises that it's really designed to build tightly [coupled]
> (well on the lose end but still) systems. If you used Erlang for the
> server using the intrinsic network transparency to implement
> redundancy etc. and used or implemented standard protocols for
> authentication etc it would still be a win.

Fully agreed.

On re-reading my last post, I see I omitted an important detail: I
wanted something where clients and server interoperate in a
network-transparent fashion.
It was tantalizing to see that Erlang came so close, but failed on two
relatively minor but essential points: security if you cannot trust all
Erlang processes, and marshalling closures. Both can be worked around,
but unfortunately in both cases the workarounds create impedance mismatches.
Since I have a limited budget, this ruled Erlang out - though I'd
readily subscribe to Erlang being a fine tool overall.

> (And IMHO this is where one wants to follow someone else. It's all
> too easy to get a security protocol wrong.)

Not sure what you meant with that.

> [Erlang SNMP stack] Being implemented in Erlang it didn't suffer from
> the typical buffer overruns that plagued the other implementations
> (implementation?).

Yup, one of the major things that plague the Unix world.
I don't think that Erlang is particularly good with that though - any
language with a garbage-collected heap would avoid this kind of problem,
even Basic ;-)
Erlang's specific strengths lie elsewhere, and the main highlight is its
commercial-use, commercial-mind support. Ericsson isn't going to simply
leave things unhandled if the Erlang project started to fall apart,
that's a quite strong promise about Erlang's future and quality.

> So I'd say that Erlang is well suited to the client server
> application, but not applied in the naive (perhaps: straightforward?)
> fashion.

Agreed :-)

>> For the record: I like Erlang quite a bit. There's a lot of good
>> support available for it. It should work very well in any
>> environment where a known set of CPUs must interoperate for a
>> relatively well-defined overall task.
> 
> Incidentally. I'm in the static typing camp myself, so I'm a bit
> guarded in my praise. Still it's better than the alternatives. :-)

Ditto :-)

Regards,
Jo
0
jo427 (1164)
6/22/2004 11:12:16 AM
"Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com> writes:

> > But that has nothing to do with the language itself.
> 
> Not quite accurate.  Python, for instance, is reputed to be easy for
> beginners to learn.  I would never presume to bill C++ as a 'quick study'
> for anyone.  So perhaps his learning curve does indeed have something to do
> with SML itself.

Certainly, the slope of the curve is a function of the language (and,
to some degree, the background of the learner).  But with a shallow
curve, you never get to any significant elevation either (unless you
spend a lot of time on that curve). :-)

> C++, as far as I'm concerned, doesn't have any justification
> anymore.  It's an evolutionary dead end.

One thing we 100% agree on.

> > I find the idea of trying to understand a program by "stepping through
> > it" mind-bogglingly ill-conceived (in *any* language).
> 
> Actually, it was the most successful strategy when I was writing 3D device
> drivers.  But, that's a cut-and-dried problem domain.  We know how 3D
> pipelines work.

Yes, I should have qualified this statement a bit.  For limited
domains (and code that is not too big) this might work.  In the
general case, though, it is a fairly bad idea.

> I hate debugging and avoid it as much as possible.  I control errors by
> micro-incremental development, rigorous testing, and fascist source control.
> I also hate understanding industrial APIs, especially Microsoft APIs.  I
> hate *ever* trying to understand other people's code.  It is mentally far
> less taxing to write my own code.  Unfortunately, I'm not some kind of
> prolific coding genius, so writing my own code is somewhat pricey.  I'm
> hoping someday I find a langauge and a development environment that works
> with my brain instead of against it.  It certainly isn't C++.

Wow.  A whole paragraph we nearly 100% agree on.  Maybe SML is for you
after all...

> > Instead of ranting here about the lack of support, why did you not try
> > asking a specific question?  Some people here do try to answer such
> > questions!  Pissing them off right from the start doesn't sound like a
> > great strategy.
> 
> Do you piss off easily, instead of just taking lumps in stride that
> might be partially deserved?

Not that easily.  Otherwise I wouldn't be answering at all.

> I've been round and round with Guido and the Python Software Foundation on
> marketing issues.  They are not worth the time.  They have pissed off a lot
> of people who wanted to put proper marketing campaigns behind the language,
> to fight Java and C# and so forth.  Serious efforts probably aren't going to
> happen again for another 2 years.  By then, hopefully the community and the
> mentality will have shifted.  Right now they are run by techies who cannot
> market their way out of a paper bag.  Microsoft and Sun will continue to
> crush them, using inferior technology.

One thing is: In the end we are academics.  We are not judged by our
peers based on whether our language has become successful (although
this might be a tie-breaker in some cases), but rather on the number
and quality of publications in reputable conferences an journals.
When you want to publish, it helps somewhat to write about a
successful product, but in the end it is the ideas that count, not the
performance in the popularity contest.  (After all, as you noted,
popularity and inherent value are often uncorrelated at best and
sometimes even seem inversely proportional.)

So it comes down to a question of time and effort.  We try to do some
of the necessary marketing, but it can only be done in our spare time.

> Grandpa, taught Dad, who taught me, there are 3 kinds of experience:
> - primary: I did it
> - secondary: you did it?
> - tertiary: someone did it...
> 
> Not sure if those were Grandpa's terms.  But, he was a newspaperman.

Personally, I'm definitely a "primary" kind of guy when it comes to
PL.  Before I have written a substantial piece of code in a language,
I can't claim to know/understand/appreciate it.

Matthias
0
find19 (1244)
6/22/2004 11:22:07 AM
Brandon J. Van Every wrote:

> Also I'm not sure if Erlang is proving something about Functional
> languages or *Concurrent* languages.

Both.
Erlang is functional when programming-in-the-small and concurrent when
programming-in-the-large.

One interesting information that's been repeated several times is that
some internal Ericsson statistics said that a line of Erlang is roughly
equivalent to five lines of C. (Try googling for "productivity
site:erlang.org" (without the quotes).)
There's also a quote about the software in the Ericsson AXP line of
telephony switches. I may have gotten the numbers mixed up so please
check before you quote me, but it was something around the lines of
"100,000 lines of Erlang, 100,000 lines of C, 80% of the functionality
is done in the Erlang parts".

Of course, all of these numbers have a fat "YMMV" tag on them, but even
then the numbers are impressive. Even sub-average programmers seem to
multiply their productivity when they switch to Erlang (at least that's
what I read between the lines).

Personally, I think a large part of these effects is due to Erlang's 
support for automatic garbage collection, together with a system that 
"just works out of the box".

The functional stuff is still great for factoring out commonalities - 
far less syntactic excess than with OO methodology in fact. I attribute 
that to the fact that you need tons of syntax to factor out a single 
line of code into a superclass, while a single-line function declaration 
may be fully sufficient (both technically and documentation-wise) in an FPL.
Of course, this kind of advantage really matters only when you have 
started to use the approach on a larger scale, and at that point most 
people are already committed and couldn't reverse the decision even if 
they wanted to. That's why the FP arguments sound like every other 
hype... even if it's true. (I'm pretty sure that FP isn't the end-all of 
design-in-the-large, but it's the best technology that I know about. 
(Well, famous last words... *gg*))

Regards,
Jo
0
jo427 (1164)
6/22/2004 11:25:19 AM
"I spy" <s_nedunuri@yahoo.com> writes:

> I'm afraid this is a misunderstanding of OO. OO does not break down
> by data structure.

Okay.  But IMO, the main idea behind OO is the grouping of data and
functions. 

> OO is about *non hierarchical* breakdown of control. 

This used to be called "spaghetti code", and used to be regarded as a
bad ting.  OO is a way to bring some structure into this, to make it
managable.  

> In traditional stepwise refinement 

You can also build things bottom up, constructing the basic building
blocks for the process.  This is IMHO often advocated in FP.

> In OO you identify classes and allocate responsibilities
> for part of the task to each of the classes
> [...] Then the classes cooperate to get the task done. 

I still maintain that OO usually has the focus on the data structures
and their interfaces, rather than on the process you want to perform.
IME, objects are almost always the processees, not the process.  I
think that to some extent, processes are instead captured by design
patterns. 

> Of course despite what some people might be saying in this thread,
> there is no real reason why functional programming and OO design
> cannot be used together to mutual benefit.

Perhaps not, there certainly are multi-paradigm languages out there.

-kzm
-- 
If I haven't seen further, it is by standing in the footprints of giants
0
ketil (99)
6/22/2004 11:25:29 AM
"Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com> writes:

> Why do you bother to advertize your 'new' mailing list as "hosted by
> SourceForge" if you do not expect people to access it by standard
> SourceForge interfaces?

To give credit where credit is due.

> In the quote above, you don't even link to your specific SourceForge
> project.  You link to SourceForge in general.  People may very well
> infer that they can get to the SML/NJ mailing list from the
> SourceForge top level.

The mailing list (which was formerly hosted by Bell Labs and, thus,
totally off limits as far as self-subscribing and googling is
concerned) is a means of getting in touch with us in case of problems,
bugs, and suggestions.  It being now hosted by SF is merely a
consequence of our departure from BL, the fact that SF is a convenient
host to which most people have easy access, and the prospect that it
will continue to exist.

> > No, we have not "created" obscurity.  Our main presence on the web is
> > not the SF page.  Just because we did not post the list name there
> > does not mean we are more "obscure" than before.
> 
> Before *what* ?

Before SF even existed.  SML/NJ has been an open source project long
before "Open Source" became a household term.

Matthias
0
find19 (1244)
6/22/2004 11:33:05 AM
Brandon J. Van Every wrote:

> Joachim Durchholz wrote:
> 
>> Brandon J. Van Every wrote:
>> 
>>> I conclude, oddly enough, that inheritance at too fine a grain 
>>> actually violates encapsulation.
>> 
>> Actually inheritance violates encapsulation regardless of how you
>> use it: after all, the inheriting class has access to all the
>> internal machinery of all of its ancestors. (Unless that machinery
>> is "protected", but that comes with its own set of problems and 
>> limitations.)
> 
> False.  Try implementing 'Private' machinery.

Sorry, it was too late in the evening; I meant to write "private" 
wherever the above says "protected".

> In terms of industrial mindshare, FP sucks.

Well, I'm in the process of setting up a repository for SML code so that
there's easy access to SML libraries. Since I don't get paid for that,
it's been rather slow progress, isn't ready for the public, and won't be
for another three months or so (I'm going to move end of July, and
everything is in a state of disarray and neglect right now).

As this example shows, you can expect industrial-strength support if
there's industrial support. In industry, there would be a team
responsible for that (even if they were doing it part-time along with
other duties), so if one of them were unavailable the rest could keep
the thing working.
Since I'm doing it privately, there's no way it's going to be
industrial-strength.

If you're out for something that's got industrial-strength support,
don't rant about those languages that are still in academia. Or get
yourself an industry that gives you the needed support. Or select a
language that's already in industry, such as Erlang... and live with the
trade-offs that that entails (I'm pretty sure you know it's not all
roses there either, TANSTAAFL).
But don't rant. You'd get more intelligent responses if you didn't.

>> If you think that programming languages should be advanced into a
>> state of usability, write to your parliamentary representative and
>> propose funding for that...
> 
> What nonsense.  If I cared *that* much, I'd write the language.

Which would result in yet another sub-industrical-strength language.
If I'm writing nonsense, I'm definitely not alone in this exchange.
*plonk*

Jo
0
jo427 (1164)
6/22/2004 11:36:25 AM
"Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com> writes:

> So to take the inverse, in FP we'd expect the flow of data to become more
> difficult to track.  Six of one, half dozen of the other?

Yes, that wouldn't surprise me.  I'm sure that if you take a problem
that maps well to OO, it could be hard to model it elegantly using
FP.

So you would have to look at what the problem is focused on; does it
make sense to structure your program with a focus on process (e.g. as
a pipeline of filters), or on data (objects), before you decide the
technology you want to use.

-kzm
-- 
If I haven't seen further, it is by standing in the footprints of giants
0
ketil (99)
6/22/2004 11:40:22 AM
Ketil Malde wrote:

> FP is just a more elegant form of structured programming, it focuses on
> the breakdown of programs by control flow.

Eeek..I'm shocked (really:-), this seems remarkably similar to the IMHO
ill-informed FUD regularly parroted by a certain citizen of comp.object
(I won't name names, but anybody who can recall what was probably the
longest flame war in the history of comp.lang.functional will know who
I'm talking about:-)

Taken at face value this statement would appear support the allegations
of functional programs suffering from maintainability problems typical of
"legendary spaghetti code" with "hierarchical dependency". 

But seeing as I know that you are not ill-informed about FP, I guess you
have good reason for saying this (though I have to say I disagree).

[
I was considering writing a long explanation of why I don't think FP is
in any way comparable to traditional state dependent and state mutating
structured programming. But I guess I'd be preaching to the converted,
so I'll spare myself and everybody else from all that :-)
]

Regards
--
Adrian Hey 
0
ahey (217)
6/22/2004 12:08:24 PM
Matthias Blume wrote:
> 
> The mailing list (which was formerly hosted by Bell Labs and, thus,
> totally off limits as far as self-subscribing and googling is
> concerned) is a means of getting in touch with us in case of problems,
> bugs, and suggestions.  It being now hosted by SF is merely a
> consequence of our departure from BL, the fact that SF is a convenient
> host to which most people have easy access, and the prospect that it
> will continue to exist.

Do you want more visibility for SML/NJ?


-- 
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
6/22/2004 12:16:08 PM
On Tue, 22 Jun 2004, Brandon J. Van Every wrote:

> So to take the inverse, in FP we'd expect the flow of data to become more
> difficult to track.  Six of one, half dozen of the other?
>

Depends. In pure FP it's all there explicitly - same goes for references,
for that matter.

-- 
flippa@flippac.org

0
flippa (196)
6/22/2004 12:26:05 PM
Adrian Hey <ahey@NoSpicedHam.iee.org> writes:

>> FP is just a more elegant form of structured programming, it focuses on
>> the breakdown of programs by control flow.

> Eeek..I'm shocked

Okay.  It could be that I am indeed ill-informed, I only *use* a bit
of FP, I never really *learned* it, you know.  I find that I often
break down my code in a manner resembling how I wrote my Pascal
progams all these years ago - structuring the process, not the data.

I'm not at all trying to say that they are the same, or that I'd ever
want to go back.  While SP was rigid, FP is very flexible.  FP
supports reuse and bottom-up much better.

> Taken at face value this statement would appear support the allegations
> of functional programs suffering from maintainability problems typical of
> "legendary spaghetti code" with "hierarchical dependency". 

I'm sorry, but IMHO spaghetti is the opposite of structured -
spaghetti is when the control flow jumps arbitrarily around in code.
SP was trying to fix this by not letting you do that (GOTO considered
harmful etc).

But if your code is going to end up as spaghetti anyway, I think OO
may be a good way to structure it[*].  (One thing to look for may be
multiple "use cases"-diagrams involving the same classes?)

> (though I have to say I disagree).

Please elaborate!

-kzm

[*] Paul Graham says something along these lines in his "Advanced"
book, chapter on CLOS, but I don't have the book here to provide the
quote. 
-- 
If I haven't seen further, it is by standing in the footprints of giants
0
ketil (99)
6/22/2004 12:36:39 PM
Joachim Durchholz wrote:
> Brandon J. Van Every wrote:
>>
>> In terms of industrial mindshare, FP sucks.
>
> Well, I'm in the process of setting up a repository for SML code so
> that there's easy access to SML libraries. [...]
> Since I'm doing it privately, there's no way it's going to be
> industrial-strength.
>
> If you're out for something that's got industrial-strength support,
> don't rant about those languages that are still in academia.

You changed the subject.  My comment has nothing to do with whether your
personal project is industrial strength or not.  I can point you at
*legions* of open source C++ or Java or Python projects that are in exactly
the same boat you're in.

FP - any language, any form - has had decades to achieve industrial
mindshare of some kind or another.  It hasn't.  That's the bottom line.  We
must ask why, if we are to be honest about what our languages achieve and
what they don't.  Not hide behind covers like "it's an academia thing, you
just wouldn't understand."

We do see some exceptions in some cases.  Erlang has been mentioned.  I've
seen CAD companies use Lisp.  A few game studios try things other than C++.

> But don't rant. You'd get more intelligent responses if you didn't.

I think the only slight diminishment of intelligence going on here, is your
willingness to label what I say a 'rant'.  "FP sucks at industrial
mindshare" isn't a rant, it's a fact.  Maybe you meant: the fact makes you
mad, so you don't respond as intelligently to what you don't like to hear?

>>> If you think that programming languages should be advanced into a
>>> state of usability, write to your parliamentary representative and
>>> propose funding for that...
>>
>> What nonsense.  If I cared *that* much, I'd write the language.
>
> Which would result in yet another sub-industrical-strength language.

Not necessarily.  I might have better focus for such a problem than the next
guy.  Emphasis on *might*.  I have no interest in finding out right now, I
already said I avoid NIH as a matter of policy.  If someone has invented
what I want, then I don't need to.

Anyways, why do you think gov. funding would result in something other than
the language landscape we see today?

> If I'm writing nonsense, I'm definitely not alone in this exchange.
> *plonk*

You seem to be the sensitive type.  Whatever dude, enjoy your plonking.

-- 
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
6/22/2004 12:43:31 PM
Matthias Blume wrote:
> "Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com>
> writes:
>
>>> But that has nothing to do with the language itself.
>>
>> Not quite accurate.  Python, for instance, is reputed to be easy for
>> beginners to learn.  I would never presume to bill C++ as a 'quick
>> study' for anyone.  So perhaps his learning curve does indeed have
>> something to do with SML itself.
>
> Certainly, the slope of the curve is a function of the language (and,
> to some degree, the background of the learner).  But with a shallow
> curve, you never get to any significant elevation either (unless you
> spend a lot of time on that curve). :-)

Well, that's baloney in the case of C++.  For your deeper curve, all you get
is wasted time.  Python people claim they get tons for their shallow
curve... but they also haven't done much of anything for 3D graphics or AI
problems, so what would I conclude for my needs?  I can point to their
successes at process control, but not at large scale applications
development.  I think, "what is the curve, how steep should it really have
to be?" is problem domain specific.

>> C++, as far as I'm concerned, doesn't have any justification
>> anymore.  It's an evolutionary dead end.
>
> One thing we 100% agree on.

Heh, ain't that a hoot.

>> I hate debugging and avoid it as much as possible.  I control errors
>> by micro-incremental development, rigorous testing, and fascist
>> source control. I also hate understanding industrial APIs,
>> especially Microsoft APIs.  I hate *ever* trying to understand other
>> people's code.  It is mentally far less taxing to write my own code.
>> Unfortunately, I'm not some kind of prolific coding genius, so
>> writing my own code is somewhat pricey.  I'm hoping someday I find a
>> langauge and a development environment that works with my brain
>> instead of against it.  It certainly isn't C++.
>
> Wow.  A whole paragraph we nearly 100% agree on.  Maybe SML is for you
> after all...

We will see.  I'm on the language trajectory I'm on for a reason, and I've
been digging awfully hard at the 'better language problem' for about a year
now.

>> Do you piss off easily, instead of just taking lumps in stride that
>> might be partially deserved?
>
> Not that easily.  Otherwise I wouldn't be answering at all.

True.

> One thing is: In the end we are academics.  We are not judged by our
> peers based on whether our language has become successful (although
> this might be a tie-breaker in some cases), but rather on the number
> and quality of publications in reputable conferences an journals.
> When you want to publish, it helps somewhat to write about a
> successful product, but in the end it is the ideas that count, not the
> performance in the popularity contest.  (After all, as you noted,
> popularity and inherent value are often uncorrelated at best and
> sometimes even seem inversely proportional.)

And then at another extreme, you have the Corporates.  The ideal Corporate
language is something like Java or C#.  Mundane, somewhat labor saving over
a previous paradigm (C++), but wholly unremarkable.  A blunt tool for
grunting out code with legions of average programmers.  There's money in the
model, for the Corporate owners.  There's no competitive advantage for the
line worker.  She is a cog, her intelligence will not be leveraged.  She
will drown in repetitive processes that maintain lines of authority.  She
will ultimately be Indian, Russian, or Chinese.

I am not either of you.  I am an independent game developer.  I am mostly
self-taught in all areas of computerdom that I know.  I have been
self-funded the vast majority of the time.  I have neither academic peers,
nor corporate peers.  I have crossed a little into both worlds.  I share
some of each's concerns.  But my main goal is to GET THINGS DONE as a ONE
MAN BAND.  It is a crazy ambition, and there are few of us.  If only because
the 'low hanging fruit' was taken by such people in previous decades (Apple,
Microsoft, guys who wrote games like Sneakers).  I believe I / we are like
them and will fundamentally prevail.  We simply have to scale up to the
level of complexity that computerdom has become.

We cannot use the primitive technologies of the Corporates, nor put up with
academia when it chooses irrelevance.  So we have to take what's available
and fix it, until it works for us.

-- 
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
6/22/2004 1:17:14 PM
"Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com> writes:

> Matthias Blume wrote:
> > 
> > The mailing list (which was formerly hosted by Bell Labs and, thus,
> > totally off limits as far as self-subscribing and googling is
> > concerned) is a means of getting in touch with us in case of problems,
> > bugs, and suggestions.  It being now hosted by SF is merely a
> > consequence of our departure from BL, the fact that SF is a convenient
> > host to which most people have easy access, and the prospect that it
> > will continue to exist.
> 
> Do you want more visibility for SML/NJ?

Sure.  But I can't be the marketeer any more than I already am.  (In
other words: When I have to decide between improving the product and
improving its web page, I will always lean towards the former.
Moreover, neither of these two can be my top priority in life.)

Matthias
0
find19 (1244)
6/22/2004 1:34:48 PM
"Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com> wrote in message news:<2jqgjkF14h3qdU1@uni-berlin.de>...

-snip-
> > The it's my lack of experience also - you accurately describe my main
> > gripe against OO.  It's not so hard to see why; FP is just a more
> > elegant form of structured programming, it focuses on the breakdown of
> > programs by control flow.  OO focuses on breakdown by data structure,
> > and consequently, control flow becomes more difficult to track.
> 
> So to take the inverse, in FP we'd expect the flow of data to become more
> difficult to track.  Six of one, half dozen of the other?

Use an OO / functional hybrid, then control flow and data flow are
equally difficult to track ;-)
0
igouy (1009)
6/22/2004 3:12:36 PM
Brandon J. Van Every wrote:
> Joachim Durchholz wrote:
>> If I'm writing nonsense, I'm definitely not alone in this exchange.
>>  *plonk*
> 
> You seem to be the sensitive type.  Whatever dude, enjoy your
> plonking.

.... I've taken this to private mail.

Regards,
Jo
0
jo427 (1164)
6/22/2004 3:18:23 PM
Joachim Durchholz wrote:

> It was tantalizing to see that Erlang came so close, but failed on two
> relatively minor but essential points: security if you cannot trust all
> Erlang processes, and marshalling closures. Both can be worked around,
> but unfortunately in both cases the workarounds create impedance 
> mismatches.

Well, yes, I feel your pain. Indeed it *looks* like Erlang would be a 
tight fit, but as it wasn't really built for the 'Internet' but rather a 
  network of computers that you could still see (both the AXD and the 
GSNs are single rack configurations) 'expensive' stuff like security 
(authentication etc) done right was left out. (That and the fact that 
telecoms people are used to non hostile environments, phreaking 
notwithstanding).

These issues could be fixed now, from a functionality standpoint, but 
then that has the posibility of making the average usage slower/more 
resource intensive, and since the non-functional requirements are 
important in a highly standardised field such as telecoms, I'm not sure 
it would be an overall win.

Stefan,
-- 
Stefan Axelsson  (email at http://www.cs.chalmers.se/~sax)
0
crap1234 (43)
6/22/2004 4:10:09 PM
Ketil Malde wrote:

> I'm sorry, but IMHO spaghetti is the opposite of structured -
> spaghetti is when the control flow jumps arbitrarily around in code.
> SP was trying to fix this by not letting you do that (GOTO considered
> harmful etc).

unless you start using call/cc and first-class continuations: obscurity 
by elegance (and considered harmful) ;-)

	Simon
0
Simon
6/22/2004 4:13:06 PM
Joachim Durchholz wrote:

> Both.
> Erlang is functional when programming-in-the-small and concurrent when
> programming-in-the-large.

Seconded.

> There's also a quote about the software in the Ericsson AXP line of
> telephony switches. I may have gotten the numbers mixed up so please
> check before you quote me, but it was something around the lines of
> "100,000 lines of Erlang, 100,000 lines of C, 80% of the functionality
> is done in the Erlang parts".

Close. The AXD line of ATM switches has ca 1 million lines of Erlang 
(the logic, failover etc, the 'difficult' stuff), ca 500k lines of C 
(device drivers mostly) and ca 13k lines of Java (management interface 
mostly). If you want the exact line counts as of today you have to ask 
Ulf. :-)

Stefan,
-- 
Stefan Axelsson  (email at http://www.cs.chalmers.se/~sax)
0
crap1234 (43)
6/22/2004 4:14:26 PM
Simon Helsen wrote:

> unless you start using call/cc and first-class continuations: obscurity 
> by elegance (and considered harmful) ;-)

I meant *not* harmful (call/cc is not harmful, at least, IMO)

	Simon
0
Simon
6/22/2004 4:17:21 PM
On Tue, 22 Jun 2004, Brandon J. Van Every wrote:

> Joachim Durchholz wrote:
> > Brandon J. Van Every wrote:
> >>
> >> In terms of industrial mindshare, FP sucks.
> >
> > Well, I'm in the process of setting up a repository for SML code so
> > that there's easy access to SML libraries. [...]
> > Since I'm doing it privately, there's no way it's going to be
> > industrial-strength.
> >
> > If you're out for something that's got industrial-strength support,
> > don't rant about those languages that are still in academia.
>
> You changed the subject.  My comment has nothing to do with whether your
> personal project is industrial strength or not.  I can point you at
> *legions* of open source C++ or Java or Python projects that are in exactly
> the same boat you're in.
>
> FP - any language, any form - has had decades to achieve industrial
> mindshare of some kind or another.  It hasn't.  That's the bottom line.
[snip]

XPath, XSLT (and its predecessor DSSSL), and now XQuery. XQuery has
*enormous* mindshare, and it's growing.

That XSLT doesn't *kill* people's taste for FP is a miracle in and of
itself :)

Of course, exactly what is being shared by these minds is a little hard to
say. However, I think ruthlessly securing a bandwagon (by whatever means)
is a fairly standard route to mindshare. (See Java.)

FP and tree transformation/manipulation do seem to be a good fit.
Certainly, research in type systems has been influential in the XML world
otherwise (see Relax-NG). It's not like there lacks for, e.g., OO
approaches (see DOM), or even wackier ones (see SAX).

Cheers,
Bijan Parsia.

0
bparsia (12)
6/22/2004 4:39:59 PM
Simon Helsen wrote:

[...]


> If you disagree so much, could you please qualify yourself?

The distinguishing characteristic of functional programming languages is 
the ability to compose functions from other functions in the manner of 
the lambda calculus. (Some people also consider referential transparency 
(no destructive updates) and lazy evaluation to be defining criteria, 
but curiously no one seems eager to offer alternative terminology for 
languages that conform to the first, but not the second and third (like 
Scheme and SML).)

Support for higher-order functions (as defined above) implies closures, 
but that's just an implementation detail. Too often the people who seem 
eager to trivialize the difference between languages with genuine 
support for higher-order functions and languages that kinda sorta have 
closures also seem to be people that haven't had a lot of experience 
with the former.

As for OO, it could be considered a matter orthogonal to FP were it not 
for the fact that it is much easier to do OO with FP than it is to do FP 
with OO. (See any one of many object system libraries for Scheme or 
Common Lisp.) What's interesting is trying to jibe OO with type systems, 
and in that context OO has a lot harder time standing on its own as a 
pervasive methodology.

As for deciding whether to use or not use SML, it depends on whether one 
is looking for reasons or excuses.

-thant

0
thant (332)
6/22/2004 5:17:42 PM
Simon Helsen wrote:
>>
>> On the other hand, Java's inner classes are not closures. They cannot 
>> capture variables from surrounding scope. That makes them almost useless.
> 
> I think you have relativate this a little-bit.
> 
> 1) There is entirely normal lexical scoping for "fields" of 
> encapsulating classes for both inner and local classes.

Of course, but that is not a sufficient criterion for closure. Even C++ 
has lexical scoping.

> 2) For local variables (and parameters, etc), yes, they have to be final 
> (i.e. normal bindings) for them to be available in the inner class. This 
> is because javac makes a copy of the used local variable. A trick to get 
> around that is to create an array with the rhs as its element and of 
> course, each reference to it in the local block has to access the local 
> variable via the array element. While ackward, it behaves like a 
> closure. In fact, this is not so different from what happens in SML. 
> Only in Java, there is no such thing as a ref constructor, so you have 
> to use an array for that instead.
> 
> I do not see what you mean by "that makes them useless".

You can always build closures by hand (and in a language with garbage 
collection, even use them), but do you really want to? What you suggest 
sounds very unnatural and tedious to me.

> if you program in an OO fashion in Java (quite likely!) you do not face 
> these problems in the first place. Local variable updates in the local 
> class are not likely and enclosing field updates, being most common, are 
> allowed.

Why do you think it is "OO fashion" not to use closures over local 
variables? Besides this somewhat sidestepping the point, I'd say that 
e.g. in Smalltalk you'd use them quite frequently, for example for 
iterating over collections. In a non-functional setting, the need for 
local updates arises quite naturally then, if you ever want to return 
something interesting as a result.

Mind you that Java libs and programs avoid that idiom, partly due to its 
restricted closure mechanism, and partly due to its inflexible type system.

> What do you mean by variables are (or are not) first-class? Could you 
> explain exactly what the difference is here? The only difference I see 
> is that SML (like all impure FPLs) makes a distinction between bindings 
> (by default) and assignments (requiring extra syntax). In Java, that 
> happens "the other way around" by having assignments by default and 
> bindings by annotation.

In ML, a "variable" in the imperative sense is called a reference, which 
is first-class and hence can be passed around independently from any 
context. In typical imperative languages, variables can only be copied 
out of context.

Cheers,

	- Andreas

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

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

0
rossberg (600)
6/22/2004 5:54:01 PM
Andreas Rossberg wrote:

> Simon Helsen wrote:
> 
>>>
>>> On the other hand, Java's inner classes are not closures. They cannot 
>>> capture variables from surrounding scope. That makes them almost 
>>> useless.
>>
>>
>> I think you have relativate this a little-bit.
>>
>> 1) There is entirely normal lexical scoping for "fields" of 
>> encapsulating classes for both inner and local classes.
> 
> 
> Of course, but that is not a sufficient criterion for closure. Even C++ 
> has lexical scoping.

that is of course not what I meant (and you know it). Lexical scoping is 
lexical scoping and it becomes interesting once you have the ability to 
talk about code in a first-class manner, e.g. with inner classes or 
blocks. If you do not implement them as closures, then you automatically 
get dynamic scoping instead of lexical scoping. The issue simply does 
not arise in C++ and in fact, I reiterate that lexical scoping *is* the 
sufficient criterion to make first-class *code* into closures.

> You can always build closures by hand (and in a language with garbage 
> collection, even use them), but do you really want to? What you suggest 
> sounds very unnatural and tedious to me.

It is tedious, but you do not entirely program them by hand. Java 
literally copies the local variable inside the inner class, essentially 
constructing a closure. However, because

1) Java combines binding and assignments in one construct, and
2) puts local variables on the stack

they have decided to enforce the "final" requirement. The latter makes 
you variable assignment behave like a binding and the array behaves like 
a reference. I never said this is a natural style. I am just pointing 
out that the differences are not all that big because Java *does* copy 
the local variables inside the inner class, just like you expect from a 
closure.

> Why do you think it is "OO fashion" not to use closures over local 
> variables? Besides this somewhat sidestepping the point, I'd say that 
> e.g. in Smalltalk you'd use them quite frequently, for example for 
> iterating over collections. In a non-functional setting, the need for 
> local updates arises quite naturally then, if you ever want to return 
> something interesting as a result.
> 
> Mind you that Java libs and programs avoid that idiom, partly due to its 
> restricted closure mechanism, and partly due to its inflexible type system.

You are right. I was too quick there. I agree that in Smalltalk, you 
want to do updates on your local variables from a block. But that is 
mostly because Smalltalk uses blocks in a lot of places where you have 
specific Java mechanisms to cope with it.

I only wanted to rebut your assertion that anonymous classes are 
essentially useless. Look at any significant body of (properly written) 
Java code and you will see that anonymous classes are used all over the 
place.

> In ML, a "variable" in the imperative sense is called a reference, which 
> is first-class and hence can be passed around independently from any 
> context. In typical imperative languages, variables can only be copied 
> out of context.

I understand this, but I find it bizar to call a variable first-class. 
You only break appart the notions of binding and assignment. In ML, you 
have binding unless you use a "ref", in Java you have assignment unless 
you use "final".

Again, the actual implementation of inner classes is not different from 
that of functional closures. It just happens that because Java puts the 
assigned value on the stack, and not on the heap, they enforce the user 
to use a binding instead.

	Simon
0
Simon
6/22/2004 8:28:11 PM
Thant Tessman wrote:

> The distinguishing characteristic of functional programming languages is 
> the ability to compose functions from other functions in the manner of 
> the lambda calculus. (Some people also consider referential transparency 
> (no destructive updates) and lazy evaluation to be defining criteria, 
> but curiously no one seems eager to offer alternative terminology for 
> languages that conform to the first, but not the second and third (like 
> Scheme and SML).)

That is *your* definition. I would like to put it differently. FP is a 
paradigm that by default supports binding and may or may not support 
assignment. This does not contradict the lamba calculus which 
effectively does everything by binding instead of destructive assignment 
(in contrast with Turing or Minsky machines). Now, for this to be 
practical, you usually want first-class functions. However, fc functions 
are not exclusive to FPs. In Smalltalk, you can compose functions as 
easily as in any functional language, yet, that is not the way to go 
about. The main reason is that Smalltalk is an OO system which is based 
on implicit state and thus requires destructive assignment by default. 
Functional binding (explicit state) as in FPs, would be problematic for 
Smalltalk's OO system.

So, SML, Scheme, Haskell, etc. all fall into the category of functional 
languages because they have "binding" by default. Yes, they also have 
first-class functions, but if that was the criterion, then I have to put 
Smalltalk in my list and do not want to do that. Btw, javascript also 
has first-class functions. Do you really want to call that an FP?

> Support for higher-order functions (as defined above) implies closures, 
> but that's just an implementation detail. 

I agree.

 > Too often the people who seem
> eager to trivialize the difference between languages with genuine 
> support for higher-order functions and languages that kinda sorta have 
> closures also seem to be people that haven't had a lot of experience 
> with the former.

If you are implying that I do not have a lot of experience with 
functional languages, you better watch your words. I have by *far* more 
experience in what I call functional languages, but I simply disagree 
that first-class functions are their distinguishing feature as explained 
above. In fact, from my long experience with FP, I noticed that 
functional state is the single-most reason why the FP paradigm is so 
good. HOFs are only a necessary thing to make this become practical.

I think the best "negative" example that HOFs are not that essential for 
FP is Erlang. Erlang long did not have explicit HOFs. Erlang is 
functional except for its concurrency model (Erlang also provides 
standard I/O). However, Erlang *did* have the distinction between 
binding and assignment. Modern versions of Erlang also have HOFs but I 
still get conflicting views on their necessity. Even though Erlang is 
mostly designed as a concurrent language, most people agree that it is 
also functional.

> As for OO, it could be considered a matter orthogonal to FP were it not 
> for the fact that it is much easier to do OO with FP than it is to do FP 
> with OO. (See any one of many object system libraries for Scheme or 
> Common Lisp.) What's interesting is trying to jibe OO with type systems, 
> and in that context OO has a lot harder time standing on its own as a 
> pervasive methodology.

It is true that static (say ML-like) typing does not go well with OO. If 
you try to program your typical OO program in Ocaml, you'll notice some 
of the problems. A modern interpretation of OO, however, implies 
implicit state and that does contract FP's inherent drive to separate 
binding from assignment. Without assignment, there is no way to 
manipulate your state. I know there things like functional objects, but 
I do not know if you can really call this an OO paradigm.

> As for deciding whether to use or not use SML, it depends on whether one 
> is looking for reasons or excuses.

What a naive remark. I am not looking for excuses to not use SML. I am 
in fact looking for excuses to *use* it. To date, in the vast majority 
of "real-world" situations, it would be irresponsible (and just plain 
dumb) to use SML. That is called pragmatism, a characteristic that a lot 
of the FP community lacks. I do not want to insult anybody because I 
know from my experience that academics get paid for papers, not working 
systems. Also, I admire the intelligence of many of the regular posters 
here. But that is not good enough to get it out there, working in a real 
environment, with real customers, real deadlines, and real money. For 
that to happen, you need pragmatism (they way the Erlang developers had 
it).

Anyways, feel free to live on in your bulp...

	Simon
0
Simon
6/22/2004 8:51:31 PM
Simon Helsen wrote:
> Thant Tessman wrote:
> 
>> The distinguishing characteristic of functional programming languages 
>> is the ability to compose functions from other functions in the manner 
>> of the lambda calculus. (Some people also consider referential 
>> transparency (no destructive updates) and lazy evaluation to be 
>> defining criteria, but curiously no one seems eager to offer 
>> alternative terminology for languages that conform to the first, but 
>> not the second and third (like Scheme and SML).)
> 
> 
> That is *your* definition. [...]

It's not a definition. It's an observation. I'm bored with arguments of 
terminology. Call it whatever you want.

> What a naive remark. I am not looking for excuses to not use SML. I am 
> in fact looking for excuses to *use* it. To date, in the vast majority 
> of "real-world" situations, it would be irresponsible (and just plain 
> dumb) to use SML. That is called pragmatism, a characteristic that a lot 
> of the FP community lacks. [...]

Last time I looked into the issue, memory violations were the single 
biggest category of software bugs and security vulnerabilities. Who's 
the ones being irresponsible?

-thant

0
thant (332)
6/22/2004 9:44:33 PM
"Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com> writes:

> Do you have any people in the SML/NJ community with minimal web design
> skills?

Define "minimal skills".
0
find19 (1244)
6/22/2004 9:48:44 PM
Matthias Blume wrote:
> "Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com>
> writes:
>
>> Matthias Blume wrote:
>>>
>>> The mailing list (which was formerly hosted by Bell Labs and, thus,
>>> totally off limits as far as self-subscribing and googling is
>>> concerned) is a means of getting in touch with us in case of
>>> problems, bugs, and suggestions.  It being now hosted by SF is
>>> merely a consequence of our departure from BL, the fact that SF is
>>> a convenient host to which most people have easy access, and the
>>> prospect that it will continue to exist.
>>
>> Do you want more visibility for SML/NJ?
>
> Sure.  But I can't be the marketeer any more than I already am.  (In
> other words: When I have to decide between improving the product and
> improving its web page, I will always lean towards the former.
> Moreover, neither of these two can be my top priority in life.)

Do you have any people in the SML/NJ community with minimal web design
skills?

-- 
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
6/22/2004 9:53:12 PM
Thant Tessman wrote:

> Last time I looked into the issue, memory violations were the single 
> biggest category of software bugs and security vulnerabilities. Who's 
> the ones being irresponsible?

what has *that* to do with the reasons for using or not using SML? Your 
response shows that you are not interested in a differentiated view. I 
am sorry I wasted my time.

	Simon
0
Simon
6/22/2004 10:07:57 PM
Simon Helsen wrote:
> Thant Tessman wrote:
>
>> As for deciding whether to use or not use SML, it depends on whether
>> one is looking for reasons or excuses.
>
> What a naive remark. I am not looking for excuses to not use SML. I am
> in fact looking for excuses to *use* it.

I don't see how you can deduce enough information from Thant's comment above
to know what he actually meant.  Seems to me he could be agreeing with you,
or you could be talking past each other.

> To date, in the vast majority
> of "real-world" situations, it would be irresponsible (and just plain
> dumb) to use SML. That is called pragmatism, a characteristic that a
> lot of the FP community lacks.

I don't know... I'm currently interested in SML/NJ because NLFFI looks far
more pragmatic *for my problems* (high performance 3D graphics and AI
algorithms) than OCaml does.  And, I wouldn't accuse the OCaml crowd of
being unpragmatic.  For instance they don't force a choice between
functional or imperative coding, and they are attempting to do OO with a
functional language.

I think it is fair to say, however, that any academic project is not as
pragmatic as a commercial one.

> I do not want to insult anybody because I
> know from my experience that academics get paid for papers, not
> working systems. Also, I admire the intelligence of many of the
> regular posters here. But that is not good enough to get it out
> there, working in a real environment, with real customers, real
> deadlines, and real money. For that to happen, you need pragmatism
> (they way the Erlang developers had it).

Well, Erlang was pushed by a company.  Academics definitely aren't into
'push', the only marketing they care about is papers.  To me the question is
whether academics allow / facilitate a bunch of non-academics, so that other
people can actually get the gruntwork done.  Issues like a standard OCaml
library get bandied about on caml-list, for instance.  It seems that the
OCaml community has evolved to the point that a lot of people are asking the
hard questions about industrialization.  It doesn't look like they've made
progress yet on the kind of community organization needed, i.e. nothing
remotely resembling the Python community.  And, as much progress as Python
has made on practical sharing of technologies, they still can't market their
way out of a paper bag.  Not for lack of trying either; rather, the PSF has
imposed barriers to progress.

The issue of who-cares-about-what and who's-in-charge definitely becomes
problematic.  In some sense languages have to free themselves of their
progenitors, because the progenitors often don't have the skills necessary
for industrialization and don't care.  So, popular language evolution is a
series of fits and starts until certain predictable milestones are overcome.
You can, for instance, look at the webpages for SML/NJ, OCaml, Python, Perl,
and Java and see exactly how far each language has evolved in terms of user
community and industrialization.

-- 
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
6/22/2004 10:32:17 PM
"Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com> writes:

> You can, for instance, look at the webpages for SML/NJ, OCaml, Python, Perl,
> and Java and see exactly how far each language has evolved [ ... ]

I would like to remind everyone that that SML/NJ is not a language but
merely one particular implementation of a language that has several
implementations of reasonable quality.

Also, extensive web representation is not identical to popularity or
utility.  (Where is the web page of the C programming language?)

Matthias
0
find19 (1244)
6/22/2004 11:27:50 PM
Simon Helsen wrote:
> Thant Tessman wrote:
> 
>> Last time I looked into the issue, memory violations were the single 
>> biggest category of software bugs and security vulnerabilities. Who's 
>> the ones being irresponsible?
> 
> 
> what has *that* to do with the reasons for using or not using SML? Your 
> response shows that you are not interested in a differentiated view. I 
> am sorry I wasted my time.

I hope I'm not putting the words in the mouths of SML's creators, but if 
anything differentiates the design of SML--particularly from languages 
that purport to be object-oriented, it's in its attempt to guarantee the 
soundness of your program in a statically-verifiable way while giving up 
as little expressiveness, performance, and practicality as possible. 
That is, the *main* thing that recommends SML is that it makes it easier 
to write bug-free programs, especially as the complexity of your 
application goes up.


-thant

0
thant (332)
6/23/2004 12:31:32 AM
Matthias Blume wrote:
{stuff deleted}
> Sure.  But I can't be the marketeer any more than I already am.  (In
> other words: When I have to decide between improving the product and
> improving its web page, I will always lean towards the former.
> Moreover, neither of these two can be my top priority in life.)

By improving the webpage you can get others to improve the product. Spending 
timing on developing a viable community of developers is more important than 
  "improving" SML/NJ.

The SML/NJ development philosophy suffers from a "cathedral" attitude that 
is counter productive. This pervades the SML community in general.  The 
whole SML Basis book fiasco being one of the more obvious recent stupidities.

Personal apologies to all the personalties involved. I do not mean to 
offend, but I want to vocally complain about this. They are all damn smart 
and hard working people, but I'm just sometimes amazed what actually ends up 
happening.

I think the SML/NJ developers are sticking to a very effective development 
philosophy that worked very well for at least a decade or so. It is 
unfortunate that this development philosophy is completely out of sync with 
the "real" world as it is today.

Wake up! Don't cop an attitude.

P.S. I've always been convinced that SML will become the Algol of my 
generation. You should read that as both high-praise and damnation. So, far 
nothing I've seen has changed by mind about that.

P.P.S. Ohhh that felt so good to get out of my system.. :P
0
danwang742 (171)
6/23/2004 3:54:34 AM
They also need a better web site.
The current one looks like it is run by dairy farmers interested in cows from
New Jersey :-)
0
rambam (304)
6/23/2004 4:12:32 AM
Matthias Blume <find@my.address.elsewhere> writes:

> The list is not supposed to be public.  It is for developers, and if
> you want to become one, you could have asked to be put on the list
> nicely (if you can't figure out how to do it yourself).

Most languages have a developers list and at least a few
general mailing lists.

Are we to assume that the SML/NJ general mailing lists are dead due
to lack of interest ?
0
rambam (304)
6/23/2004 4:14:18 AM
Matthias Blume <find@my.address.elsewhere> writes:

> Our main presence on the web is
> not the SF page.

Is it the Ocaml page ?

0
rambam (304)
6/23/2004 4:15:03 AM
"Daniel C. Wang" <danwang74@hotmail.com> writes:

>  I've always been convinced that SML will become the Algol of my
> generation. You should read that as both high-praise and
> damnation. So, far nothing I've seen has changed by mind about that.

Ocaml are doing an excellent job of keeping ML alive and visible.
0
rambam (304)
6/23/2004 4:17:50 AM
Matthias Blume <find@my.address.elsewhere> writes:

> One thing is: In the end we are academics.  We are not judged by our
> peers based on whether our language has become successful (although
> this might be a tie-breaker in some cases), but rather on the number
> and quality of publications in reputable conferences an journals.

Haskell seems to have a greater presence despite it's academic roots.
0
rambam (304)
6/23/2004 4:24:24 AM
Stefan Axelsson <crap1234@hotmail.com> writes:

> Brandon J. Van Every wrote:
>> It's all theoretical
>> handwaving, I see no evidence of proven utility.  FP's failure to capture
>> industry mindshare is clear enough.
>
> I guess this is where we wave the Erlang flag again?
> (http://www.erlang.org). I'd say there's quite some evidence of proven
> utility there. Within Ericsson alone we have two *major* products both
> very successfull in their fields (market leaders). And those aren't
> the only ones.

Erlang had the benefit of being designed by and promoted by people active in
industry instead of in academia.

0
rambam (304)
6/23/2004 4:31:30 AM
Matthias Blume wrote:
> "Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com>
> writes:
>
>> Do you have any people in the SML/NJ community with minimal web
>> design skills?
>
> Define "minimal skills".

Capable of performing the trivial edits I suggested for clarity of accessing
the mailing list, and having the time and wherewithal to do so?

-- 
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
6/23/2004 4:34:20 AM
I R T wrote:
> "Daniel C. Wang" <danwang74@hotmail.com> writes:
>
>>  I've always been convinced that SML will become the Algol of my
>> generation. You should read that as both high-praise and
>> damnation. So, far nothing I've seen has changed by mind about that.
>
> Ocaml are doing an excellent job of keeping ML alive and visible.

Yes, if I were picking languges solely on the basis of community viability,
there would be no contest.  OCaml beats SML/NJ hands down.  I think it is
possible for OCaml to reach the "Python stage" of industrialization, but of
course many problems have to be dealt with to make it happen.  Meanwhile,
SML/NJ has not reached the OCaml stage of industrialization.

I am hoping that by establishing a Seattle ML SIG, I can pull these language
communities along.  My ultimate goal is "better game technology."  It would
be sweet to someday do lectures at the GDC about why I'm making tons of
money and other people are not.  :-)  The candidate for my uber-game
technology is currently the ML language family.  Hope it works.

-- 
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
6/23/2004 4:42:53 AM
I R T wrote:
> They also need a better web site.
> The current one looks like it is run by dairy farmers interested in
> cows from New Jersey :-)

In terms of aesthetics, trying to talk to techies about "better websites" is
a lost cause.  Look at the eyesore that is www.python.org.  Look at that POS
logo.  I worked with groups of people who offered things like this instead:
http://www.pollenation.net/assets/public/python-main-oct05.png (bear in mind
it's an image of a webpage, not a webpage).  But the PSF is incompetent.
Guido went so far as to publically trash the web designer who did the logo
and the mockup as not really knowing anything about graphic design.  As far
as I'm concerned, in matters of visual aesthetics, Guido is an idiot.  The
kind of guy who should be CTO, never CEO, and certainly not an Art Director.
I've told him so, same way he told that web guy.

Meanwhile Sun rolls on with www.java.com.  Even though the volunteers of the
Python community are talented enough to compete with their slick web
designs.  It's nothing short of infuriating.  Fortunately for me personally,
I had enough problems with Python itself to walk away from it.  It really
isn't the right technology for what I want to do.  It may be in 3 to 5 years
though, when they've sped it up.

So, I've gone up some of the learning curve of making language communities
commercially viable.  Don't have any feather in my cap from it yet though.
The next part of the Master Plan is local conquest.  I think beer is a
powerful determinant of human action.

-- 
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
6/23/2004 4:55:29 AM
Thant Tessman wrote:
> Simon Helsen wrote:
>>
>> To date, in the vast
>> majority of "real-world" situations, it would be irresponsible (and
>> just plain dumb) to use SML. That is called pragmatism, a
>> characteristic that a lot of the FP community lacks. [...]
>
> Last time I looked into the issue, memory violations were the single
> biggest category of software bugs and security vulnerabilities. Who's
> the ones being irresponsible?

"Garbage collection for the masses" is yesterday's headline.  Java did it,
C# aped it.

There's no way I could consult SML/NJ with the kind of web presence it
currently has.  Any manager would take one look at those webpages and flee
in terror.  Even OCaml would be quite a stretch.  Currently my only option
is to write my own software with either, sell it, and make a lot of money.
Hopefully if I succeed at such production problems, "I've made money with
this" will become a powerful consulting tool.  But there's a faceplate
that's gonna have to happen as part of the exercise.

-- 
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
6/23/2004 5:03:16 AM
"Daniel C. Wang" <danwang74@hotmail.com> writes:

> By improving the webpage you can get others to improve the
> product. Spending timing on developing a viable community of
> developers is more important than "improving" SML/NJ.

Why don't you do it then, Dan?  If you feel so passionate about it...
(The opportunity was -- and still is -- there.)

> The SML/NJ development philosophy suffers from a "cathedral" attitude
> that is counter productive. This pervades the SML community in
> general.  The whole SML Basis book fiasco being one of the more
> obvious recent stupidities.

You are being extremely unfair, and you know it.  What "fiasco"?  What
"stupidities"?  Be glad John and (I believe) Emden are not reading
netnews, otherwise a big, serious apology would be in order.  And by
this I don't mean:

> Personal apologies to all the personalties involved. I do not mean to
> offend, [...]

This is bullshit!  You can't go around insulting people left and right
and then step away with a simple "oops, sorry, no offense" or such!

> but I want to vocally complain about this. They are all damn
> smart and hard working people, but I'm just sometimes amazed what
> actually ends up happening.

Maybe you could elaborate?  Yes, they are all smart and hard-working.
Which is why things are slow -- because being hard-working means they
can't spend all their time on these web pages.  [On second thought:
No, don't elaborate.  When I am done with this article I think I am
done with this thread, too.]

And by the way: I take the "cathedral" thing as a compliment.  I never
bought into this ESR nonsense anyway.  I *hate* bazaars in general,
and the software variety in particular.  Just go and have a look at
all those projects at SF: 90% utter crap, ill-conceived, half-baked,
full of bugs!  And even the ones that aren't crap (including the
high-profile ones) are almost never original in any way.  They are not
advancing our horizons!  There are things that cannot be done well
bazaar-style.  Designing a language or a library API are good examples
for that.

In short, I don't care if SML or Haskell or even OCaml or Clean or ...
will die -- as long as some of the better ideas that went into their
design make it into future languages and as long as the worst ideas
survive as warnings for future designers.  In this sense the Algol
analogy is probably true -- and no reason for being ashamed.

In the meantime, SML is by no means dead -- and neither is SML/NJ.  And
since many of us continue to find the language and the implementation
to be excellent tools for what we do, we will continue to try and help
improve them.

> I think the SML/NJ developers are sticking to a very effective
> development philosophy that worked very well for at least a decade or
> so.

Ok.

> It is unfortunate that this development philosophy is completely
> out of sync with the "real" world as it is today.

It seems to me that being effective would be better than being "in
sync" with the so-called "real" world.  You know, that "real" world
isn't all that great to begin with...

> P.S. I've always been convinced that SML will become the Algol of my
> generation. You should read that as both high-praise and
> damnation. So, far nothing I've seen has changed by mind about that.

See above.

> P.P.S. Ohhh that felt so good to get out of my system.. :P

Good for you.  I, otoh, feel like I have just been back-stabbed.

Matthias
0
find19 (1244)
6/23/2004 5:11:26 AM
Matthias Blume wrote:
> "Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com>
> writes:
>
>> You can, for instance, look at the webpages for SML/NJ, OCaml,
>> Python, Perl, and Java and see exactly how far each language has
>> evolved [ ... ]
>
> I would like to remind everyone that that SML/NJ is not a language but
> merely one particular implementation of a language that has several
> implementations of reasonable quality.

So, where is SML '97's web presence?  All of the SML implementations are at
the same level of web presence: better than nothing, but not by much.

> Also, extensive web representation is not identical to popularity

False.  Try Google hits as one of your metrics.

> or utility.  (Where is the web page of the C programming language?)

C and C++ have tremendous historical weight behind them.  Therefore, they
are no longer centralized.  You might dream of SML being at such a stage of
utility.

Java, C#, and all their major competitors have centralized web presences.
And books in every Barnes & Noble.  This is how the industrial game is
played.  In Seattle, most programmers understand this game exceedingly well,
because the master of the game is in our backyard.

-- 
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
6/23/2004 5:21:24 AM
Matthias Blume <find@my.address.elsewhere> writes:

> Why don't you do it then, Dan?  If you feel so passionate about it...

Or Brandon.  Or I R T.  Document your experiences.  Set up a Wiki.
Mailing lists.  Get involved!

> And by the way: I take the "cathedral" thing as a compliment.  I never
> bought into this ESR nonsense anyway

I think that to a large extent, successful software projects require
leadership.  Often as a single person doing most of the development
initially, to a handful of 'core' developers later on, as people dig
into the code to solve their particular problems.

The problem with this is that until there is a sufficiently large
team, the project risks dying at the whim of the core developer(s).
The multiple implementations of SML may be sufficiently compatible and
independent that this isn't a major blocker for its 'real world' use
-- I don't know.

But where the 'bazaar' is most helpful, is as a user community:
documentation, bug reports, web infrastructure.  And it seems to me
that is where most of the complaints about SML are directed -- and
Matthias has made it pretty clear that this is not where is interests
lie.  So, if you want SML to be industrially successful, you have to
contribute the advertising yourself.  I'm sure that for instance
www.standardml.org would be happy for any contributions.

-kzm
-- 
If I haven't seen further, it is by standing in the footprints of giants
0
ketil (99)
6/23/2004 7:11:15 AM
On Tue, 22 Jun 2004, Brandon J. Van Every wrote:

> "Garbage collection for the masses" is yesterday's headline.  Java did it,
> C# aped it.
>

Agreed, though check out MLKit's region inference system - no GC required.

-- 
flippa@flippac.org
0
flippa (196)
6/23/2004 8:13:23 AM
Hi,

> You didn't read past the front page of these web site(s), did you?
> On the SML/NJ front page you find a section on "Documentation and
> Literature".  The links lead to information on no less than 9
> tutorials and 19 books.  Admittedly, quite a few of them aren't what
> you are currently looking for, but to say that you weren't able to
> locate more than one book is a joke.

:-))) I guess most of them are already on your bookshelf. But just try
to order them or to find them in a computer bookshop. Most are old
things or are out of print.

>> - SML is *extremely* difficult to debug and retro-document.
>
> How much experience do you have with the language?

Not much. But overall, I have a very good experience of programming in
general and I usually adapt very quickly. I may not be SML-wired but
compared to the other tools I have used since years, I insist, it's more
difficult to debug SML. However, it's true that the code that I have to
maintain is not particularly well-commented.

> I find the idea of trying to understand a program by "stepping through
> it" mind-bogglingly ill-conceived (in *any* language).

Your opinion, not mine. In many cases you have no other choice. I would
even say that it's the fastest way to understand a code that is not
correctly documented.

>> - I tried to find some support on Usenet. I found 2 newsgroups:
>> comp.lang.functional and comp.lang.ml. The level of activity in these
>> groups makes me wonder how much developers are using the language.
>> You can't produce without support and obviously, support for SML is
>> scarce.
>
> Instead of ranting here about the lack of support, why did you not try
> asking a specific question?  Some people here do try to answer such
> questions!  Pissing them off right from the start doesn't sound like a
> great strategy.

Answer irrelevant. I'm not saying that questions are not answered. I
just looked at the activity on comp.lang.ml and was wondering how much
developers where using this language. When I say "no support", this
means:

    - no recent books (see above)
    - no rich set of companion tools (I was looking for a SML code
beautifier, for example - no such thing)
    - no tool vendors

SML is not a language supported by the industry. It is a tool mostly
used by researchers and scientists. Not a criticism. Just a fact. Again,
I'm trying to use this language in the commercial world. I have
deadlines to meet. I'm talking about production.


If I understand well, you're pretty involved in the development of SML.
While this certainly gives you an authoritative opinion on the language
benefits and capabilities, on the other hand, this doesn't qualify you
as the right person for evaluating the difficulties of using SML in the
industry. That's the point. I'm not bashing the language. I'm convinced
it has been pretty well designed in order to solve very difficult
problems. I'm just trying to evaluate whether it can really be used for
the project that I have to maintain given the constraints of my
customer.

I'm not interested in philosophical discussions about what language is
the best. I have used many languages in my programmer's life (APL,
BASIC, Pascal, C, C++, assembly, VB, VB .Net, C#, just to name a few).
None is the best, some are better suited for certain projects than
others.  I just want to determine what *solution* is the best for my
customer. And currently, I see many drawbacks in the current SML
approach originally taken in this project given the lack of productivity
tools. The problems that I mentioned are real and are inhibitors for my
current project. They may not be of any importance under different
circumstances.

Cheers.

-- 
Patrick Philippot - Microsoft MVP [.Net]
MainSoft Consulting Services
www.mainsoft.fr


0
6/23/2004 8:58:35 AM
"Ketil Malde" <ketil@ii.uib.no> wrote in message
news:eg7jtzq1g6.fsf@havengel.ii.uib.no...
> "I spy" <s_nedunuri@yahoo.com> writes:
>
>
> > In OO you identify classes and allocate responsibilities
> > for part of the task to each of the classes
> > [...] Then the classes cooperate to get the task done.
>
> I still maintain that OO usually has the focus on the data structures
> and their interfaces, rather than on the process you want to perform.
> IME, objects are almost always the processees, not the process.  I
> think that to some extent, processes are instead captured by design
> patterns.
I have been architecting and designing OO software for 10 years and I have
no idea what you're talking about here. Any OO book that says that OO
focusses on data structures is imparting misinformation. Some of the earlier
OO books used to suggest "start brainstorming classes, writing down the
names of all the 'things' you can think of", so perhaps that's where you got
the idea. But the things being identified have little to do with data -
instead they are about responsibilities (e.g. to take a simple HR example,
what responsibilities does Employee have, what does a Company have, what
does a Project have, etc. Once you've identified the responsibilites, and
only then, does it make sense to sit down and figure out what data and data
structures a class needs in order to get its job done). Which is why many
design sessions today start with CRC (Class Responsibility Collaboration)
cards to get peoples mindsets away from the notion that its about data
structures. The idea that class = data structure is probably the most
damaging idea that ever took hold in OO, and might explain all that Fortran
code out there masquerading as OO.

As for design patterns, where did you get the idea they are about capturing
processes?

cheers
-sri


0
s_nedunuri (52)
6/23/2004 9:14:18 AM
I don't know much about them, but have you looked at languages like O
Haskell or Scala?
(http://scala.epfl.ch/).

"Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com> wrote in
message news:2jqh6tF14isutU1@uni-berlin.de...
> I spy wrote:
> >
> > Of course despite what some people might be saying in this thread,
> > there is no real reason why functional programming and OO design
> > cannot be used together to mutual benefit.
>
> Sure they can, as in OCaml.  But my original motivation in asking my
> question, is that OCaml has a bad interface to low level code (only 31-bit
> ints, no 32-bit floats, funky 2-step C calling conventions) and SML/NJ
> doesn't.  The price for what I want is giving up OO.  So, I want to know
how
> FP languages 'do things' without OO support.
>
> -- 
> 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
s_nedunuri (52)
6/23/2004 9:15:59 AM
"Bijan Parsia" <bparsia@email.unc.edu> wrote in message
news:Pine.A41.4.44+UNC.0406221235040.59608-100000@login0.isis.unc.edu...
> On Tue, 22 Jun 2004, Brandon J. Van Every wrote:
>
> > Joachim Durchholz wrote:
> > > Brandon J. Van Every wrote:
> > >>
> > >> In terms of industrial mindshare, FP sucks.
> > >
> > > Well, I'm in the process of setting up a repository for SML code so
> > > that there's easy access to SML libraries. [...]
> > > Since I'm doing it privately, there's no way it's going to be
> > > industrial-strength.
> > >
> > > If you're out for something that's got industrial-strength support,
> > > don't rant about those languages that are still in academia.
> >
> > You changed the subject.  My comment has nothing to do with whether your
> > personal project is industrial strength or not.  I can point you at
> > *legions* of open source C++ or Java or Python projects that are in
exactly
> > the same boat you're in.
> >
> > FP - any language, any form - has had decades to achieve industrial
> > mindshare of some kind or another.  It hasn't.  That's the bottom line.
> [snip]
>
> XPath, XSLT (and its predecessor DSSSL), and now XQuery. XQuery has
> *enormous* mindshare, and it's growing.
>
> That XSLT doesn't *kill* people's taste for FP is a miracle in and of
> itself :)
Huh? I've written good sized XSLT scripts and seen the contortions you have
to go through to get the job done. Give me a good term rewrite engine any
day. Besides, its somewhat apples and oranges to compare XSLT and FP.
Different tools for different jobs
cheers
-sri


0
s_nedunuri (52)
6/23/2004 9:23:27 AM
On Wed, 23 Jun 2004, I spy wrote:

> "Bijan Parsia" <bparsia@email.unc.edu> wrote in message
> news:Pine.A41.4.44+UNC.0406221235040.59608-100000@login0.isis.unc.edu...
[snip]
> > > FP - any language, any form - has had decades to achieve industrial
> > > mindshare of some kind or another.  It hasn't.  That's the bottom line.
> > [snip]
> >
> > XPath, XSLT (and its predecessor DSSSL), and now XQuery. XQuery has
> > *enormous* mindshare, and it's growing.
> >
> > That XSLT doesn't *kill* people's taste for FP is a miracle in and of
> > itself :)
> Huh? I've written good sized XSLT scripts and seen the contortions you have
> to go through to get the job done.

Hence my wonder.

>  Give me a good term rewrite engine any
> day. Besides, its somewhat apples and oranges to compare XSLT and FP.

Hardly. XSLT is a functional programming language. It's basically syntatic
uglification of DSSSL-O which is a fairly pure functional subset of
Scheme. It's pattern matching oriented, has single assignment, etc. etc.

XQuery has a nicer syntax and an interesting type system etc. etc.

> Different tools for different jobs

Well, except XSLT is perhaps the most widely used FP langauge. So, to some
degree, they are the same tool (though saying "FP" covers so much, it's a
bit odd to compare).

Cheers,
Bijan Parsia.

0
bparsia (12)
6/23/2004 9:30:30 AM
"Bijan Parsia" <bparsia@email.unc.edu> wrote in message
news:Pine.A41.4.44+UNC.0406230526220.67778-100000@login2.isis.unc.edu...
> On Wed, 23 Jun 2004, I spy wrote:
>
> > "Bijan Parsia" <bparsia@email.unc.edu> wrote in message
> > news:Pine.A41.4.44+UNC.0406221235040.59608-100000@login0.isis.unc.edu...
> [snip]
> > > > FP - any language, any form - has had decades to achieve industrial
> > > > mindshare of some kind or another.  It hasn't.  That's the bottom
line.
> > > [snip]
> > >
> > > XPath, XSLT (and its predecessor DSSSL), and now XQuery. XQuery has
> > > *enormous* mindshare, and it's growing.
> > >
> > > That XSLT doesn't *kill* people's taste for FP is a miracle in and of
> > > itself :)
> > Huh? I've written good sized XSLT scripts and seen the contortions you
have
> > to go through to get the job done.
>
> Hence my wonder.
>
> >  Give me a good term rewrite engine any
> > day. Besides, its somewhat apples and oranges to compare XSLT and FP.
>
> Hardly. XSLT is a functional programming language. It's basically syntatic
> uglification of DSSSL-O which is a fairly pure functional subset of
> Scheme. It's pattern matching oriented, has single assignment, etc. etc.
I'm having a hard time seeing how you can call XSLT a functional language.
Where's the higher order functions? Where's the recursive functions? Where's
the type classes? Where's the type inferencing? All these either
characterize or are pretty much standard with modern day functional
languages. XSLT is just a verbose term rewrite engine, nothing more. And not
a particularly clever one at that.

> XQuery has a nicer syntax and an interesting type system etc. etc.
>
> > Different tools for different jobs
>
> Well, except XSLT is perhaps the most widely used FP langauge. So, to some
> degree, they are the same tool (though saying "FP" covers so much, it's a
> bit odd to compare).
well I disagree with your characterization of XSLT as a functional language
so I can't really comment on the rest of your statement
cheers
-sri

> Cheers,
> Bijan Parsia.
>


0
s_nedunuri (52)
6/23/2004 9:47:32 AM
"I spy" <s_nedunuri@yahoo.com> writes:

> I have been architecting and designing OO software for 10 years and
> I have no idea what you're talking about here.

Okay - perhaps I don't really grok OO.

> The idea that class = data structure is probably the most damaging
> idea that ever took hold in OO, and might explain all that Fortran
> code out there masquerading as OO.

So what is a class, then?  I happily admit to the belief that it is a
data structure enriched with operations.  IME most, if not all, data
an OO program uses is encapsulated in objects.  Classes tend to be
nouns, nouns tend to be data.  (Especially in contrast to FP where
things tend to be structured around functions, i.e. the verbs.  (Also
IME; so I'm probably going to be flamed from the other side as well :-))

(Does Fortran even have data structures other than arrays? :-)

> As for design patterns, where did you get the idea they are about
> capturing processes?

Because from what I've seen, they describe how objects interact in
order to achieve some (somewhat abstracted) process.  As you say,
the class structure are defined by identifying 'concepts' and their
responsibilities.  They don't tell you how the classes interact,
that's why you have 'use cases' and, I think, at least to some extent,
design patterns.

Perhaps I don't know them well enough; I've only done a little OO, and
that was a while ago.

-kzm
-- 
If I haven't seen further, it is by standing in the footprints of giants
0
ketil (99)
6/23/2004 10:11:03 AM
Matthias Blume wrote:
>
> And by the way: I take the "cathedral" thing as a compliment.  I never
> bought into this ESR nonsense anyway.  I *hate* bazaars in general,
> and the software variety in particular.  Just go and have a look at
> all those projects at SF: 90% utter crap, ill-conceived, half-baked,
> full of bugs!  And even the ones that aren't crap (including the
> high-profile ones) are almost never original in any way.  They are not
> advancing our horizons!

When you refuse to be industrially relevant, whatever originality you may
come up with doesn't make it to 99.9999% of people.  You can't advance the
computer industry's horizons that way.  You can only advance the horizons of
an exceedingly narrow group of your academic peers.

> There are things that cannot be done well
> bazaar-style.  Designing a language or a library API are good examples
> for that.

Growing language communities is a bazaar problem, not a cathederal problem.
In an ideal world, the people who insist on spending most of their time in
the cathederal would at least acknowledge the concerns of those in the
marketplace outside, and take minimal steps to facilitate their
organization.  Bazaar people can organize bazaars, but you have to let them,
and minimally coordinate with them.

For instance, if someone complains that they can't find your mailing list,
where does that complaint go?  Circular file?  Or do you authorize /
deputize someone to edit your webpages?

> In short, I don't care if SML or Haskell or even OCaml or Clean or ...
> will die -- as long as some of the better ideas that went into their
> design make it into future languages and as long as the worst ideas
> survive as warnings for future designers.  In this sense the Algol
> analogy is probably true -- and no reason for being ashamed.

So, you write for language designers.  Not working programmers.  A pity.
With such an attitude, you are unlikely to improve the programming lives of
terribly many people.

-- 
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
6/23/2004 10:25:49 AM
Ketil Malde wrote:
> Matthias Blume <find@my.address.elsewhere> writes:
>
>> Why don't you do it then, Dan?  If you feel so passionate about it...
>
> Or Brandon.  Or I R T.  Document your experiences.  Set up a Wiki.
> Mailing lists.  Get involved!

I am currently organizing a Seattle ML SIG, as per a post I recently made to
comp.lang.ml.  I attempted to produce marketing materials for the Python
community.  I have learned from experience, however, that there are certain
things I can't do if the gatekeepers withhold the keys to the kingdom.  Like
edit web pages I don't have authorization for.

There are certain things the Powers That Be have to do, in order to build
credible language communities.  If the official website of a given language
is not in good order, it's very unlikely that a third party contender can
reverse the negative marketing that generates.  You'd have to get to the
size of the Python community before it would be possible to have a 'palace
revolt' and get the traffic to go to your website instead of the broken
official website.  And unfortuantely, the people in the Python world who
could have pulled that off, folded up their tent and went home.

> So, if you want SML to be industrially successful, you have to
> contribute the advertising yourself.  I'm sure that for instance
> www.standardml.org would be happy for any contributions.

This bodes ill.  Both of their listed mailing lists are dead and contain
spam.  One is the very same dead list that triggered this subthread!  A
viable language community is not happening here.

So which is the easier problem?  Getting SML guys to form a viable language
community, or getting the OCaml implementors to fix their broken integer
representation, add 32-bit float support, and clean up the C FFI?  Talk
about a rock and a hard place!  I think I'm just going to get drunk with
whomever's in Seattle until the answer reveals itself.

-- 
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
6/23/2004 10:49:34 AM
Patrick Philippot wrote:
>
>> I find the idea of trying to understand a program by "stepping
>> through it" mind-bogglingly ill-conceived (in *any* language).
>
> Your opinion, not mine. In many cases you have no other choice. I
> would even say that it's the fastest way to understand a code that is
> not correctly documented.

Or sparsely documented.  I've certainly used this approach to understand
other people's open source game projects.  Such projects are not too big,
and their flow control is not too crazy.  I would say that cranking up the
debugger is appropriate for understanding any project with a "modest main
trunk."  A 3D device driver, for instance, may contain huge amounts of code
but probably has a fairly modest main trunk.

-- 
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
6/23/2004 11:03:32 AM
Ketil Malde wrote:

> "I spy" <s_nedunuri@yahoo.com> writes:
>
> (...)
>
> > The idea that class =3D data structure is probably the most damaging
> > idea that ever took hold in OO, and might explain all that Fortran
> > code out there masquerading as OO.
>
> So what is a class, then?

Quoting from Meyer's Object-Oriented Software Construction
(2ed, pg. 142):

"A class is an Abstract Data Type equipped with a possibly partial
implementation."

> I happily admit to the belief that it is a
> data structure enriched with operations.  IME most, if not all, data
> an OO program uses is encapsulated in objects.  Classes tend to be
> nouns, nouns tend to be data.  (Especially in contrast to FP where
> things tend to be structured around functions, i.e. the verbs.  (Also
> IME; so I'm probably going to be flamed from the other side as well :-)=
)

OO is built around abstract data (not data). Interacting with an object
is done through its (class) public interface, and it must obey its contra=
ct
(methods/features preconditions). In return the object "ensures" that
the class's invariants and method/feature postconditions are also obeyed.=


The implementation of an object data structures and its methods/features
are irrelevant internal issues (from the client's point of view).

All this being said, it is true that when searching for "appropriate"
classes (ADT's), the data (information) eventually used in the problem
space is a much better approach than to look at than the "functions"
of the problem. They are less vulnerable to changes (specially if one
captures "correctly" their abstract properties, and clearly delegates
the responsibilities [contracts] between the class and its clients).

> (...)
>
> -kzm
> --
> If I haven't seen further, it is by standing in the footprints of giant=
s

-miguel

--
Miguel Oliveira e Silva   email: mos@det.ua.pt
Dep. de Electr=F3nica e Telecomunica=E7=F5es / IEETA
Universidade de Aveiro - PORTUGAL
phone: +351 234 370375    fax: +351 234 370545
www: http://www.ieeta.pt/~mos


0
mos (67)
6/23/2004 11:04:45 AM
I spy wrote:
> I don't know much about them, but have you looked at languages like O
> Haskell

I have not read that Haskell is high performance, so I wouldn't expect it of
O'Haskell.  The main reason I investigated OCaml rather than Haskell is
performance.  Also, OCaml seemed more willing to be industrially relevant
than Haskell.  Haskell seems oriented towards "very computer sciency
paradigms."  I am not sure if those paradigms are valuable or not.  I do
know that I need good interfaces down to the ASM level, and grunging with
low level optimization problems seems to bore an awful lot of academics.

> or Scala? (http://scala.epfl.ch/).

Just looked at it now.  It lays out webs, networks, and .NET interoperation
as basic motivators - all things I hate and am utterly uninterested in.  I
want a language that generates fast native code for low level 3D graphics
and AI problems, but is also a HLL.

-- 
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
6/23/2004 11:18:26 AM
Brandon J. Van Every wrote:
> Fortunately for me personally,
> I had enough problems with Python itself to walk away from it.  It really
> isn't the right technology for what I want to do.  It may be in 3 to 5 years
> though, when they've sped it up.

Have you tried Psyco? (http://psyco.sourceforge.net/) It made Python 
fast enough for my interactive visualisations (that admittedly aren't 
game related).

Stefan,
-- 
Stefan Axelsson  (email at http://www.cs.chalmers.se/~sax)
0
crap1234 (43)
6/23/2004 11:41:20 AM
Simon Helsen wrote:
> 
> Lexical scoping is 
> lexical scoping and it becomes interesting once you have the ability to 
> talk about code in a first-class manner, e.g. with inner classes or 
> blocks. If you do not implement them as closures, then you automatically 
> get dynamic scoping instead of lexical scoping. The issue simply does 
> not arise in C++ and in fact, I reiterate that lexical scoping *is* the 
> sufficient criterion to make first-class *code* into closures.

There is a difference between lexical scoping and lexical closure. All 
remotely modern languages have the former, but only high-level languages 
tend to have the latter.

Imposal of restrictions on lexical closure does not turn lexical scoping 
into dynamic scoping. Still it means that you do not have proper (full) 
closure. I agree that Java is not far away. I just consider the missing 
bit very important.

Btw, the issue *does* arise in C++, that's why it has even more 
arbitrary restrictions than Java (local functions may only access static 
variables of outer scope etc.).

> Java 
> literally copies the local variable inside the inner class, essentially 
> constructing a closure. However, because
> 
> 1) Java combines binding and assignments in one construct, and
> 2) puts local variables on the stack
> 
> they have decided to enforce the "final" requirement. The latter makes 
> you variable assignment behave like a binding and the array behaves like 
> a reference. I never said this is a natural style. I am just pointing 
> out that the differences are not all that big because Java *does* copy 
> the local variables inside the inner class, just like you expect from a 
> closure.

Agreed, but this minor technical difference has major practical impact, 
IMHO.

> I agree that in Smalltalk, you 
> want to do updates on your local variables from a block. But that is 
> mostly because Smalltalk uses blocks in a lot of places where you have 
> specific Java mechanisms to cope with it.

That is precisely my point. Why do you need these specific ad-hoc 
mechanisms instead of a more generic approach? Because Java's support 
for closures is not powerful enough! It can only be used for rather 
trivial things.


>> In ML, a "variable" in the imperative sense is called a reference, 
>> which is first-class and hence can be passed around independently from 
>> any context. In typical imperative languages, variables can only be 
>> copied out of context.
> 
> I understand this, but I find it bizar to call a variable first-class. 

Why?

> You only break appart the notions of binding and assignment.

Breaking apart, or rather decoupling, concepts is exactly what makes 
them first class.

> In ML, you 
> have binding unless you use a "ref", in Java you have assignment unless 
> you use "final".

Some rather philosphical comment: you suggest that both approaches are 
somehow dual, but they aren't. In ML, when you need a certain capability 
(eg. mutability) you create a value of a type that provides it. In Java, 
that capability is always there by default, built into some other, 
conceptionally unrelated mechanisms (functions, objects), and you need 
sort of a "negative capability" (final) to revoke it. Maybe it's just 
me, but I find this backwards, unnatural, and the need for negation 
suspicious. The only reason I can see is historical accident.

	- Andreas

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

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

0
rossberg (600)
6/23/2004 11:46:01 AM
Brandon J. Van Every wrote:
> Thant Tessman wrote:
> 
>>Simon Helsen wrote:
>>
>>>To date, in the vast
>>>majority of "real-world" situations, it would be irresponsible (and
>>>just plain dumb) to use SML. That is called pragmatism, a
>>>characteristic that a lot of the FP community lacks. [...]
>>
>>Last time I looked into the issue, memory violations were the single
>>biggest category of software bugs and security vulnerabilities. Who's
>>the ones being irresponsible?
> 
> 
> "Garbage collection for the masses" is yesterday's headline.  Java did it,
> C# aped it.

Yes the fact that Java supports automatic memory management allows it to 
avoid the single biggest category of software bugs. But it's hard to 
consider this much of an accomplishment given other (better) programming 
languages have been doing this for decades.

The popularity of Java in particular is proof that the biggest obstacles 
to the advancement of the craft of computer programming are cultural, 
not technical. Java is C++ with garbage collection and without all that 
complicated template stuff. Although I hear they're adding back some of 
that complicated template stuff because it was in C++ for a reason.


> There's no way I could consult SML/NJ with the kind of web presence it
> currently has.  Any manager would take one look at those webpages and flee
> in terror. [...]

What kind of manager decides on a programming language based on a web page?

There are reasons I have to use C++ most of the time (and there are 
people I work with who would rather I use C instead--I tell them no), 
but those reasons aren't ubiquitously preponderate, and I have used SML 
for Real Work (TM) in the past, and plan to use it again in the future.

-thant

0
thant (332)
6/23/2004 1:36:14 PM
In article <cbc10d$82r$1@news.xmission.com>,
Thant Tessman  <thant@acm.org> wrote:
> not technical. Java is C++ with garbage collection and without all that 
> complicated template stuff. Although I hear they're adding back some of 
> that complicated template stuff because it was in C++ for a reason.

Except that now it's much less complicated and less bloaty, and in
general Done Right.

(Well, all right, I would have preferred NextGen instead of GJ as the
basis of JSR-14, but you can't have everything...)


Lauri Alanko
la@iki.fi
0
la (473)
6/23/2004 1:42:45 PM
On Wed, 23 Jun 2004, I spy wrote:

> "Bijan Parsia" <bparsia@email.unc.edu> wrote in message
> news:Pine.A41.4.44+UNC.0406230526220.67778-100000@login2.isis.unc.edu...
> > On Wed, 23 Jun 2004, I spy wrote:
[snip]

> > Hardly. XSLT is a functional programming language. It's basically syntatic
> > uglification of DSSSL-O which is a fairly pure functional subset of
> > Scheme. It's pattern matching oriented, has single assignment, etc. etc.
> I'm having a hard time seeing how you can call XSLT a functional language.

This is getting silly:

http://www.topxml.com/xsl/articles/fp/Default.asp?printerversion=true

> Where's the higher order functions? Where's the recursive functions?

These are sorta there with pain. XSLT is crippled, no doubt. But anyway.

>  Where's
> the type classes? Where's the type inferencing? All these either
> characterize or are pretty much standard with modern day functional
> languages.
[snip]

Well, if we rule out Scheme, ok, fine. Some versions of Erlang would fail
hard too.  I'll stick with XQuery for my point. My point was that
functional and functional like programming languages and FP inspired
things have quite a bit of mindshare and it's growing fast. (XQuery is
quite the buzz at the moment.)

I notice that the person I was responding to (who made the claim that FP
had no industrial mindshare) hasn't commented (either to riposte or
concede). In any case, drop out XSLT and he's still refuted (IMHO). Put it
in, and he's refuted all the more :)

Cheers,
Bijan Parsia.

P.S., I'm not convinced by the article I pointed to above. The tact seems
a bit wrong. Anyway.

0
bparsia (12)
6/23/2004 3:38:01 PM
In article <2jt5pgF15mr7rU1@uni-berlin.de>, Brandon J. Van Every wrote:
> Patrick Philippot wrote:
>>
>>> I find the idea of trying to understand a program by "stepping
>>> through it" mind-bogglingly ill-conceived (in *any* language).
>>
>> Your opinion, not mine. In many cases you have no other choice. I
>> would even say that it's the fastest way to understand a code that is
>> not correctly documented.
> 
> Or sparsely documented.  I've certainly used this approach to understand
> other people's open source game projects.  Such projects are not too big,
> and their flow control is not too crazy.  I would say that cranking up the
> debugger is appropriate for understanding any project with a "modest main
> trunk."  A 3D device driver, for instance, may contain huge amounts of code
> but probably has a fairly modest main trunk.

I would say that debugging by stepping is chiefly used with imperative
code.  The more expression-oriented your code becomes, the less meaningful
"stepping" becomes.  c.f. John Backus's Turing Award Lecture on the von
Neumann bottleneck.

cheers,
William
0
wlovas (87)
6/23/2004 4:12:19 PM
Andreas Rossberg wrote:

> There is a difference between lexical scoping and lexical closure. All 
> remotely modern languages have the former, but only high-level languages 
> tend to have the latter.

This seems to me a matter of definition. I do not know where you got 
yours from, but for me, lexical scoping means that variable bindings are 
resolved by there lexical position, nothing more, nothing less.

The only thing that closures add to the equation are that pieces of 
program text become first-class, i.e. they can be tossed around before 
they are executed. You still expect plain old dumb lexical scoping of 
the free variables inside your code. The 2 notions are orthogonal and 
closures only add complication in guaranteeing lexical scoping.

> Imposal of restrictions on lexical closure does not turn lexical scoping 
> into dynamic scoping. Still it means that you do not have proper (full) 
> closure. 

I did not say this.

 > I agree that Java is not far away. I just consider the missing
> bit very important.

Only if you need HO-programming the way functional languages require 
you. I contest that this is the case if you are willing to make implicit 
state (e.g. destructive updates, assignments, etc.) as your default 
paradigm.

> Btw, the issue *does* arise in C++, that's why it has even more 
> arbitrary restrictions than Java (local functions may only access static 
> variables of outer scope etc.).

That is not why. The reason is that in C++ objects may be allocated on 
the stack (I don't remember when and under what circumstances, but the 
point is that C++ is more restrictive in this respect because of 
historical design decisions). Java can be more liberal because objects 
always get allocated on the heap. So, there is no problem with any of 
the fields of an outer class.

> Agreed, but this minor technical difference has major practical impact, 
> IMHO.

It does if you want to program in a functional manner. Again, Java was 
not functional, so it does not matter too much. Yet, they have inner 
classes with the necessary properties to alleviate some important and 
common cases. I agree the approach is more ad-hoc, but the discussion 
was whether closures in functional languages make them different from 
your typical OO language. Somewhere else, I wrote that it is not 
first-class functions, but the difference between binding and 
assignment. In other words, the default for a functional language is to 
have explicit state (which is threaded through your program) instead of 
implicit state, which is invisible. The latter becomes natural in the OO 
paradigm, but I totally agree that if you do not use the OO paradigm, 
explicit state leads to better programs.

>> I agree that in Smalltalk, you want to do updates on your local 
>> variables from a block. But that is mostly because Smalltalk uses 
>> blocks in a lot of places where you have specific Java mechanisms to 
>> cope with it.
> 
> 
> That is precisely my point. Why do you need these specific ad-hoc 
> mechanisms instead of a more generic approach? Because Java's support 
> for closures is not powerful enough! It can only be used for rather 
> trivial things.

No, that is not what I meant. In Smalltalk, you have to be able to write 
something like

a := 1.
10 timesRepeat [:n | a := a * n].

(I may be screwing the syntax)

Of course, if a is not lexically scoped in the block, this piece of code 
would not make sense. Now, very obviously, you write a for-loop in Java, 
which does not require the use of a block (a "lexical block" to use your 
terminology).

What is common in Java is to invoke a function with an object argument 
of, say, type A. However, instead of using the default method f in A, 
you need to override f with some locally adapted functionality. So you, 
send it an anonymous sub-"object" of A. AFAIK, you usually do not need 
access to local variables in this scenario.

So, anonymous classes as they exist today are very useful and in fact, 
by their ability to override some methods in a super-class add an 
OO-dimention that blocks do not have.

Mind you, it would be nice to also have something like blocks to 
facilitate the usage of catamorphisms and maps (instead of arbirary 
syntax extensions as is happening in Java 1.5), but that does not render 
inner classes useless.

>> I understand this, but I find it bizar to call a variable first-class. 
>  
> Why?

because it is not the variable which is being "tossed around", but the 
value that it binds. If I write

fun f () =
   let val b = fn x => x + 1 in
      b

What is first-class? The lambda bound to b or the variable b itself?

> Breaking apart, or rather decoupling, concepts is exactly what makes 
> them first class.

Hmmm... are we using the same name for the same thing? Are you saying 
that the above identifier b is 'not' a variable?

> Some rather philosphical comment: you suggest that both approaches are 
> somehow dual, but they aren't. 

Why not? If a variable in Java is final, it can (and will) exactly be 
handled as a binding in a functional language. I do not expect the 
implementations to be dual. For example, even though Java will optimize 
when a variable (or anything else for that matter) is declared final, it 
will not do the same effort as your typical ML compiler, ditto the other 
way around, although in that case, optimization is more difficult in the 
first place.

 > In ML, when you need a certain capability
> (eg. mutability) you create a value of a type that provides it. In Java, 
> that capability is always there by default, built into some other, 
> conceptionally unrelated mechanisms (functions, objects), and you need 
> sort of a "negative capability" (final) to revoke it. Maybe it's just 
> me, but I find this backwards, unnatural, and the need for negation 
> suspicious. The only reason I can see is historical accident.

No, it is not accidental (debatable) and certainly not unnatural. It is 
only unnatural if you assume explicit state for everything, which 
contradicts OO. Look at Ocaml and look at a typical OO program in Ocaml. 
The usage of refs all the time is very unnatural and arguably confusing. 
The reason is that your default assumption (state is always explicit) is 
barely maintainable because some other concepts (unrelated indeed) force 
implicit state.

Maybe one day, we will have this discussion about lazyness and 
strictness. Already today, some are arguing that lazyness is natural and 
negating them is the right thing to do. Others argue that strictness is 
natural and you need an explicit lazyness "marker".

In the end, these are all just paradigms and one need to understand the 
consequences of using one over the other. I think each has their 
benefits and drawbacks and it is, in the end, very difficult to make 
superiority claims because we do not have the resources to assess this.

What was my initial point here? Oh yes, closures. I do not think they 
constitute a unique capacity of functional languages, although they tend 
to be tremendously important.

	Simon
0
Simon
6/23/2004 5:12:03 PM
Ketil Malde <ketil@ii.uib.no> wrote in message news:<egzn6ulh3c.fsf@havengel.ii.uib.no>...

> (Does Fortran even have data structures other than arrays? :-)

Fortran has had data structures (called "derived types" (DT)) since
the 1990 standard. You can use DT's as procedure arguments and
function results, create arrays of DT's, and overload operators such
as '+'. Members of DT's can be declared public or private.

Fortran 2003 adds further support for object-oriented programming. I
believe it has single but not multiple inheritance.
0
beliavsky (2213)
6/23/2004 5:13:05 PM
In article <2jt02dF156fkdU1@uni-berlin.de>,
 "I spy" <s_nedunuri@yahoo.com> wrote:

> I don't know much about them, but have you looked at languages like O
> Haskell or Scala?

I think O'Haskell is very interesting, in an academic way,
but there isn't a practical implementation.  Even if you
reckon hugs to be a practical implementation of Haskell,
the ohugs interpreter is even older, has some extra issues
because of the way I/O is integrated into the interpreter's
dispatching, and is no longer maintained as the author has
gone on to develop Timber.  Timber is like O'Haskell with
time thrown into the mix as a sort of event source, with a
bias towards real time applications.  That's still strictly
academic too, as far as I know with only a modified ohugs
available for a working implementation.

   Donn Cave, donn@u.washington.edu
0
Donn
6/23/2004 5:50:46 PM
Simon Helsen wrote:
> Andreas Rossberg wrote:
> 

[...]

>> Agreed, but this minor technical difference has major practical 
>> impact, IMHO.
> 
> 
> It does if you want to program in a functional manner. Again, Java was 
> not functional, so it does not matter too much. Yet, they have inner 
> classes with the necessary properties to alleviate some important and 
> common cases. I agree the approach is more ad-hoc, but the discussion 
> was whether closures in functional languages make them different from 
> your typical OO language. Somewhere else, I wrote that it is not 
> first-class functions, but the difference between binding and 
> assignment. In other words, the default for a functional language is to 
> have explicit state (which is threaded through your program) instead of 
> implicit state, which is invisible. The latter becomes natural in the OO 
> paradigm, but I totally agree that if you do not use the OO paradigm, 
> explicit state leads to better programs.

I've read this paragraph about twenty times and it still makes no sense.

Here's curry in Scheme:

  	(define (curry f arg)
  	  (lambda rest (apply f arg rest)))

How do you do that in Java? If you can't, by what logic do you claim 
that it is not closures (real closures, not inner classes) that make 
programming in functional languages different?

-thant

0
thant (332)
6/23/2004 6:21:01 PM
Thant Tessman wrote:

> Here's curry in Scheme:
> 
>      (define (curry f arg)
>        (lambda rest (apply f arg rest)))

The usage of apply is specific to Scheme and has nothing to do with 
closures, so let's simplify this to

(define (curry f)
    (lambda (x) (lambda (y) (f x y))))

> How do you do that in Java? If you can't, by what logic do you claim 
> that it is not closures (real closures, not inner classes) that make 
> programming in functional languages different?

I don't think you understand what a closure is. In a functional 
language, functions are the only and main procedural mechanism and very 
light-weight. A closure, however, is not tight to functions. In 
Smalltalk, the above example would look like this

curry:f
   [:x | [:y | f value: x value: y ]].

and somewhere else you can use this as follows (assume that curry is 
defined in class B and we have an instance b of that class)

myF = [:x :y | x + t]
partResult = ((b curry: myF) value: 3)
result = partResult value: 4

(notice that value: is required because blocks are objects themselves)

Now, doing this in Java with inner classes is way more cumbersome (they 
were not designed for that - see discussion with Andreas on usage), but 
perfectly possible. You would have to make the parameter f to the method 
curry final, but I do not see any principle reason (appart from sugar) 
that this is not possible. The only problem in this particular example 
might be typing, but that has of course *nothing* to do with closures. 
Smalltalk is like Scheme dynamically typed and thus avoids the problem. 
You need parametric polymorphism, so maybe with GJ you can do it anyways.

In fact, with an approriate macro or template mechanism you can easily 
"augment" Java with a notion of (typed) Smalltalk blocks without all too 
much effort. No need to start implementing closures yourself. Again, 
there is nothing fundamental in OO languages that prohibits or even 
makes it difficult to have closures. It just happens to be not that 
widely used because OO programs are non-functional. The Java solution is 
extremely baroque, but the fact that you can reference local variables, 
parameters, etc in your inner class turns them into closures.

Notice that even in Smalltalk, where catamorphisms with blocks are 
common-place, you do not have first-class "methods" and currying is not 
considered an issue.

	Simon
0
Simon
6/23/2004 8:06:19 PM
Simon Helsen wrote:

> [...] Again, 
> there is nothing fundamental in OO languages that prohibits or even 
> makes it difficult to have closures. [...]

That wasn't the claim. The claim is that OO isn't a substitute for 
higher-order functions--that programming with HOFs is categorically 
different. That some language like Smalltalk or Dylan (or Scheme with 
the appropriate libraries) supports both OO and HOFs does not refute 
this claim. No one ever said a language couldn't be both OO and FP. And 
since all the languages we're talking about are Turing-equivalent, what 
really matters is how painful implementing something like curry has to 
be before you put it in the non-FP category (where FP implies the use of 
higher-order functions). I put Java in the non-FP category, as I'm sure 
most people do, not because Java is OO, but because it's a pain doing FP .

And the more important question, at least for me, is: If you have FP, is 
OO something you want? And it's taken me a few years to come to this 
conclusion, and it would take an essay to justify, but my answer is: 
no--at least not in any form the typical OO advocate would recognize as OO.

-thant

0
thant (332)
6/23/2004 9:16:04 PM
Thant Tessman wrote:

> That wasn't the claim. The claim is that OO isn't a substitute for 
> higher-order functions

Who was claiming that? You were saying that closures are the single-most 
defining aspect of FP and I have just shown that that is not the case. 
The single-most defining aspect is the separation of binding and 
assignment, which cannot be found in any other paradigm.

>-that programming with HOFs is categorically 
> different. That some language like Smalltalk or Dylan (or Scheme with 
> the appropriate libraries) supports both OO and HOFs does not refute 
> this claim. No one ever said a language couldn't be both OO and FP. 

But that is the point. By your definition of FP, the 2 are perfectly 
complementary because closures are very natural in OO languages like 
Smalltalk (and baroque in Java).

 > And
> since all the languages we're talking about are Turing-equivalent, what 
> really matters is how painful implementing something like curry has to 
> be before you put it in the non-FP category (where FP implies the use of 
> higher-order functions). I put Java in the non-FP category, as I'm sure 
> most people do, not because Java is OO, but because it's a pain doing FP .

I agree, except for *why* it is a pain! By looking at Smalltalk, 
everybody agrees that it is not an FPL because it does not distinguish 
between binding and assignment and relies on implicit (object) state. 
The closures in Smalltalk are very real closures and are in fact used in 
a virtually identical way in FPs (e.g. as catamorphisms). Moreover, the 
block-closures in Smalltalk are used *all over the place*. It is 
fundamentally part of the Smalltalk-way of programming OO. Without 
blocks (closures) Smalltalk would not be possible. Yet, it is not an FP, 
is it?

> And the more important question, at least for me, is: If you have FP, is 
> OO something you want? And it's taken me a few years to come to this 
> conclusion, and it would take an essay to justify, but my answer is: 
> no--at least not in any form the typical OO advocate would recognize as OO.

That is another story altogether.

	Simon
0
Simon
6/23/2004 9:51:54 PM
Thant Tessman wrote:
> Brandon J. Van Every wrote:
>
>> There's no way I could consult SML/NJ with the kind of web presence
>> it currently has.  Any manager would take one look at those webpages
>> and flee in terror. [...]
>
> What kind of manager decides on a programming language based on a web
> page?

All of them.  And broadly speaking, they decide based on constellations of
webpages.

-- 
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
6/23/2004 10:29:31 PM
Stefan Axelsson wrote:
> Brandon J. Van Every wrote:
>> Fortunately for me personally,
>> I had enough problems with Python itself to walk away from it.  It
>> really isn't the right technology for what I want to do.  It may be
>> in 3 to 5 years though, when they've sped it up.
>
> Have you tried Psyco? (http://psyco.sourceforge.net/) It made Python
> fast enough for my interactive visualisations (that admittedly aren't
> game related).

A friend of mine has.  It brings performance improvements, but not to the
level of efficiently compiled languages.  You simply can't make a silk purse
out of a sow's ear.

-- 
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
6/23/2004 10:33:29 PM
Simon Helsen wrote:

> [...] You were saying that closures are the single-most
> defining aspect of FP and I have just shown that that is not the case. 

You've shown no such thing. You've shown that, given HOFs as the 
defining characterist of FP languages, there are programming languages 
that are both OO and FP.  I know Dylan is an example of just such a 
language. If I understand your example, so is Smalltalk.


> The single-most defining aspect is the separation of binding and 
> assignment, which cannot be found in any other paradigm.

Before this thread started, I thought I knew what those words meant. C++ 
distinguishes between binding and assignment. Certainly you don't 
consider it a functional language?

-thant

0
thant (332)
6/23/2004 10:58:17 PM
Matthias Blume wrote:
{stuff deleted}
> 
> You are being extremely unfair, and you know it.  What "fiasco"?  What
> "stupidities"?  Be glad John and (I believe) Emden are not reading
> netnews, otherwise a big, serious apology would be in order.  And by
> this I don't mean:

They can't ship a tarball of the webpages because of the copyright issues 
with the publisher. An API that I can't get in electronic form is absolutely 
useless. The Basis should be a living document not a dead tree that has been 
in production for way too long than it need to be.

They didn't need to publish a book. They need to get all the ML 
implementations on board and agree to stay in sync, which these days isn't 
the case. In fact an automated test suite that checked for compliance with 
some crappy HTML webpages would have been by far easier to get out the door 
into the real world and been far more useful. However, they went for the 
dead tree approach. In fact it seems the goal of the whole Basis exercise 
has been aimed at getting a book out the door rather than being useful. That 
at least is my perspective.

{stuff deleted}
> In short, I don't care if SML or Haskell or even OCaml or Clean or ...
> will die -- as long as some of the better ideas that went into their
> design make it into future languages and as long as the worst ideas
> survive as warnings for future designers.  In this sense the Algol
> analogy is probably true -- and no reason for being ashamed.

If you have that attitude then any seriously pragmatic developer will not 
dare bet a project on SML/NJ with every good rational reason not too. If you 
don't care about building a base, then why continue working and doing 
mantaince on SML? There are much more intellectually interesting problems to 
tackle. If it really is simply a fun hobby then fine. If it really is just a 
hobby then the owners should abandon control and move on. I suspect after 
the mythical "next offical release" happens that is exactly what will happen.

Anyway, you basically seem to agree with me about the philosophy of 
development that is being used and mostly agree with the long term outcomes 
of such a result. If SML/NJ developers are happy with the outcomes of SML 
becoming "the next Algol" then great.. I only want to make clear that in 
some ways Algol was a wild success by other metrics it was a complete failure.

Just don't develop and attitude when other people using different metrics 
make valid complaints about SML/NJ this particularly irrked me.

In any case, I did not intend for you to feel stabbed in the back.. stabbed 
in the front perhaps but not in the back... :)

BTW First there was MINIX the wonderful jewel of an OS created by a great 
academic and published as a book. Then this silly grad student ignoring all 
that wonderful academic jewelry wrote something to be useful. I personally 
do not buy into ESRs explination of everything, but I can see the pattern of 
  how academic research gets developed and "deployed". I understand the 
reward models of research environments and pretty much certain this failure 
of research to have direct impact on day to day practice is a systematic 
faliure.
0
danwang742 (171)
6/24/2004 6:36:15 AM
Bijan Parsia wrote:
{stuff deleted}
> Hardly. XSLT is a functional programming language. It's basically syntatic
> uglification of DSSSL-O which is a fairly pure functional subset of
> Scheme. It's pattern matching oriented, has single assignment, etc. etc.

XSLT and DSSL are more in the model of attribute grammars in their design. 
(Yet another dead academic fad of the past...)


> XQuery has a nicer syntax and an interesting type system etc. etc.

XQuery arguebly is more of a modern functional design...

0
danwang742 (171)
6/24/2004 6:41:29 AM
Brandon J. Van Every wrote:

> So which is the easier problem?  Getting SML guys to form a viable language
> community, or getting the OCaml implementors to fix their broken integer
> representation, add 32-bit float support, and clean up the C FFI?  Talk
> about a rock and a hard place!  I think I'm just going to get drunk with
> whomever's in Seattle until the answer reveals itself.

Switch to MLton... www.mlton.org the main developer is being contracted by a 
n unamed company so that said company can ship a product. (Okay, so it is a 
static analysis tool... but... still it is a comercial product...)

Of course MLton has it's own down sides, but if somone put a gun to my head 
and asked me to deliver at 100kloc program in SML for a product I would 
personally use MLton.
0
danwang742 (171)
6/24/2004 6:47:20 AM
Brandon J. Van Every wrote:

> A friend of mine has.  It brings performance improvements, but not to the
> level of efficiently compiled languages.  You simply can't make a silk purse
> out of a sow's ear.

I'm not quite sure what that means (the 'ear' thing I mean). If you're 
saying that there's something in Python that precludes efficient 
compilation by a runtime compiler I don't agree.

Statically it's difficult to compile Python, no argument there. However 
as a runtime compiler has the possibility of taking runtime knowledge 
into account they have at least the possibility of producing better code 
  than a static compiler even if Psyco itself may not be there just yet, 
so that's no disadvantage (given sufficient overall runtime that is).

Stefan,
-- 
Stefan Axelsson  (email at http://www.cs.chalmers.se/~sax)
0
crap1234 (43)
6/24/2004 8:49:42 AM
On Sun, 20 Jun 2004 13:41:14 -0600, Thant Tessman <thant@acm.org>
wrote:

>
>Also, I will add that what SML gives me that neither Scheme nor C++ has 
>given me is a type system so well-designed that if a program compiles, 
>it very likely just works. This may be contradicted by the experiences 
>of Patrick Philippot, but the whole concept of SML .net hurts my brain.

In OCaml ( close enough for the same rule to apply )

let sq x= x * x *x;;

let do_sq x=
    let sq_x= sq_x in
        begin
          print_string "The square of ";
          print_int      x;
          print_string " is ";
          print_int      sq_x;
          print_string ".";
          print_newline ()
        end;;

map do_sq [1;2;3;4;5];;

is going to produce the wrong answer.

If you talk with "extreme programmers" they will 
bombard you with dogma that 	 type systems are unnecessary
and that unit tests work better and catch more, while
giving you the freedom of a typeless system.

I am not enamoured with "extreme programmers", and would
say that I prefer languages with type systems, because they do
eliminate many errors. However, it is foolish to say ( or imply )
that type systems eliminate all or almost all errors eg when
saying "a type system so well-designed that if a program compiles, 
it very likely just works". All that really says is that you are not
writing really complex systems where other types of errors creap in.
         



The reply-to email address is olczyk2002@yahoo.com.
This is an address I ignore.
To reply via email, remove 2002 and change yahoo to
interaccess,

**
Thaddeus L. Olczyk, PhD

There is a difference between
*thinking* you know something,
and *knowing* you know something.
0
olczyk2002 (317)
6/24/2004 9:55:44 AM
Simon Helsen wrote:
> 
> The single-most defining aspect is the separation of binding and 
> assignment, which cannot be found in any other paradigm.

Not true, Algol-68 had it, modulo some syntactic sugar. Although it was 
quite ahead of its time with respect to "functionality", it was clearly 
an imperative language.

> But that is the point. By your definition of FP, the 2 are perfectly 
> complementary because closures are very natural in OO languages like 
> Smalltalk (and baroque in Java).

I maintain that Java, unlike Smalltalk, does not meet the requirements.

Anyway, I agree that the presence of 1st-class functions alone is not 
the defining factor of FPLs. IMHO, it is their ease of use and the 
central role they play that - along with the deprecation of mutability - 
defines FP.

This is not a sharp definition, but I don't think there can be one. Same 
goes for OO, by the way.

	- Andreas

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

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

0
rossberg (600)
6/24/2004 9:56:32 AM
TLOlczyk <olczyk2002@yahoo.com> writes:

>> Also, I will add that what SML gives me that neither Scheme nor C++ has 
>> given me is a type system so well-designed that if a program compiles, 
>> it very likely just works

I think we have to stop saying this. :-)

> let sq x= x * x *x;;

> If you talk with "extreme programmers" they will 
> bombard you with dogma that 	 type systems are unnecessary
> and that unit tests work better and catch more, while
> giving you the freedom of a typeless system.

I think we perhaps should describe (H-M) type systems as giving you
unit tests for free - tests that the are proven instead of run.  They
don't replace all other testing, but at least they can do a lot of the
tedious stuff for you.

I also think that the kind of HOF juggling that is fairly common in FP
languages like Haskell is going to be very difficult to get right
without a decent type system.

-kzm
-- 
If I haven't seen further, it is by standing in the footprints of giants
0
ketil (99)
6/24/2004 10:15:07 AM
Simon Helsen wrote:
> 
>> There is a difference between lexical scoping and lexical closure. All 
>> remotely modern languages have the former, but only high-level 
>> languages tend to have the latter.
> 
> This seems to me a matter of definition. I do not know where you got 
> yours from, but for me, lexical scoping means that variable bindings are 
> resolved by there lexical position, nothing more, nothing less.

That's mine too, so I was quite confused when you somehow seemed to 
suggest that it implies lexical closure. Maybe I misinterpreted your 
writing.

>> Btw, the issue *does* arise in C++, that's why it has even more 
>> arbitrary restrictions than Java (local functions may only access 
>> static variables of outer scope etc.).
> 
> That is not why. The reason is that in C++ objects may be allocated on 
> the stack (I don't remember when and under what circumstances, but the 
> point is that C++ is more restrictive in this respect because of 
> historical design decisions).

You confuse me again.  Of course, C++ objects are allocated on the stack 
(by default). That's why C++ severely restricts lexical closure. We seem 
to agree on that. But how can you say that "the issue does not arise in 
C++" then?? (the issue being implementability of closures).


>> That is precisely my point. Why do you need these specific ad-hoc 
>> mechanisms instead of a more generic approach? Because Java's support 
>> for closures is not powerful enough! It can only be used for rather 
>> trivial things.
> 
> No, that is not what I meant. In Smalltalk, you have to be able to write 
> something like
> 
> a := 1.
> 10 timesRepeat [:n | a := a * n].
> 
> (I may be screwing the syntax)
> 
> Of course, if a is not lexically scoped in the block, this piece of code 
> would not make sense. Now, very obviously, you write a for-loop in Java, 
> which does not require the use of a block (a "lexical block" to use your 
> terminology).

Yes, but I think you are not acknowledging cause and effect properly. 
You say the restrictions on closures are not a problem in Java because 
it has other mechanisms, e.g. for looping. But it's the other way round: 
Java needs ad-hoc constructions like loops, because of the problem of 
closures grossly lacking expressiveness (or not existing at all in the 
beginning). For loops just address the most pressing need, but are 
barely a scalable replacement.

> What is common in Java is to invoke a function with an object argument 
> of, say, type A. However, instead of using the default method f in A, 
> you need to override f with some locally adapted functionality. So you, 
> send it an anonymous sub-"object" of A. AFAIK, you usually do not need 
> access to local variables in this scenario.

That is Java's workaround for the situations not covered by builtin 
loops and the like. In my book, it clearly qualifies as doing closures 
by hand. If you are willing to do that, and even find it natural or 
satisfying, then of course, you won't need real builtin closures.

But I find that workaround so incredibly cumbersome that moving the 
inner class you use for it out of the function wouldn't really make a 
significant difference anymore. That's why I said they are *almost" useless.

>>> I understand this, but I find it bizar to call a variable first-class. 
>>  
>> Why?
> 
> because it is not the variable which is being "tossed around", but the 
> value that it binds. If I write
> 
> fun f () =
>   let val b = fn x => x + 1 in
>      b
> 
> What is first-class? The lambda bound to b or the variable b itself?

There is no variable (in the imperative sense).

> Hmmm... are we using the same name for the same thing? Are you saying 
> that the above identifier b is 'not' a variable?

Right, at least not in the sense of imperative programming. To avoid 
confusion, I prefer to call it an identifier.

The imperative paradigm, out of historical accident and to provide some 
superficial convenience, just couples these two completely orthogonal 
concepts of identifier and mutable variable.

Cheers,

	- Andreas

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

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

0
rossberg (600)
6/24/2004 11:31:31 AM
Ketil Malde wrote:

> Adrian Hey <ahey@NoSpicedHam.iee.org> writes:
>> Taken at face value this statement would appear support the allegations
>> of functional programs suffering from maintainability problems typical of
>> "legendary spaghetti code" with "hierarchical dependency".
> 
> I'm sorry, but IMHO spaghetti is the opposite of structured -
> spaghetti is when the control flow jumps arbitrarily around in code.
> SP was trying to fix this by not letting you do that (GOTO considered
> harmful etc).

I would agree, this is what I assumed folk usually mean by spaghetti,
but what Mr. X (the unnamed citizen of comp.object, critcial of FP)
means by spaghetti is (AFAICT) the opaque and subtle dependencies
that often result from shared mutable state (which is indeed a problem
IMO in all imperative languages, even those of the structured or OO
variety).

BTW, I never considered GOTO harmful, and as frequent assembler hacker
you'll never catch me writing..
        CALL BLAH
        RET
when..
        JUMP BLAH
will do the job just as well (better in fact). But I guess I always
did think like an FP'er and came to realise that GOTO is just a poor
mans tail call, and "spaghetti" loops were just poor mans tail recursion.
(Nothing to be ashamed of if you're forced to use a language that doesn't
deal with tail calls properly.)
 
> Please elaborate!

Not sure what you want be to elaborate on, but I guess it's why I don't
think FP and structured programming in an imperative language are
comparable. Well I'll try to cut a very long story short.

It's all to do with the evils of "heirarchical dependency" that Mr. X
objects to (with some justification I think). In an imperative language
notfunctions typically have state dependency and state mutating obligations,
and typically (in a good design) the state is only accessible via other
notfunctions. But even in a good design this still leads to the problem
that the specification for a notfunction typically mandates the use of
other notfunctions in the implementation. This can make programs hard to
maintain, especially in situations where changes to program requirements
and design may render the state dependence and mutation obligations some
existing notfunctions inappropriate. It's hard to identify what those
notfunctions are, and hard to modify them so they are appropriate for
the new design. This is what I believe Mr. X means by "spaghetti".

This dependency problem is further exacerbated by the lame or non-existant
parameterisation capabilities of languages typically used in structured
programming.

Superficially FP seems similar, but IMO the big differences in FP are:
* Powerful parameterisation capabilities which make it easy to apply
  what OO folk refer to as "dependency inversion".
* Dependency is explict. The result delivered by a function is dependent
  only on the arguments.
* The only obligation a function has is to deliver a correct result
  (according to some specification). The specification doesn't require that
  the function implementation uses any other particular function. (Any
  implementation which complies with the specification will do just as
  well, in the sense that there's no danger of breaking other parts of
  the program).
* And of course there's closures too (yippee! gotta mention closures :-)

Typically, in the course of program maintainance (meeting new requirements),
you don't change either the specifications or implementations of existing
functions at all. The exception to this the top level main or equivalent,
because changes to program specification are ultimately changes to the
specification main. You may define new functions to support the new
main (the implementations of which will often reuse existing functions),
and the changes may render some existing functions obsolete.

But there's no need to change existing functions. Of course pragmatism
creeps in and in reality, rather defining a new function and obsoleting
an old one, you sometimes take a shortcut and actually modify an existing
function instead, but only if it would be obsoleted otherwise (main being
the obvious example of this).

Sorry if this seems like a lecture, I would have thought all this doesn't
really need to be said on c.l.f. But you did ask :-)

Regards
--
Adrian Hey

0
ahey (217)
6/24/2004 12:16:08 PM
TLOlczyk wrote:

[...]

> [...] However, it is foolish to say ( or imply )
> that type systems eliminate all or almost all errors eg when
> saying "a type system so well-designed that if a program compiles, 
> it very likely just works". All that really says is that you are not
> writing really complex systems where other types of errors creap in.

If this sounds like an exaggeration, replace "it very likely just works" 
with "in my experience it is more likely to work than it would be had it 
been written in any other programming language I've worked with." (C, 
C++, Scheme, Basic (of various flavors), a much smaller amount of Java, 
Pascal, Fortran, COBOL.) And the more complex the task, the more this 
claim applies.

-thant

0
thant (332)
6/24/2004 1:07:58 PM
Adrian Hey <ahey@NoSpicedHam.iee.org> writes:

>> Please elaborate!

> Not sure what you want be to elaborate on, but I guess it's why I don't
> think FP and structured programming in an imperative language are
> comparable. Well I'll try to cut a very long story short.

Yes.  (Or rather, why designing FP programs aren't closer to structured
program design than to object oriented design, which was what I so
ineffectively was trying to communicate. :-)

All those years ago, I wrote programs starting out with:

    procedure Task(..)

then I added

    begin
        do_subtask1
        subtask_2
    end

Now I find I write programs starting with

    main_function = task 

adding 

       where task = subtask2 . subtask1

and so on.  The top-down design is similar, and the flow of the
processing in the resulting program remains linear.  Contrast this 
with OO design, where you design objects, and later perform task by
designing patterns of interaction between them.  You can still do
top-down, although I think it would be less common, and focusing on
the hierarchical composition of objects from other objects.

(I'm probably grossly misrepresenting OO design again :-).

> It's all to do with the evils of "heirarchical dependency" that Mr. X
> objects to (with some justification I think).

So it seems that Mr. X is opposed to mutable state - while I'm happy
to agree with that point of view, I don't quite see how that makes him
opposed to FP.  If c.l.f. wasn't using up all my time, I'd hang around
in c.o. to find out :-)

> Superficially FP seems similar, but IMO the big differences in FP are:

(I knew that, of course.)

> But there's no need to change existing functions.

So in a sense, you not only have immutable data, but also immutable
functions.  Never considered that :-)

> Sorry if this seems like a lecture

Not at all - I don't mind being lectured, who knows, I might even
learn something.

-kzm
-- 
If I haven't seen further, it is by standing in the footprints of giants
0
ketil (99)
6/24/2004 2:00:53 PM
"Joachim Durchholz" <jo@durchholz.org> wrote in message
news:cb94ro$3m6$1@news.oberberg.net...
> Brandon J. Van Every wrote:
>
> > Also I'm not sure if Erlang is proving something about Functional
> > languages or *Concurrent* languages.
>
> Both.
> Erlang is functional when programming-in-the-small and concurrent when
> programming-in-the-large.
>
> One interesting information that's been repeated several times is that
> some internal Ericsson statistics said that a line of Erlang is roughly
> equivalent to five lines of C. (Try googling for "productivity
> site:erlang.org" (without the quotes).)
> There's also a quote about the software in the Ericsson AXP line of
> telephony switches. I may have gotten the numbers mixed up so please
> check before you quote me, but it was something around the lines of
> "100,000 lines of Erlang, 100,000 lines of C, 80% of the functionality
> is done in the Erlang parts".
>
> Of course, all of these numbers have a fat "YMMV" tag on them, but even
> then the numbers are impressive. Even sub-average programmers seem to
> multiply their productivity when they switch to Erlang (at least that's
> what I read between the lines).
>
> Personally, I think a large part of these effects is due to Erlang's
> support for automatic garbage collection, together with a system that
> "just works out of the box".
>
> The functional stuff is still great for factoring out commonalities -
> far less syntactic excess than with OO methodology in fact. I attribute
> that to the fact that you need tons of syntax to factor out a single
> line of code into a superclass, while a single-line function declaration
> may be fully sufficient (both technically and documentation-wise) in an
FPL.
> Of course, this kind of advantage really matters only when you have
> started to use the approach on a larger scale, and at that point most
> people are already committed and couldn't reverse the decision even if
> they wanted to. That's why the FP arguments sound like every other
> hype... even if it's true. (I'm pretty sure that FP isn't the end-all of
> design-in-the-large, but it's the best technology that I know about.
> (Well, famous last words... *gg*))
Yes and No. There are certain things that are easier in FP than in a typical
OO language, but the same could be said vice versa too. It depends on which
paradigm you're coming from. So I think that's a bit of a wash. I do agree
that the functional approach is probably more productive, but not for the
reasons you outlined. Rather I think it has to do with the techniques that
are used to improve productivity and correctness, the chief among these
being DbC (Design by Contract) which is a proven technique for getting your
programs more likely to be right the first time. This naturally saves time
and therefore improves productivity. But when you look at DbC contracts, for
anything but the simplest contracts you'll often find the postcondition
essentially "recalculating" what was done in the body of the loop. Therefore
in a way you end up writing the code twice. (which is why DbC often slows
down initial development even though it improves overall productivity
through reduced and easier debugging). Now with declarative languages (that
is, functional and logic) that second writing is not necessary. Why? Because
the first writing (the contract) *is* the executable form. Of course, you're
now relying on the compiler to extract out the efficient form which has
historically been a weak point of declarative languages, although that is
begining to change

cheers
-sri

> Regards,
> Jo


0
s_nedunuri (52)
6/24/2004 3:37:45 PM
"TLOlczyk" <olczyk2002@yahoo.com> escreveu na mensagem
news:mj8ld050cqet6nl0o536j8mtqk69rqv4fp@4ax.com...
> On Sun, 20 Jun 2004 13:41:14 -0600, Thant Tessman <thant@acm.org>
> wrote:
>
> >
> >Also, I will add that what SML gives me that neither Scheme nor C++ has
> >given me is a type system so well-designed that if a program compiles,
> >it very likely just works. This may be contradicted by the experiences
> >of Patrick Philippot, but the whole concept of SML .net hurts my brain.
>
> In OCaml ( close enough for the same rule to apply )
>
> let sq x= x * x *x;;
>
> let do_sq x=
>     let sq_x= sq_x in
>         begin
>           print_string "The square of ";
>           print_int      x;
>           print_string " is ";
>           print_int      sq_x;
>           print_string ".";
>           print_newline ()
>         end;;
>
> map do_sq [1;2;3;4;5];;
>
> is going to produce the wrong answer.

The funny thing is that when I wrote your example in Haskell the compiler
complained because the let binding "sq_x" is ambiguous ;-)

> If you talk with "extreme programmers" they will
> bombard you with dogma that type systems are unnecessary
> and that unit tests work better and catch more, while
> giving you the freedom of a typeless system.
>
> I am not enamoured with "extreme programmers", and would
> say that I prefer languages with type systems, because they do
> eliminate many errors. However, it is foolish to say ( or imply )
> that type systems eliminate all or almost all errors eg when
> saying "a type system so well-designed that if a program compiles,
> it very likely just works". All that really says is that you are not
> writing really complex systems where other types of errors creap in.

Let me say a few things:

- Thant said "...type system so well-designed that if a program compiles, it
very likely just works" not "the type system catches all errors". Very
likely is way different from no errors at all.
- It's always possible to write programs that are semantically wrong but are
type-checked if you aren't encoding the semantics in the types (e.g.
dependent types), so this is a moot point.
- In these type-systems you can (and should) use the type-system to encode
your abstractions (e.g. using folds instead of explicit recursion) and doing
so the compiler will catch more errors for you (trivial and non-trivial).
Instead of writing complex systems using simple types functional programmers
use complex types (i.e. Typeful programming) that can be type-checked. For
example is known that many properties can be automatically derived from the
types of expressions (Google for "Theorems for free!"), using sofisticated
types is no exception to this rule.

> The reply-to email address is olczyk2002@yahoo.com.
> This is an address I ignore.
> To reply via email, remove 2002 and change yahoo to
> interaccess,
>
> **
> Thaddeus L. Olczyk, PhD

Daniel Yokomizo.


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.708 / Virus Database: 464 - Release Date: 18/6/2004

0
6/24/2004 3:45:39 PM
Ketil Malde wrote:

> Adrian Hey <ahey@NoSpicedHam.iee.org> writes:
> So it seems that Mr. X is opposed to mutable state - while I'm happy
> to agree with that point of view, I don't quite see how that makes him
> opposed to FP.  If c.l.f. wasn't using up all my time, I'd hang around
> in c.o. to find out :-)

No, Mr. X embraces mutable state. Though I think his real objection is
to "heirarchcal dependency" coupled with mutable state, he insists this
is not the case. Hierarchical dependency is a bad thing in it's own right
(allegedly).

But I (and every other FPer who participated in the last flame war on
this topic) find this position incomprehensible. How can you have
reuse without introducing (hierarchical) dependency?

IMO big difference (for maintainance) between FP and stateful structured
programming is that in FP the dependence is one of implementation only,
and I can freely change the dependencies if I like by producing
alternative function implementations which still comply with the same
specification.

In stateful structured programming I'm not free to do this unless I
have a complete understanding of the state dependencies and mutation
obligations of the various notfunctions that are currently used in
by the notfunction I'm trying to modify. So in effect the specification
for a notfunction really is defined by what other notfunctions the
current implementation happens to use.

But in FP the specification is independent. It is only whether or
not the current implementation is correct that is dependent on
(the correctness of) whatever functions the current implementation
uses.

Hope that makes some kind of sense. On re-reading this I have to confess
it looks like the kind of gobbledygook Mr. X himself posts :-)

Sorry 'bout that.

Regards
--
Adrian Hey 

0
ahey (217)
6/24/2004 4:07:41 PM
Hi Andreas,

I think overall we agree (module some minuscul points, but we are 
converging - I have the impression that terminology was an issue). I 
have no more time to go into it, but I learned from the discussion. Thanks!

	Simon

Andreas Rossberg wrote:

> Simon Helsen wrote:
> 
>>
>>> There is a difference between lexical scoping and lexical closure. 
>>> All remotely modern languages have the former, but only high-level 
>>> languages tend to have the latter.
>>
>>
>> This seems to me a matter of definition. I do not know where you got 
>> yours from, but for me, lexical scoping means that variable bindings 
>> are resolved by there lexical position, nothing more, nothing less.
> 
> 
> That's mine too, so I was quite confused when you somehow seemed to 
> suggest that it implies lexical closure. Maybe I misinterpreted your 
> writing.
> 
>>> Btw, the issue *does* arise in C++, that's why it has even more 
>>> arbitrary restrictions than Java (local functions may only access 
>>> static variables of outer scope etc.).
>>
>>
>> That is not why. The reason is that in C++ objects may be allocated on 
>> the stack (I don't remember when and under what circumstances, but the 
>> point is that C++ is more restrictive in this respect because of 
>> historical design decisions).
> 
> 
> You confuse me again.  Of course, C++ objects are allocated on the stack 
> (by default). That's why C++ severely restricts lexical closure. We seem 
> to agree on that. But how can you say that "the issue does not arise in 
> C++" then?? (the issue being implementability of closures).
> 
> 
>>> That is precisely my point. Why do you need these specific ad-hoc 
>>> mechanisms instead of a more generic approach? Because Java's support 
>>> for closures is not powerful enough! It can only be used for rather 
>>> trivial things.
>>
>>
>> No, that is not what I meant. In Smalltalk, you have to be able to 
>> write something like
>>
>> a := 1.
>> 10 timesRepeat [:n | a := a * n].
>>
>> (I may be screwing the syntax)
>>
>> Of course, if a is not lexically scoped in the block, this piece of 
>> code would not make sense. Now, very obviously, you write a for-loop 
>> in Java, which does not require the use of a block (a "lexical block" 
>> to use your terminology).
> 
> 
> Yes, but I think you are not acknowledging cause and effect properly. 
> You say the restrictions on closures are not a problem in Java because 
> it has other mechanisms, e.g. for looping. But it's the other way round: 
> Java needs ad-hoc constructions like loops, because of the problem of 
> closures grossly lacking expressiveness (or not existing at all in the 
> beginning). For loops just address the most pressing need, but are 
> barely a scalable replacement.
> 
>> What is common in Java is to invoke a function with an object argument 
>> of, say, type A. However, instead of using the default method f in A, 
>> you need to override f with some locally adapted functionality. So 
>> you, send it an anonymous sub-"object" of A. AFAIK, you usually do not 
>> need access to local variables in this scenario.
> 
> 
> That is Java's workaround for the situations not covered by builtin 
> loops and the like. In my book, it clearly qualifies as doing closures 
> by hand. If you are willing to do that, and even find it natural or 
> satisfying, then of course, you won't need real builtin closures.
> 
> But I find that workaround so incredibly cumbersome that moving the 
> inner class you use for it out of the function wouldn't really make a 
> significant difference anymore. That's why I said they are *almost" 
> useless.
> 
>>>> I understand this, but I find it bizar to call a variable first-class. 
>>>
>>>  
>>> Why?
>>
>>
>> because it is not the variable which is being "tossed around", but the 
>> value that it binds. If I write
>>
>> fun f () =
>>   let val b = fn x => x + 1 in
>>      b
>>
>> What is first-class? The lambda bound to b or the variable b itself?
> 
> 
> There is no variable (in the imperative sense).
> 
>> Hmmm... are we using the same name for the same thing? Are you saying 
>> that the above identifier b is 'not' a variable?
> 
> 
> Right, at least not in the sense of imperative programming. To avoid 
> confusion, I prefer to call it an identifier.
> 
> The imperative paradigm, out of historical accident and to provide some 
> superficial convenience, just couples these two completely orthogonal 
> concepts of identifier and mutable variable.
> 
> Cheers,
> 
>     - Andreas
> 
0
Simon
6/24/2004 4:58:48 PM
Daniel C. Wang wrote:
>
> BTW First there was MINIX the wonderful jewel of an OS created by a
> great academic and published as a book. Then this silly grad student
> ignoring all that wonderful academic jewelry wrote something to be
> useful. I personally
> do not buy into ESRs explination of everything, but I can see the
>   pattern of how academic research gets developed and "deployed". I
> understand the
> reward models of research environments and pretty much certain this
> failure of research to have direct impact on day to day practice is a
> systematic faliure.

Well in fairness, SML/NJ is BSD-style licensed.  Anyone could take it and
run with it.

-- 
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
6/24/2004 6:18:49 PM
Stefan Axelsson wrote:
> Brandon J. Van Every wrote:
>
>> A friend of mine has.  It brings performance improvements, but not
>> to the level of efficiently compiled languages.  You simply can't
>> make a silk purse out of a sow's ear.
>
> I'm not quite sure what that means (the 'ear' thing I mean). If you're
> saying that there's something in Python that precludes efficient
> compilation by a runtime compiler I don't agree.

Show me the benchmarks.

> Statically it's difficult to compile Python, no argument there.

That's why it's going to take 3 to 5 years for it to become a good language,
from a performance standpoint.

-- 
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
6/24/2004 6:20:01 PM
Daniel C. Wang wrote:
> Brandon J. Van Every wrote:
>
>> So which is the easier problem?  Getting SML guys to form a viable
>> language community, or getting the OCaml implementors to fix their
>> broken integer representation, add 32-bit float support, and clean
>> up the C FFI?  Talk about a rock and a hard place!  I think I'm just
>> going to get drunk with whomever's in Seattle until the answer
>> reveals itself.
>
> Switch to MLton... www.mlton.org the main developer is being
> contracted by a n unamed company so that said company can ship a
> product. (Okay, so it is a static analysis tool... but... still it is
> a comercial product...)
>
> Of course MLton has it's own down sides, but if somone put a gun to
> my head and asked me to deliver at 100kloc program in SML for a
> product I would personally use MLton.

My understanding is that MLton only does whole program compilation, i.e. you
can't compile individual modules.  I don't see how you would be able to
stand the compile times for a 100kloc program?

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

"Trollhunter" - (n.) A person who habitually accuses
people of being Trolls.



0
6/24/2004 7:21:30 PM
In article <mj8ld050cqet6nl0o536j8mtqk69rqv4fp@4ax.com>, TLOlczyk wrote:
> If you talk with "extreme programmers" they will 
> bombard you with dogma that 	 type systems are unnecessary
> and that unit tests work better and catch more, while
> giving you the freedom of a typeless system.

I've always thought this was hogwash -- the "freedom" of a typeless system
is the freedom to write buggy code.  That is, i've never felt constrained
by a type system -- when the typechecker complains, it's a bug in my
program, and i'm happy to have found out at compile time rather than
(maybe) at run time.

> I am not enamoured with "extreme programmers", and would
> say that I prefer languages with type systems, because they do
> eliminate many errors. However, it is foolish to say ( or imply )
> that type systems eliminate all or almost all errors eg when
> saying "a type system so well-designed that if a program compiles, 
> it very likely just works". All that really says is that you are not
> writing really complex systems where other types of errors creap in.

Bottom line: functional programmers have noticed that when their code
typechecks, it tends to be correct.  This doesn't mean that the type system
prevents them from writing buggy code -- it just means that a typeful
development methodology tends to lead to correct code relatively quickly.
There are many subtle reasons for this assertion, but they're difficult to
articulate succinctly, so functional programmers just keep observing that
when their code typechecks, it tends to be correct... and antagonists keep
mistinterpreting it.

Sigh...

William
0
wlovas (87)
6/24/2004 8:01:14 PM
William Lovas wrote:

> Bottom line: functional programmers have noticed that when their code
> typechecks, it tends to be correct.  This doesn't mean that the type system
> prevents them from writing buggy code -- it just means that a typeful
> development methodology tends to lead to correct code relatively quickly.
> There are many subtle reasons for this assertion, but they're difficult to
> articulate succinctly, so functional programmers just keep observing that
> when their code typechecks, it tends to be correct... and antagonists keep
> mistinterpreting it.

let's put this myth out of the world. My functional programs then to be 
correct because of the functional paradigm (whatever that means - see 
other thread) and minimally so because of the type system. I am not an 
antagonist and have extensive experience with functional programming, 
but this notion of "I wrote my program and when it compiled, it just 
worked!" is only mildly related to the type system. In fact, in writing 
fairly large pieces of SML code, I noticed that when I could compile, 
the remaining (and often very subtle) bugs in my code almost always 
pointed back to the usage of non-functional programming features such as 
imperative datastructures (sometimes required for efficiency's sake).

	Simon

> 
> Sigh...
> 
> William

-- 
-- Simon Helsen, Ph.D.
-- Dep. of Electrical and Computer Engineering
-- University of Waterloo, Canada
-- http://www.helsen.org
0
Simon
6/24/2004 10:57:38 PM
"Adrian Hey" <ahey@NoSpicedHam.iee.org> wrote in message
news:ZsadncOm2-DFYEfdRVn-jw@nildram.net...
> Ketil Malde wrote:
>
> > Adrian Hey <ahey@NoSpicedHam.iee.org> writes:
> > So it seems that Mr. X is opposed to mutable state - while I'm happy
> > to agree with that point of view, I don't quite see how that makes him
> > opposed to FP.  If c.l.f. wasn't using up all my time, I'd hang around
> > in c.o. to find out :-)
>
> No, Mr. X embraces mutable state. Though I think his real objection is
> to "heirarchcal dependency" coupled with mutable state, he insists this
> is not the case. Hierarchical dependency is a bad thing in it's own right
> (allegedly).
>
> But I (and every other FPer who participated in the last flame war on
> this topic) find this position incomprehensible. How can you have
> reuse without introducing (hierarchical) dependency?
I think I can hazard a guess as to who Mr X is - or at least - he sounds
remarkably like another individual I know from another newsgroup. I happen
to agree with his basic argument, So I'll stick my neck out a bit and try
and see if I can justify his position. Basically what this other guy often
rails against is top down problem decomposition. That is if I know I need to
compute F, I break F down into a series of subfunctions, which are firther
recursively decomposed until you have a bunch of leaf functions that are (in
theory) a cinch to write. Fine, except you now also have a whole tree of
dependencies. Change your root function F and potentially every leaf
function is affected. OO inverts that dependency. That is you have a group
of interacting top level classes. The top level classes may have subclasses,
but these subclasses are not visible to other top level classes. So you now
have a log linear # of dependencies instead of a quadratic # with standard
functional decomp. Through the use of patterns such as the Template Method,
you can use the subclasses to refine what is computed by the top level
classes, *without* introducing dependencies. Of course you can only do this
if you have subtype polymorphism of the kind found in OO languages. It is
difficult to carry out in a standard functional language, even with type
classes and type class inheriance and all that.

Incidentally, you can further decouple the dependencies by making the
invocation implicit. Instead of telling that other object what to do, a
method
sends an event to another object to say its done. That other object is free
to respond with whatever method is most appropriate. In this way you have
fairly limited the dependency structure

cheers
-sri


0
s_nedunuri (52)
6/24/2004 11:07:40 PM
Simon Helsen wrote:
> William Lovas wrote:
> 
>> Bottom line: functional programmers have noticed that when their code
>> typechecks, it tends to be correct.  [...]
> 
> 
> let's put this myth out of the world. My functional programs then to be 
> correct because of the functional paradigm (whatever that means - see 
> other thread) and minimally so because of the type system. [...]

Except that when I attribute this quality to SML's type system, I do so 
based on (among other things) my experience with Scheme, which is an 
awful lot like SML without a type system. Scheme is a great language, 
and there are many things that make a language productive, but at least 
when comparing Scheme with SML, it is indeed SML's type system that 
deserves credit for the non-trivial advantage SML has over Scheme in 
producing robust programs. (The type system also gives SML a performance 
advantage over Scheme.)

-thant

0
thant (332)
6/24/2004 11:24:10 PM
"I spy" <s_nedunuri@yahoo.com> writes:

> Fine, except you now also have a whole tree of dependencies.

If I understand (both of) you correctly, I think I see the point(s). I
would have to agree with Adrian, though, that pure functions
eliminates any dependcies.   E.g. I write my programs composing
functions something like this

    do_work input = print $ format $ compute $ grok $ parse input

(If you're unfamiliar with Haskell, think of the $ as a reversed Unix
pipe |)  Now, since each function has to be pure, i.e. it cannot
modify any state external to it, there are no dependencies, and I can
safely write

    do_less input = print $ format $ dont_compute $ grok $ parse input

or extend it with

    do_work arg input = print $ format $ conditional_ compute arg $ grok...
        where conditional_compute True = compute
              conditional_compute False = dont_compute

and so on.

So I don't think the 'Hierarchical dependency' problem applies to FP.

-kzm
-- 
If I haven't seen further, it is by standing in the footprints of giants
0
ketil (99)
6/25/2004 7:25:35 AM
Simon Helsen wrote:
> 
> let's put this myth out of the world. My functional programs then to be 
> correct because of the functional paradigm (whatever that means - see 
> other thread) and minimally so because of the type system. I am not an 
> antagonist and have extensive experience with functional programming, 
> but this notion of "I wrote my program and when it compiled, it just 
> worked!" is only mildly related to the type system. In fact, in writing 
> fairly large pieces of SML code, I noticed that when I could compile, 
> the remaining (and often very subtle) bugs in my code almost always 
> pointed back to the usage of non-functional programming features such as 
> imperative datastructures (sometimes required for efficiency's sake).

So maybe use of imperative features should be visible in the types, like 
e.g. in Haskell? ;-)

	- Andreas

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

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

0
rossberg (600)
6/25/2004 9:43:47 AM
I spy wrote:
> 
> I think I can hazard a guess as to who Mr X is - or at least - he sounds
> remarkably like another individual I know from another newsgroup. I happen
> to agree with his basic argument, So I'll stick my neck out a bit and try
> and see if I can justify his position. Basically what this other guy often
> rails against is top down problem decomposition. That is if I know I need to
> compute F, I break F down into a series of subfunctions, which are firther
> recursively decomposed until you have a bunch of leaf functions that are (in
> theory) a cinch to write. Fine, except you now also have a whole tree of
> dependencies. Change your root function F and potentially every leaf
> function is affected. OO inverts that dependency. That is you have a group
> of interacting top level classes. The top level classes may have subclasses,
> but these subclasses are not visible to other top level classes. So you now
> have a log linear # of dependencies instead of a quadratic # with standard
> functional decomp. Through the use of patterns such as the Template Method,
> you can use the subclasses to refine what is computed by the top level
> classes, *without* introducing dependencies. Of course you can only do this
> if you have subtype polymorphism of the kind found in OO languages. It is
> difficult to carry out in a standard functional language, even with type
> classes and type class inheriance and all that.

I think I remember the flamewar here, and yes, I believe that is roughly 
what Mr. X was arguing. But IMO, it is completely beside the point, 
because it is just about well-known principles of modular design, i.e. 
programming-in-the-large. That is mostly independent of the paradigm 
used for the underlying programming-in-the-small - nobody would talk 
about individual functions at that level.

With an ML-style module system (which provides much more powerful 
subtyping than the average OO type system) you can achieve something 
very similar (and more, I would add) wrt programming-in-the-large.

	- Andreas

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

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

0
rossberg (600)
6/25/2004 9:44:30 AM
Andreas Rossberg <rossberg@ps.uni-sb.de> writes:

> Simon Helsen wrote:
> > 
> > In fact, in writing 
> > fairly large pieces of SML code, I noticed that when I could compile, 
> > the remaining (and often very subtle) bugs in my code almost always 
> > pointed back to the usage of non-functional programming features such as 
> > imperative datastructures (sometimes required for efficiency's sake).
> 
> So maybe use of imperative features should be visible in the types, like 
> e.g. in Haskell? ;-)

Or maybe using a type-and-effect system to avoid the imperative style
monads force on you?

	Torben
0
torbenm265 (288)
6/25/2004 10:13:55 AM
"Andreas Rossberg" <rossberg@ps.uni-sb.de> wrote in message
news:cbgs5u$4m82e$2@hades.rz.uni-saarland.de...
> I spy wrote:
> >
> > I think I can hazard a guess as to who Mr X is - or at least - he sounds
> > remarkably like another individual I know from another newsgroup. I
happen
> > to agree with his basic argument, So I'll stick my neck out a bit and
try
> > and see if I can justify his position. Basically what this other guy
often
> > rails against is top down problem decomposition. That is if I know I
need to
> > compute F, I break F down into a series of subfunctions, which are
firther
> > recursively decomposed until you have a bunch of leaf functions that are
(in
> > theory) a cinch to write. Fine, except you now also have a whole tree of
> > dependencies. Change your root function F and potentially every leaf
> > function is affected. OO inverts that dependency. That is you have a
group
> > of interacting top level classes. The top level classes may have
subclasses,
> > but these subclasses are not visible to other top level classes. So you
now
> > have a log linear # of dependencies instead of a quadratic # with
standard
> > functional decomp. Through the use of patterns such as the Template
Method,
> > you can use the subclasses to refine what is computed by the top level
> > classes, *without* introducing dependencies. Of course you can only do
this
> > if you have subtype polymorphism of the kind found in OO languages. It
is
> > difficult to carry out in a standard functional language, even with type
> > classes and type class inheriance and all that.
>
> I think I remember the flamewar here, and yes, I believe that is roughly
> what Mr. X was arguing. But IMO, it is completely beside the point,
> because it is just about well-known principles of modular design, i.e.
> programming-in-the-large. That is mostly independent of the paradigm
> used for the underlying programming-in-the-small - nobody would talk
> about individual functions at that level.
I was attempting to answer the previous poster's question about how you can
reuse without introducing hierarchical dependency. Bearing that in mind, it
seems that your response is besides the point! Nobody is denying the
advantages of modular design - but to insist that everything comes down to
modules is as extreme as clamining everything should be an object.
cheers
-sri



0
s_nedunuri (52)
6/25/2004 4:23:51 PM
"Ketil Malde" <ketil@ii.uib.no> wrote in message
news:egfz8kgkuo.fsf@havengel.ii.uib.no...
> "I spy" <s_nedunuri@yahoo.com> writes:
>
> > Fine, except you now also have a whole tree of dependencies.
>
> If I understand (both of) you correctly, I think I see the point(s). I
> would have to agree with Adrian, though, that pure functions
> eliminates any dependcies.   E.g. I write my programs composing
> functions something like this
>
>     do_work input = print $ format $ compute $ grok $ parse input
>
> (If you're unfamiliar with Haskell, think of the $ as a reversed Unix
> pipe |)  Now, since each function has to be pure, i.e. it cannot
> modify any state external to it, there are no dependencies, and I can
> safely write
>
>     do_less input = print $ format $ dont_compute $ grok $ parse input
>
> or extend it with
>
>     do_work arg input = print $ format $ conditional_ compute arg $
grok...
>         where conditional_compute True = compute
>               conditional_compute False = dont_compute
>
> and so on.
>
> So I don't think the 'Hierarchical dependency' problem applies to FP.
Yes, you can certainly get a long way by the correct use of abstract data
types, and properly designed functions, particularly when programming in the
small. But if you take a look at the Design Patterns book you'll see
examples in there of how the OO approach is advantageous when it comes to
minimizing architectural dependencies. Incidentlaly, there's an apparant
obviousness to some of the patterns in that book which is deceptive. I had
to re-read it at least once, and actually use the patterns before I got it.

Note I say OO approach - I happen to think that OO design can be profitably
used even when programming with functional languages, although obviously the
fidelity ("purity" to some :-) of your implementation will depend on the
level of support for the concepts in the language.

cheers
-sri

> -kzm
> -- 
> If I haven't seen further, it is by standing in the footprints of giants


0
s_nedunuri (52)
6/25/2004 4:32:13 PM
I spy wrote:

> I was attempting to answer the previous poster's question about how you
> can reuse without introducing hierarchical dependency.

Oh, I was wondering about that :-)

I'm afraid if that was your aim you've left me unconvinced :-(

Dependency inversion, useful as it is, is not the same thing as dependency
elimination, which is (AFAICT) what Mr. X claims his brand of OT offers.
(Not sure if that's what you're claiming too). Nor is dependency inversion
something that OOPL's or OT have a monopoly on.

Regards
--
Adrian Hey





 


 


0
ahey (217)
6/25/2004 7:00:03 PM
"I spy" <s_nedunuri@yahoo.com> wrote:
> >
> > I think I remember the flamewar here, and yes, I believe that is roughly
> > what Mr. X was arguing. But IMO, it is completely beside the point,
> > because it is just about well-known principles of modular design, i.e.
> > programming-in-the-large. That is mostly independent of the paradigm
> > used for the underlying programming-in-the-small - nobody would talk
> > about individual functions at that level.
> I was attempting to answer the previous poster's question about how you can
> reuse without introducing hierarchical dependency. Bearing that in mind, it
> seems that your response is besides the point! Nobody is denying the
> advantages of modular design - but to insist that everything comes down to
> modules is as extreme as clamining everything should be an object.

I don't follow. You can do modular design with modules or classes or
probably other constructs. Point is, X was comparing peas and
pineapples (approaches to PITS vs. approaches to PITL) in his
argumentation.

  - Andreas
0
rossberg (600)
6/26/2004 3:39:46 AM
"Adrian Hey" <ahey@NoSpicedHam.iee.org> wrote in message
news:G5Kdnflvhcig6kHdRVn-gw@nildram.net...
> I spy wrote:
>
> > I was attempting to answer the previous poster's question about how you
> > can reuse without introducing hierarchical dependency.
>
> Oh, I was wondering about that :-)
>
> I'm afraid if that was your aim you've left me unconvinced :-(
OK, so I didn't succeed... but that's a different issue :-)

> Dependency inversion, useful as it is, is not the same thing as dependency
> elimination, which is (AFAICT) what Mr. X claims his brand of OT offers.
> (Not sure if that's what you're claiming too). Nor is dependency inversion
> something that OOPL's or OT have a monopoly on.
Anyone who claims their particular brand of SW technology eliminate all
dependencies is selling snake oil. The person I have in mind is no snake oil
salesman, so *if* it indeed is the same person (and I have no way of telling
for sure as long as he's the mysterious Mr X, although it sure sounds like
him), then I doubt that's what he was claiming.

Dependency inversion is (one of many) techniques for minimizing
dependencies. As a programmer I would want to have as many in my arsenal as
I can. While it may not be exclusive to OO programming languages (you can
after emulate any feature in any Turing complete language), it is certainly
a hallmark of OO *design*, and I would go so far as to exclusive to OO.  In
the interest of debate, I would welcome counter examples...

cheers
-sri

> Regards
> --
> Adrian Hey
>
>
>
>
>
>
>
>
>
>
>


0
s_nedunuri (52)
6/26/2004 2:33:56 PM
"Andreas Rossberg" <rossberg@ps.uni-sb.de> wrote in message
news:b20b8d03.0406251939.1e22e76a@posting.google.com...
> "I spy" <s_nedunuri@yahoo.com> wrote:
> > >
> > > I think I remember the flamewar here, and yes, I believe that is
roughly
> > > what Mr. X was arguing. But IMO, it is completely beside the point,
> > > because it is just about well-known principles of modular design, i.e.
> > > programming-in-the-large. That is mostly independent of the paradigm
> > > used for the underlying programming-in-the-small - nobody would talk
> > > about individual functions at that level.
> > I was attempting to answer the previous poster's question about how you
can
> > reuse without introducing hierarchical dependency. Bearing that in mind,
it
> > seems that your response is besides the point! Nobody is denying the
> > advantages of modular design - but to insist that everything comes down
to
> > modules is as extreme as clamining everything should be an object.
>
> I don't follow. You can do modular design with modules or classes or
> probably other constructs. Point is, X was comparing peas and
> pineapples (approaches to PITS vs. approaches to PITL) in his
> argumentation.
sorry whats PITS and PITL?

>   - Andreas


0
s_nedunuri (52)
6/26/2004 2:34:26 PM
"Simon Helsen" <where-X=@-in-shelsenXcomputer.org> wrote in message news:cb71pe$ted$1@rumours.uwaterloo.ca...
>
> What is really different between OO and FP is that the formers focuses
> on an extensible datatype model, whereas the latter focuses on
> side-effect free expressions.

I want a language with an extensible datatype model AND
side-effect-free expressions!


Marshall


0
mspight (144)
6/27/2004 5:06:58 AM
"Simon Helsen" <where-X=@-in-shelsenXcomputer.org> wrote in message news:cb71pe$ted$1@rumours.uwaterloo.ca...
>
> What is really different between OO and FP is that the formers focuses
> on an extensible datatype model, whereas the latter focuses on
> side-effect free expressions.

I want a language with an extensible datatype model AND
side-effect-free expressions!


Marshall


0
mspight (144)
6/27/2004 5:24:26 AM
"I spy" <s_nedunuri@yahoo.com> wrote:
> sorry whats PITS and PITL?

Just programming-in-the-small/large.

  - Andreas
0
rossberg (600)
6/27/2004 10:28:31 AM
The initial post has disapeared from my news server,
so I'll just respond here.


Seeing is believing. When we say that closures are
more fundamental than objects, it is because we
know that objects can be built using closures
("easier" than than building closures using objects).


Daniel P. Friedman's "Object-Oriented Style" from
the International LISP Conference, October 2003 describe
how one can use closures and macros to build a simple
object system. It captures very precisely how things
work.

<http://www.cs.indiana.edu/hyplan/dfried/ooo.ps>


Other papers on related matters can by founc at:

<http://library.readscheme.org/page4.html>

-- 
Jens Axel S�gaard
0
usenet8944 (1130)
6/27/2004 10:31:18 AM
Brandon J. Van Every wrote:
> Show me the benchmarks.

Well, I can't. I was discussing what I thought you pointed out was a 
*theoretical* limitation, not a practical one, I beg your pardon if I 
misunderstood. As I haven't (and won't) sink a man year or two into 
Psyco I can't show you any benchmarks.

> That's why it's going to take 3 to 5 years for it to become a good language,
> from a performance standpoint.

I'm not sure I follow. Either Python as a language puts limits on the 
degree to which it's amenable to efficient compilation, or it doesn't 
(cf C and how aliasing screws many optimisations; that's a language 
limitation). More or less development of the compiler wont change that.

Compare if you will the situation within Ericsson with Erlang. The early 
implementations had several shortcomings, but as there was nothing in 
the language that precluded better implementations a few years down the 
road (and it was sort of good enough already) the go ahead was given 
anyhow. If there had been serious limitations with the language itself 
that would have precluded that, it would most certainly have gotten the 
axe at an earlier stage. At the other end of the spectrum is perhaps Ada 
(or Algol 68) that specified many features that people (at the time) 
didn't know how to write compilers for and there was much gnashing of 
teeth as a result.

Stefan,
-- 
Stefan Axelsson  (email at http://www.cs.chalmers.se/~sax)
0
crap1234 (43)
6/27/2004 12:15:42 PM
Stefan Axelsson wrote:
> Brandon J. Van Every wrote:
>> Show me the benchmarks.
>
> Well, I can't. I was discussing what I thought you pointed out was a
> *theoretical* limitation, not a practical one, I beg your pardon if I
> misunderstood. As I haven't (and won't) sink a man year or two into
> Psyco I can't show you any benchmarks.

We're definitely having a theory vs. practice schism here.

>> That's why it's going to take 3 to 5 years for it to become a good
>> language, from a performance standpoint.
>
> I'm not sure I follow. Either Python as a language puts limits on the
> degree to which it's amenable to efficient compilation, or it doesn't
> (cf C and how aliasing screws many optimisations; that's a language
> limitation). More or less development of the compiler wont change
> that.

I'm expressing optimism about what is possible in theory and what will
happen in practice.  I do not know the answer.  Neither do you.  If either
of us knew, we'd be Python variant implementors.  Either that, or astutely
observant of the various optimization efforts currently occurring around
Python.  I do know that they exist, and I haven't heard that they're on a
dead end trajectory.  But, I do not care about the details.  I look at this
strategically, i.e. is anybody making so much progress that it's reasonable
to expect a performance miracle sooner than 3 years from now?  The answer is
no.

-- 
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
6/27/2004 12:37:07 PM
Brandon J. Van Every wrote:

> We're definitely having a theory vs. practice schism here.

Ah, well then, the possibility was always at the back of my mind, my 
bad. "In theory, theory and practice are the same, but in practice 
they're very different."

Stefan,
-- 
Stefan Axelsson  (email at http://www.cs.chalmers.se/~sax)
0
crap1234 (43)
6/27/2004 1:16:37 PM
I spy wrote:

> Anyone who claims their particular brand of SW technology eliminate all
> dependencies is selling snake oil.

Indeed, though in all fairness, the claim is to have eliminated all
"hierarchical dependency". Dunno if there's supposed to be some significance
in that, like non-hierarchical dependency (whatever that might be) is OK
perhaps?

Sometimes this claim is qualified by "at a given level of abstraction".
The fact that this qualification is necessary makes me suspect that in
reality OT does have hierarchical dependency "problems" between levels
of abstraction. In fact, a real cynic might suspect that levels of
abstraction are deliberately chosen to make the claim to have eliminated
hierarchical dependency appear plausible (to a sufficiently naive audience).

FPers could also legitimately claim that thier programs were "free from
hierarchical dependency at a given level of abstraction", though generally
they don't because they're not so anal about this dependency thing.

What FPers are anal about is referential transparency :-)
 
> Dependency inversion is (one of many) techniques for minimizing
> dependencies. As a programmer I would want to have as many in my arsenal
> as I can. While it may not be exclusive to OO programming languages (you
> can after emulate any feature in any Turing complete language), it is
> certainly
> a hallmark of OO *design*, and I would go so far as to exclusive to OO. 

I've noticed a tendency to make such assumptions in the OO community :-)
"Abstraction" and "Polymorphism" are examples of other traits that are
exclusive to OO (or so some propogandists would have us believe).

> In the interest of debate, I would welcome counter examples...

The dependency inversion principle is just a fancy way of saying don't
make stuff that's likely to reusable dependent on stuff that's unlikely
to be reusable. Sound advice in any language.

FPers apply this principle every time they define a higher order function. 
ML users can do this at the module level too.

Regards
--
Adrian Hey

0
ahey (217)
6/28/2004 10:49:49 AM
"Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com> writes:

> Well, Erlang was pushed by a company.  Academics definitely aren't into
> 'push', the only marketing they care about is papers.  To me the question is
> whether academics allow / facilitate a bunch of non-academics, so that other
> people can actually get the gruntwork done.

Just for the record, Ericsson never really pushed Erlang as much as it
(mostly) allowed it to exist and be tried by those projects that dared
risk it. You may read Bjarne Dacker's excellent thesis
(http://www.erlang.se/publications/bjarnelic.ps) to get the details,
but essentially, "marketing" of Erlang was done rather half-heartedly
in 1993-95, with a very limited budget, and then explicitly stopped
in 1996 (when Erlang compentence was redirected to some major
projects.) In the thesis, you will find reference to even more
dramatic setbacks. Erlang evolved very much thanks to a few successful
commercial projects -- since it was used in some important products,
and could support itself through user licenses, we might as well try
to find a low-cost way to spread it outside of the company, and try to
reduce our own risks. Open Source proved to be the answer.

In 1993, I was a potential Erlang customer -- or rather, I wanted very 
much to become an Erlang customer -- but could not get a satisfactory 
support commitment from Ericsson. My impression then, as an outsider, 
was that while Ericsson allowed Erlang to be developed and to some 
extent marketed, it did not consider it an official Ericsson product. 
I solved the dilemma by joining Ericsson in 1996. Nowadays, you don't 
have to resort to such drastic measures just to use Erlang. ;-)

/Uffe
-- 
Ulf Wiger, Senior Specialist,
   / / /   Architecture & Design of Carrier-Class Software
  / / /    Strategic Product & System Management
 / / /     Ericsson AB, Connectivity and Control Nodes
0
ulf.wiger1 (107)
6/29/2004 2:24:19 PM
Joachim Durchholz <jo@durchholz.org> wrote in message news:<cb3trt$u1t$1@news.oberberg.net>...
> 
> Of course, you can also construct a closure using a class. You "just"
> need to write about 50 lines to handle class syntax, constructor, and an
> "execute" function that houses the expression proper. Oh, and find a
> good name for the class, write the JavaDoc stuff, make a unit test -
> what's a single line of code not even worthy a second thought in a
> functional language takes two full days in an OO language.

Not with appropriate libraries. In C++, for example, you can use the
Boost library's "bind" to perform function currying:

int plus(int a,int b) { return a+b; }

int main()
{
  int result=bind(plus,1,_1)(2); // Will give "3"
}

Other libraries may do it as bind(plus)(1)(2), or similar.

50 lines to handle syntax? I think not.

Closures and other FP features can similarly be handled with
libraries, and is used to great effect in modern C++ libraries, like
the Spirit parser framework.

Furthermore, you can create lambda-functions, using Boost.Lambda,
e.g.:

vector<int> v(10);

for_each(v.begin(), v.end(), cout << _1 + 1); // Prints the elements
of the sequence, adding one to each

It's a common fallacy to claim that something is easy in language X,
and hard in language Y, when you have only kept up with the recent
developments in language X, and not in language Y.

Or, to put it in a different way: All languages supporting OO
programming are not equal.

Rather than discussing specific languages, it might be more productive
to discuss the various paradigms and abstractions, and what kind of
things they are well suited for (regardless which language one use),
whether those paradigms are procedural, OO, generic, functional
programming, etc.

Not to mention how combination of paradigms (like OO and generic
programming) may enable you to do things that neither paradigm, by
itself, can do. But this strays rather far from OP.

> There's a more indirect advantage.
> The more restricted a piece of code is, the easier it is to read - you
> have less assumptions to check when it comes to understand why it does
> what it does.
> FPLs don't overwrite data (usually), so if you're chasing a bug, you
> don't have to check your assumptions whether some data stays the same,
> sparing you a lot of thought and and code-sifting effort.

"const" gives an alternative to this in C++.

Regards,

Terje
0
6/29/2004 2:50:52 PM
Terje Sletteb? wrote:

[...]

> It's a common fallacy to claim that something is easy in language X,
> and hard in language Y, when you have only kept up with the recent
> developments in language X, and not in language Y. [...]

Some of us have kept up with language Y (where Y is C++). I wrote my own 
closure system in C++ years ago as soon as templates could handle it. 
I've even written a functional programming language interpreter in C++ 
in just over 7K lines of code, including a mark-and-sweep garbage 
collecting smart pointer, lexer generator, and SLR parser generator. 
<http://www.standarddeviance.com/sigma>

Functional programming is not impossible in C++, and the attempt is 
sometimes worth the effort, but I can't help but be suspicious of the 
experiences of anyone who suggests that it is easy to do FP in C++. That 
C++ programmers will go to the lengths they do to emulate (poorly) FP 
techniques says more about the value of FP than about the value of C++.

-thant

0
thant (332)
6/29/2004 3:35:36 PM
----- Original Message ----- 
From: "Adrian Hey" <ahey@NoSpicedHam.iee.org>
Newsgroups: comp.lang.functional
Sent: Monday, June 28, 2004 11:49 AM
Subject: Re: FP tutorial for OO programmers?


> I spy wrote:
>
> > Anyone who claims their particular brand of SW technology eliminate all
> > dependencies is selling snake oil.
>
> Indeed, though in all fairness, the claim is to have eliminated all
> "hierarchical dependency". Dunno if there's supposed to be some
significance
> in that, like non-hierarchical dependency (whatever that might be) is OK
> perhaps?
>
> Sometimes this claim is qualified by "at a given level of abstraction".
> The fact that this qualification is necessary makes me suspect that in
> reality OT does have hierarchical dependency "problems" between levels
> of abstraction. In fact, a real cynic might suspect that levels of
> abstraction are deliberately chosen to make the claim to have eliminated
> hierarchical dependency appear plausible (to a sufficiently naive
audience).
>
> FPers could also legitimately claim that thier programs were "free from
> hierarchical dependency at a given level of abstraction", though generally
> they don't because they're not so anal about this dependency thing.
>
> What FPers are anal about is referential transparency :-)
Nothing wrong with that. See below

>
> > Dependency inversion is (one of many) techniques for minimizing
> > dependencies. As a programmer I would want to have as many in my arsenal
> > as I can. While it may not be exclusive to OO programming languages (you
> > can after emulate any feature in any Turing complete language), it is
> > certainly
> > a hallmark of OO *design*, and I would go so far as to exclusive to OO.
>
> I've noticed a tendency to make such assumptions in the OO community :-)
> "Abstraction" and "Polymorphism" are examples of other traits that are
> exclusive to OO (or so some propogandists would have us believe).
Perhaps not abstraction but certainly polymorphism + dynamic binding are.
Where in FP prior to OO was there any discussion of subtype polymorphism? Or
inheritance? Or event based programming? I think its only fair to give
credit where credit's due.

> > In the interest of debate, I would welcome counter examples...
>
> The dependency inversion principle is just a fancy way of saying don't
> make stuff that's likely to reusable dependent on stuff that's unlikely
> to be reusable. Sound advice in any language.
Almost. Its actually about making sure that abstractions don't depend on
details. (see Robert Martin's book on OO Design for extensive discussion of
this about 8 other OO principles). Of course, if you put it that way, you
could encapsulate (trivialize?) almost any principle. After all, Parnas's
advice on modules is "just a fancy way" of saying don't expose anything that
doesn't need to be exposed. But consider what came about of that deceptively
simple principle. Besides, its much harder to walk the talk.

> FPers apply this principle every time they define a higher order function.
I doubt it. The absence of frameworks (as an example) in the FP world shows
its not a commonly used principle.

I must emphasize (as I often do when I interact with Mr X' (a pointer alias
to someone who may or may not the same as Mr X)) that I distinguish the
programming language from the design approach. I believe it is possible to
get a good way towards the benefits of OO design in a functional language.
And as I've been discovering, with exotica like existential types, get even
closer than I originally thought.
However, it does involve a change in mindset. Certainly languages are biased
towards certain way of thinking to misquote Wittgenstein so it isn't always
easy, and its possible that what you end up with won't look idiomatic in
that language. At that point, it may be time to take the best of what you
have in your iriginal language and create a new one. I dont know. I'm still
discovering.

Take a look at Robert Martin's article at
www.objectmentor.com/publications/dip.pdf
As he shows in there, he demonstrates how you can get dep inversion even in
(gasp) C.

cheers
-sri


0
s_nedunuri (52)
6/29/2004 4:02:32 PM
Thant Tessman wrote:

> Functional programming is not impossible in C++, and the attempt is 
> sometimes worth the effort, but I can't help but be suspicious of the 
> experiences of anyone who suggests that it is easy to do FP in C++. That 
> C++ programmers will go to the lengths they do to emulate (poorly) FP 
> techniques says more about the value of FP than about the value of C++.

For once ;-) I agree with Thant. Much of the power Terje is referring to 
originates from the availabitity of templates in C++, which by 
themselves are a functional language.

Still, C++ is not functional and programs in C++ are not functional 
(despite this modern usage of the language). I think this highlights my 
case in a previous discussion with Thant on what makes FP FP and more 
importantly, why it appears so powerful for those experienced using it.

Summarized, even if you have HO facilities in C++ (and Smalltalk, where 
it has been around since the beginning), what makes FP's programs so 
much better is the emphasis (and in Haskell "requirement") to write 
"side-effect free" programs. This, as I said, is rooted in making 
identifier binding separate (and the default) from variable assignments.

On another note, you could wonder why this side-effect free style of 
programming never took off if I (and many here) claim it is so 
effective. Lots of explanations are possible:

1) historical. Most computer programming comes from Von Neumann 
machines, not functions. In such an environment, implicit state is very 
natural. The lambda calculus was long a pure mathematical notion, not a 
practical one. By the time it became practical, it was too late...

2) to effectively program side-effect free, you have to write recursive 
functions all the time. As a seasoned FPer, I find it more natural to 
write a recursive function than a while-loop, but that is not true for 
many programmers. I think though, that if someone who has never 
programmed, immediately learns iteration as recursion, things would be 
different. Maybe that is not happening because of 1). I have once 
contested in this newsgroup that it is also related to the way we are 
tought mathematics in High-School. Most of it is continuous (or even 
discrete) analysis and very little recursive algebra.

Maybe I should stop here...

	Simon
0
Simon
6/29/2004 6:18:09 PM
I spy wrote:

> Perhaps not abstraction but certainly polymorphism + dynamic binding are.
> Where in FP prior to OO was there any discussion of subtype polymorphism?
> Or inheritance? Or event based programming? I think its only fair to give
> credit where credit's due.

Sorry, I hadn't realised we were debating history. I honestly don't know
the chronology of when these ideas were developed and when they were
first incorprated, and in what languages. Perhaps you think you do.
Even so, I don't think it's of any relevance to present day state of
the art, in FP or OO.

>> FPers apply this principle every time they define a higher order
>> function.
> I doubt it.

You should doubt your doubt, given your evident inexperience with
FP and FPLs. 

> The absence of frameworks (as an example) in the FP world
> shows its not a commonly used principle.

Just because FPers don't call thier frameworks "frameworks" doesn't mean
they don't exist.

> I believe it is
> possible to get a good way towards the benefits of OO design in a
> functional language.

Maybe the benefits of "OO" design just aren't that great.
Maybe OOism isn't even necessary to get what benefits there are.
Maybe FP offers benefits that OOism doesn't.

This is all purely hypothetical of course. Everybody knows OO is
really the best. It just is. We should pity all those poor FPers
trying to do thier OO in such crippled languages.

> However, it does involve a change in mindset.

Yep, that much is true :-)

Regards
--
Adrian Hey






  



0
ahey (217)
6/29/2004 6:33:51 PM
Simon Helsen wrote:
>
> On another note, you could wonder why this side-effect free style of
> programming never took off if I (and many here) claim it is so
> effective. Lots of explanations are possible:

I'm glad I kept following this thread I started.  You have elucidated some
core differences between paradigms in a simple manner... I didn't know that
anyone was ever going to do it.

> 1) historical. Most computer programming comes from Von Neumann
> machines, not functions. In such an environment, implicit state is
> very natural. The lambda calculus was long a pure mathematical
> notion, not a practical one. By the time it became practical, it was
> too late...
>
> 2) to effectively program side-effect free, you have to write
> recursive functions all the time. As a seasoned FPer, I find it more
> natural to write a recursive function than a while-loop, but that is
> not true for many programmers. I think though, that if someone who
> has never programmed, immediately learns iteration as recursion,
> things would be different.

I see a more fundamental issue than "what a beginner is used to."  Namely,
some problems are better described recursively, and others are better
described iteratively.  You might flatten or hierarchize an algorithm to
work the other way, but that often amounts to shoehorning.

It matters very much how flat or hierarchical a problem was to begin with.
I might choose to see IO in terms of hierarchical nested structures -
natural languages work that way at the phrase level, after all.  But that's
just tactics; strategically, human communication is an ongoing flat stream
of sentences.  Then if you get enough sentences you might try to make
hierarchical meaning out of 'em again, or you might get lost.

Recursive or iterative representation might be appropriate at different
levels of a problem.  For instance, low level 3D graphics operations are
easily seen in terms of pipeline stages, like the IO devices and Von Neumann
architectures they're feeding.  But, scene graphs and spatial databases are
recursive entities.  Yet, intermediate layers are often flattened with plain
grid addressing systems, so that fewer levels of recursion exist.  This
brings greater efficiency when recursion is context-heavy, such as with a
memory cache hierarchy.

It may seem insightful to talk about Von Neumann architectures as "defining
computation in terms of a bottleneck," but really you're getting what you
pay for.  If you want a machine that can recurse well, to all sorts of
contexts, you're talking about spending a lot more HW silicon gates to
facilitate it.  You just gonna put lotsa expensive SRAM in your box and not
have any memory hierarchy?  You gonna wire every component to talk to every
component, instead of through an IO bus?  That's expensive.

Ironically, recursion would be better able to express a cache hierarchy.
The problem is would you do so 'honestly'.  Would you burden the programmer
with the knowledge of memory context, and the penalties for making a switch
as you move up-down the hierarchy?  Or would you take the academic CS
approach that memory hierarchies shouldn't exist because we shouldn't have
to be sullied with 'em?

-- 
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
6/29/2004 8:05:13 PM
On Tue, 29 Jun 2004 17:02:32 +0100
"I spy" <s_nedunuri@yahoo.com> wrote:

> Take a look at Robert Martin's article at
> www.objectmentor.com/publications/dip.pdf
> As he shows in there, he demonstrates how you can get dep inversion
> even in (gasp) C.

I apologize in advance if I misinterpret what you have said; I haven't
been following this thread closely.  I read the article you linked to
and was happy to find a definition of dependence inversion that I
could understand.  The parts of this thread that I have looked at have
left me somewhat confused about what this mysterious dependence
inversion beast was.  If I understand correctly, I can guarantee you
that I use higher order functions all over the place in my SML code to
achieve dependence inversion and I'm pretty sure that such techniques
are so common in the functional programming community that people
don't even think to give it a name.

It seems to me that there is no significant difference between
functional and object oriented languages with respect to dependence
inversion.  Is there something special about object orientation that
lends itself to dependence inversion?  Do you suspect that I've missed
some important point somewhere?

Benjamin
0
benjaminy (25)
6/29/2004 8:22:23 PM
On Tue, 29 Jun 2004 14:18:09 -0400, Simon Helsen
<where-X=@-in-shelsenXcomputer.org> wrote:

>On another note, you could wonder why this side-effect free style of 
>programming never took off if I (and many here) claim it is so 
>effective.

I routinely throw out a challenge to FPers
which they never meet.

Write a fully skinable ( with functionality; write
skins; read skins; create/modify skins; change skins;
revert to previous skins ) GUI from a basic
widget set ( Motif, GTK, QT, MFC, OWL ... no skinable
functionality included --that's cheating )
in a side effect free manner.

Tell any fledgling programmer how hard this is and they
go running awat from FP as fast as they can.

FP isn't popular, because programmers don't like FP.


The reply-to email address is olczyk2002@yahoo.com.
This is an address I ignore.
To reply via email, remove 2002 and change yahoo to
interaccess,

**
Thaddeus L. Olczyk, PhD

There is a difference between
*thinking* you know something,
and *knowing* you know something.
0
olczyk2002 (317)
6/29/2004 8:39:16 PM
On Tue, 29 Jun 2004 15:39:16 -0500, TLOlczyk <olczyk2002@yahoo.com> wrote:

> On Tue, 29 Jun 2004 14:18:09 -0400, Simon Helsen
> <where-X=@-in-shelsenXcomputer.org> wrote:
>
>> On another note, you could wonder why this side-effect free style of
>> programming never took off if I (and many here) claim it is so
>> effective.
>
> I routinely throw out a challenge to FPers
> which they never meet.
>
> Write a fully skinable ( with functionality; write
> skins; read skins; create/modify skins; change skins;
> revert to previous skins ) GUI from a basic
> widget set ( Motif, GTK, QT, MFC, OWL ... no skinable
> functionality included --that's cheating )
> in a side effect free manner.
>
> Tell any fledgling programmer how hard this is and they
> go running awat from FP as fast as they can.
>
> FP isn't popular, because programmers don't like FP.
>

When you post to a newsgroup, you get responded to in the
same way.

Your so-called FP challenge is ridiculous. I've never read or
heard any FPer claim that frou-frou programming (skins, etc.)
is a strength of FP, or even something an FP-oriented programmer
would care about, much less spend any time writing that sort of
teenage stuff. I would wager that most subscribers to this group
use a program for reasons like functionality, robustness, accuracy,
reliability - not how 'cool' it looks on the screen.
--
dg
0
Don
6/29/2004 9:22:40 PM
TLOlczyk wrote:

> I routinely throw out a challenge to FPers
> which they never meet.
> 
> Write a fully skinable ( with functionality; write
> skins; read skins; create/modify skins; change skins;
> revert to previous skins ) GUI from a basic
> widget set ( Motif, GTK, QT, MFC, OWL ... no skinable
> functionality included --that's cheating )
> in a side effect free manner.
> 
> Tell any fledgling programmer how hard this is and they
> go running awat from FP as fast as they can.
> 
> FP isn't popular, because programmers don't like FP.

Maybe you are right. Maybe most programmers are only interested in 
creating graphical user interfaces and fancy-looking (and not 
necessarily useful) applications. Maybe it is true that most 
applications at the end of the day are so simple in terms of their logic 
that FP does not bring much.

But people do not complain about Micros**t software because of the lack 
of nice GUIs (well, I am sure one or the other Mac-lover will complain 
at this point). They complain because subtle incomprehendable bugs slip 
into programs that cause them to crash, misperform or others. The 
*logic* of these programs fails.

As somebody else said, that is not the point. There are nice GUI 
frameworks for FPs, that, of course, do use side-effects. Also, I once 
in a while prefer an efficient imperative datastructure when there is no 
known efficient functional one. However, I want to be able to naturally 
write in a functional (side-effect free) style when possible. The 
popular languages of the day do not let me.

Programmers don't *not* like FP because they cannot program what they 
want. A hybrid language would have easily amended the problem. I want to 
know why there is such an negative bias to recursive side-effect free 
solution. In fact, today in my class, I again noticed that some students 
could not "think" without side-effects. They hardly understand the notion.

Also, your argument is very weak because Smalltalk never took off 
either. Yet, they *invented* the notion of such GUIs and replacable skins.

	Simon

> 
> 
> The reply-to email address is olczyk2002@yahoo.com.
> This is an address I ignore.
> To reply via email, remove 2002 and change yahoo to
> interaccess,
> 
> **
> Thaddeus L. Olczyk, PhD
> 
> There is a difference between
> *thinking* you know something,
> and *knowing* you know something.

-- 
-- Simon Helsen, Ph.D.
-- Dep. of Electrical and Computer Engineering
-- University of Waterloo, Canada
-- http://www.helsen.org
0
Simon
6/29/2004 10:36:20 PM
Thaddeus Olczyk wrote:

> > Write a fully skinable ( with functionality; write
> > skins; read skins; create/modify skins; change skins;
> > revert to previous skins ) GUI from a basic
> > widget set ( Motif, GTK, QT, MFC, OWL ... no skinable
> > functionality included --that's cheating )
> > in a side effect free manner.
> > Thaddeus L. Olczyk, PhD

Well, I'm not a PhD, but IMHO the side-effect-free-ness is a viable option
for algorithmical problems, but not a panacea for everything. SML, for
example, provides imperative I/O that can be used for creating user
interfaces. It's not that it impossible to write imperative code, just
harder to maintain. But if you resort to it only where necessary, you make
an advantage. Writing MLish code means you tend to write "functional" code
but only when it's possible.

Java Swing is a nice abstraction for writing GUIs. I doubt if there's a
_much_ better way of doing this. And yet there are application fields (e.g.
compilers) where FPLs shine.

But to return to the original suggestion, a pluggable skin looks like a
structure that can be feed to your application functor -  which is the ML
way of thinking. Just there was not enough  manpower to tackle this highly
important problem.

- Gergely, SML bigot


0
greg7497 (2)
6/30/2004 9:10:15 AM
"Benjamin Ylvisaker" <benjaminy@alumni.cmu.edu> wrote in message
news:20040629162223.380a6634.benjaminy@alumni.cmu.edu...
> On Tue, 29 Jun 2004 17:02:32 +0100
> "I spy" <s_nedunuri@yahoo.com> wrote:
>
> > Take a look at Robert Martin's article at
> > www.objectmentor.com/publications/dip.pdf
> > As he shows in there, he demonstrates how you can get dep inversion
> > even in (gasp) C.
>
> I apologize in advance if I misinterpret what you have said; I haven't
> been following this thread closely.  I read the article you linked to
> and was happy to find a definition of dependence inversion that I
> could understand.  The parts of this thread that I have looked at have
> left me somewhat confused about what this mysterious dependence
> inversion beast was.  If I understand correctly, I can guarantee you
> that I use higher order functions all over the place in my SML code to
> achieve dependence inversion and I'm pretty sure that such techniques
> are so common in the functional programming community that people
> don't even think to give it a name.
>
> It seems to me that there is no significant difference between
> functional and object oriented languages with respect to dependence
> inversion.  Is there something special about object orientation that
> lends itself to dependence inversion?  Do you suspect that I've missed
> some important point somewhere?
>
> Benjamin
Not at all. In fact, that's exactly the kind of feedback I was looking for.
To continue Robert Martin's example, then, do you abstract out strings,
devices, and files into streams in your code and then pass around the
appropriate "driver"?

Here's another example, also from Robert Martin:

A simple example:  The button and lamp.  The button object needs to
send the 'turnOn' message to the Lamp.  How shall we accomplish this?

  Button<>-----------Lamp

Certainly, using the 'has' relationship in this way makes it possible
for the button to send the 'turnOn' message to the lamp.  However it
also means that Button *depends* upon Lamp.  That makes it very
difficult for Button to control Fans, Ovens, or Telephones.  An
alternative is "The Abstract Server" design pattern:


  Button<>----------[]ButtonServer
                          A
                          |
                        Lamp


Here, ButtonServer is an abstract base class with a pure virtual
'TurnOn' method.  Button contains a pointer to ButtonServer.  Lamp
derives from ButtonServer and implements the TurnOn message.

Note, that in this case, Button does not depend upon Lamp.  If we want
button to control a Fan, we can simply derive Fan from ButtonServer.

But what if we have purchased the Fan class from a third party.  We
can't modify the source code to have it inherit from ButtonServer.  So
we employ the "AdaptedServer" design pattern:

Button<>--------------[]ButtonServer
                            A
                            |
                            |
                         FanAdapter<>---------[]Fan

Here, FanAdapter is a simple class that inherits from ButtonServer
and which 'has' a Fan.  When the FanAdapter receives the "TurnOn"
message, it delegates to the Fan object.

Notice that all these relationships are 'one-way'.  Note that Button
does not care about anything past the ButtonServer.  We can make
changes to Fan, FanAdapter, or any other derivative of ButtonServer,
and Button does not care.

From what I've seen of FP, higher order functions are used to abstract away
algorithms, but this kind of dependency inversion is rare. In fact, I
suspect your average FPer would turn their nose up in disgust :-)

cheers
-sri


0
s_nedunuri (52)
6/30/2004 10:08:45 AM
"Adrian Hey" <ahey@NoSpicedHam.iee.org> wrote in message
news:jZmdncMmyMaIKnzdRVn-sA@nildram.net...
> I spy wrote:
>
> > Perhaps not abstraction but certainly polymorphism + dynamic binding
are.
> > Where in FP prior to OO was there any discussion of subtype
polymorphism?
> > Or inheritance? Or event based programming? I think its only fair to
give
> > credit where credit's due.
>
> Sorry, I hadn't realised we were debating history. I honestly don't know
> the chronology of when these ideas were developed and when they were
> first incorprated, and in what languages. Perhaps you think you do.
> Even so, I don't think it's of any relevance to present day state of
> the art, in FP or OO.
Fine, then how many FP articles or books talk about any of these things
today?

> >> FPers apply this principle every time they define a higher order
> >> function.
> > I doubt it.
>
> You should doubt your doubt, given your evident inexperience with
> FP and FPLs.
And yours obviously with OO? Its clear that a discussion's going to get
nowhere if you start hurling insults dude.

> > The absence of frameworks (as an example) in the FP world
> > shows its not a commonly used principle.
>
> Just because FPers don't call thier frameworks "frameworks" doesn't mean
> they don't exist.
Hmm..lessee.. what do they call them then?

> > I believe it is
> > possible to get a good way towards the benefits of OO design in a
> > functional language.
>
> Maybe the benefits of "OO" design just aren't that great.
> Maybe OOism isn't even necessary to get what benefits there are.
> Maybe FP offers benefits that OOism doesn't.
I don't think I ever denied that. In fact I believe I've said it more than
once. Let me say it again for the record: FP offers benefits that OOism
doesn't. There. Do I get into the club now?
I have to say you seem pretty touchy about your favorite little development
paradigm. If I hadn't experience with FP and the FP community, it would be
rather offputting. It doesn't really bother me, but that kind of response
would lead many newcomers to write the community off as a bunch of old
grouches.

> This is all purely hypothetical of course. Everybody knows OO is
> really the best. It just is. We should pity all those poor FPers
> trying to do thier OO in such crippled languages.
What nonsense.

cheers
-sri
> > However, it does involve a change in mindset.
>
> Yep, that much is true :-)
>
> Regards
> --
> Adrian Hey
>
>
>
>
>
>
>
>
>
>


0
s_nedunuri (52)
6/30/2004 10:09:19 AM
On Wed, 30 Jun 2004, I spy wrote:

> > Just because FPers don't call thier frameworks "frameworks" doesn't mean
> > they don't exist.
> Hmm..lessee.. what do they call them then?
>

"Domain-specific languages" seems to be a pretty common one in Haskell.
Combinator libraries another. How does Parsec compare to what you'd expect
of a parsing framework?

-- 
flippa@flippac.org
0
flippa (196)
6/30/2004 10:36:22 AM
I spy wrote:

> Fine, then how many FP articles or books talk about any of these things
> today?

I don't know, you'll have to count them yourself if this an issue for you.

> Its clear that a discussion's going to get nowhere if you start hurling
> insults dude.

Sorry "dude". It's certainly true I do get a little hacked off at people
who assume they know FP despite having never used any FPL, even once. I've
been using them in one form or another for over 15 years and I still get
surpised by their expressive power and the stuff folk come up with.  

But, perhaps I was hasty to assume that you were such a person.

>> Just because FPers don't call thier frameworks "frameworks" doesn't mean
>> they don't exist.
> Hmm..lessee.. what do they call them then?

They call them "libraries", or maybe "combinator libraries".

Regards
--
Adrian Hey
 

0
ahey (217)
6/30/2004 11:32:05 AM
Brandon J. Van Every wrote:
> Simon Helsen wrote:
>> 2) to effectively program side-effect free, you have to write
>> recursive functions all the time. As a seasoned FPer, I find it more
>> natural to write a recursive function than a while-loop, but that is
>> not true for many programmers. I think though, that if someone who
>> has never programmed, immediately learns iteration as recursion,
>> things would be different.
> 
> I see a more fundamental issue than "what a beginner is used to."��Namely,
> some problems are better described recursively, and others are better
> described iteratively.��You�might�flatten�or�hierarchize�an�algorithm�to
> work the other way, but that often amounts to shoehorning.

This is an interesting observation in relation to the duality of
iteration/call-by-value versus recursion/call-by-name as described by
Filinski (http://citeseer.lcs.mit.edu/filinski89declarative.html).
If both iteration and recursion should be in the programmer's toolbox, then
why not both call-by-value and call-by-name (i.e. strict and lazy)? 

0
news239 (43)
6/30/2004 12:13:49 PM
I spy wrote:
> 
> A simple example:  The button and lamp.  The button object needs to
> send the 'turnOn' message to the Lamp.  How shall we accomplish this?
> 
>   Button<>-----------Lamp
> 
> Certainly, using the 'has' relationship in this way makes it possible
> for the button to send the 'turnOn' message to the lamp.  However it
> also means that Button *depends* upon Lamp.  That makes it very
> difficult for Button to control Fans, Ovens, or Telephones.  An
> alternative is "The Abstract Server" design pattern:
> 
>   Button<>----------[]ButtonServer
>                           A
>                           |
>                         Lamp
> 
> Here, ButtonServer is an abstract base class with a pure virtual
> 'TurnOn' method.  Button contains a pointer to ButtonServer.  Lamp
> derives from ButtonServer and implements the TurnOn message.
> 
> Note, that in this case, Button does not depend upon Lamp.  If we want
> button to control a Fan, we can simply derive Fan from ButtonServer.
> 
> But what if we have purchased the Fan class from a third party.  We
> can't modify the source code to have it inherit from ButtonServer.  So
> we employ the "AdaptedServer" design pattern:
> 
> Button<>--------------[]ButtonServer
>                             A
>                             |
>                          FanAdapter<>---------[]Fan
> 
> Here, FanAdapter is a simple class that inherits from ButtonServer
> and which 'has' a Fan.  When the FanAdapter receives the "TurnOn"
> message, it delegates to the Fan object.


This is a good example demonstrating the sort of cultural clash we have 
witnessed here so many times. Reading this, the seasoned FP programmer 
would just shake his head and ask "Why on earth do I need to mess with 
multiple classes, purely virtual methods, inheritence and adaptors, when 
all I want is just abstracting over a turnOn function??? And how could 
anybody ever bother calling such trivial and obvious abstractions design 
patterns and inventing names for it?"

Please forgive my bit of sarcasm here, I'm well aware that the example 
is just a simple instance of a more general scheme. But all of this 
usually is quite easy to express in your favorite FPL. In simple cases, 
it just boils down to higher-order functions, for more complex cases 
you'd probably resort to more high-level mechanisms, e.g. functors in ML 
or type classes in Haskell.


> From what I've seen of FP, higher order functions are used to abstract away
> algorithms, but this kind of dependency inversion is rare.  In fact, I
> suspect your average FPer would turn their nose up in disgust :-)

Not at all, that's what higher-order functions and polymorphism are all 
about. Dependency inversion is nothing but another word for abstraction. 
Your average FPer might just consider the use of abstraction too banal 
to mention. :-)

Cheers,

	- Andreas

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

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

"Computer games don't affect kids; I mean if Pac Man affected us
  as kids, we would all be running around in darkened rooms, munching
  magic pills, and listening to repetitive electronic music."
  - Kristian Wilson, Nintendo Inc.

0
rossberg (600)
6/30/2004 1:06:34 PM
"Daniel C. Wang" <danwang74@hotmail.com> writes:

> Matthias Blume wrote:
> {stuff deleted}
> > You are being extremely unfair, and you know it.  What "fiasco"?
> > What
> > "stupidities"?  Be glad John and (I believe) Emden are not reading
> > netnews, otherwise a big, serious apology would be in order.  And by
> > this I don't mean:
> 
> They can't ship a tarball of the webpages because of the copyright
> issues with the publisher. An API that I can't get in electronic form
> is absolutely useless.

Now, this takes the prize for the lamest charge ever!

    wget -r http://www.standardml.org/Basis/

> They didn't need to publish a book. They need to get all the ML
> implementations on board and agree to stay in sync, which these days
> isn't the case.

It takes care of design to produce something people will be willing to
stay in sync with.  It also takes care (and time!) to keep 400+ pages
internally consistent.  About the other things one can argue, and the
process has certainly not been optimal.  But just standing on the
outside and throwing dirt around doesn't help.

My very limited archive (9/03-now) of the Basis discussion mailing
list has around 300 messages.  (None from Dan Wang, though.)
So, yes, the process has to be lively.  And, yes, it is.

> {stuff deleted}
> > In short, I don't care if SML or Haskell or even OCaml or Clean or ...
> > will die -- as long as some of the better ideas that went into their
> > design make it into future languages and as long as the worst ideas
> > survive as warnings for future designers.  In this sense the Algol
> > analogy is probably true -- and no reason for being ashamed.
> 
> If you have that attitude then any seriously pragmatic developer will
> not dare bet a project on SML/NJ with every good rational reason not
> too.

Look.  I think SML is a very good language, and SML/NJ is a very good
implementation of it.  I am very fond (and proud) of some of its more
unique features, and I use it daily.  It won't die any time soon.  On
the other hand, there are clearly things that can be improved (both
with SML/NJ and the language in general), so I am not going to make it
my mission in life to go for "world domination".  Doing so would be a
waste of time, realistically speaking.  Again, as academics we can do
only so much.  We can produce ideas, we can make reasonably good
implementations of those ideas.  But a commercial compilers will
always be better (in implementation terms) because more time and
resources can be devoted to details that are important but
unpublishable.  And, of course, there is no way to seriously compete
with a commercial marketing campaign.

> If you don't care about building a base, then why continue
> working and doing mantaince on SML?

Because these days it is my tool.  (And it is also the tool for many
other people.)

> There are much more intellectually interesting problems to tackle.

Indeed.  Lukily, some of them can be pursued in the context of an
implementation of SML.

> Anyway, you basically seem to agree with me about the philosophy of
> development that is being used and mostly agree with the long term
> outcomes of such a result.

The long-term outcome has noting to do with the development model.
Long-term outcome is extremely weakly (if at all) related to how the
language and one particular implementation are being developed.  Also,
I don't see how a "bazaar" approach could possibly deal with a
language like SML.

> If SML/NJ developers are happy with the outcomes of SML becoming
> "the next Algol" then great..

I think that a language that is the father of (with few notable
exceptions) every other language practically used cannot be called a
"miserable failure" at all!  If SML would be *that* successful, I'd
indeed be more than happy.

Still, "happy" is the wrong word.  "Resigned to" would perhaps be
better.

> BTW First there was MINIX the wonderful jewel of an OS created by a
> great academic and published as a book. Then this silly grad student
> ignoring all that wonderful academic jewelry wrote something to be
> useful.

I think you are reading to much into this.  Linux is a fluke.  Try
repeating it.  You'll never succeed.
Also, it took and takes someone who makes it his/her life's mission.
In an academic environment this is nearly impossible.

> I personally do not buy into ESRs explination of everything,
> but I can see the pattern of how academic research gets developed and
> "deployed". I understand the reward models of research environments
> and pretty much certain this failure of research to have direct impact
> on day to day practice is a systematic faliure.

I guess we just have different ideas of what the purpose of academic
research should be.

Matthias
0
find19 (1244)
6/30/2004 5:19:20 PM
On Wed, 30 Jun 2004 11:08:45 +0100
"I spy" <s_nedunuri@yahoo.com> wrote:

> Here's another example, also from Robert Martin:
> 
> A simple example: The button and lamp.  The button object needs to
> send the 'turnOn' message to the Lamp.  How shall we accomplish
> this?
> 
>   Button<>-----------Lamp
> 
> Certainly, using the 'has' relationship in this way makes it
> possible for the button to send the 'turnOn' message to the lamp.
> However it also means that Button *depends* upon Lamp.  That makes
> it very difficult for Button to control Fans, Ovens, or Telephones.
> An alternative is "The Abstract Server" design pattern:
> 
> 
>   Button<>----------[]ButtonServer
>                           A
>                           |
>                         Lamp
> 
> 
> Here, ButtonServer is an abstract base class with a pure virtual
> 'TurnOn' method.  Button contains a pointer to ButtonServer.  Lamp
> derives from ButtonServer and implements the TurnOn message.
> 
> Note, that in this case, Button does not depend upon Lamp.  If we
> want button to control a Fan, we can simply derive Fan from
> ButtonServer.
> 
> But what if we have purchased the Fan class from a third party.  We
> can't modify the source code to have it inherit from ButtonServer.
> So we employ the "AdaptedServer" design pattern:
> 
> Button<>--------------[]ButtonServer
>                             A
>                             |
>                             |
>                          FanAdapter<>---------[]Fan
> 
> Here, FanAdapter is a simple class that inherits from ButtonServer
> and which 'has' a Fan.  When the FanAdapter receives the "TurnOn"
> message, it delegates to the Fan object.
> 
> Notice that all these relationships are 'one-way'.  Note that Button
> does not care about anything past the ButtonServer.  We can make
> changes to Fan, FanAdapter, or any other derivative of ButtonServer,
> and Button does not care.
> 
> From what I've seen of FP, higher order functions are used to
> abstract away algorithms, but this kind of dependency inversion is
> rare. In fact, I suspect your average FPer would turn their nose up
> in disgust :-)
> 
> cheers
> -sri

I'll post two different implementations in SML so that we have
something concrete to talk about and criticize.  The first is simpler
and uses a single higher order function to abstract out the process of
turning on:

fun buttonDoingItsThing (..., turnOn) =
  [definition of what a button does that can call turnOn]

Now we can call buttonDoingItsThing wherever we like and pass in a
function to turn on the appropriate device:

....
  buttonDoingItsThing (..., turnOnLamp)
....

If the function for turning on a fan that was written by somebody else
doesn't do exactly what we want we can wrap it in another function.
We don't need to name this function if we don't want to, probably
because what it does is so trivial:

....
  buttonDoingItsThing (..., fn () => ... turnOnFan ... )
....


If we want to get fancier, we can use a module system like SML's
signatures, structures and functors.  Here we have a signature for
something that can be turned on:

signature TurnOnableThing = sig
  type turn_onable_thing

  val turnOn turn_onable_thing -> unit
end

and a lamp implementation of that signature:

structure Lamp : TurnOnableThing = struct
  type turn_onable_thing = [definition of lamp type]

  fun turnOn lamp = [definition of how to turn on a lamp]
end

and the opaque fan implementation and a wrapper that subscribes to the
TurnOnableThing signature:

structure Fan = [definition of a fan that does not subscribe to the
TurnOnableThing signature]

structure FanWrapper : TurnOnableThing = struct
  type turn_onable_thing = Fan.[something]

  fun turnOn fan = ... Fan.[something] ...
end


So are there some dependences in the code that I've written
(hierarchical or otherwise) that are not present in the OO
implementation suggested by your drawings?

Benjamin
0
benjaminy (25)
6/30/2004 5:24:23 PM
I spy wrote:
>
> Notice that all these relationships are 'one-way'.  Note that Button
> does not care about anything past the ButtonServer.  We can make
> changes to Fan, FanAdapter, or any other derivative of ButtonServer,
> and Button does not care.
>
> From what I've seen of FP, higher order functions are used to
> abstract away algorithms, but this kind of dependency inversion is
> rare. In fact, I suspect your average FPer would turn their nose up
> in disgust :-)

I don't really see the point in calling all of that stuff "dependency
inversion," other than to have some jargon.  Inversion from what?  Why
presume there's some 'preferred' way to arrange dependencies?  Your example
is just deciding what's going to depend on what.  The vaunted
'AdaptedServer' pattern is simply a fancy way of saying you inserted a level
of indirection to translate between components you couldn't change.  Big
deal.

-- 
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
6/30/2004 6:29:50 PM
"I spy" <s_nedunuri@yahoo.com> escreveu na mensagem
news:2kfhpcF1mifdU1@uni-berlin.de...

[snip]

> To continue Robert Martin's example, then, do you abstract out strings,
> devices, and files into streams in your code and then pass around the
> appropriate "driver"?

First I have two things to say: I was a Java programmer until very recently
and I have read almost everything written by RCM, so IMHO I understand was
are you trying to say.

Saying that such form of abstraction is so common that people don't give it
a name. The original program could be written as (all code tested in Hugs
version Jan 2001 beta):


    readKeyboard :: IO (Maybe Char)
    readKeyboard = return Nothing  -- dummy implementation

    writePrinter :: Char -> IO ()
    writePrinter _ = return ()     -- dummy implementation

    copy' :: IO ()
    copy' =
        do {mx <- readKeyboard;
            case mx of {
                Just x -> do {writePrinter x; copy'};
                Nothing -> return ()}}

    --usage
    copy'

So we have a copy' function that depends on two other functions (i.e.
readKeyboard and writePrinter). Now we have to write to either the printer
or to the disk and the disk writing function has this type signature:

    writeDisk :: Char -> IO ()
    writeDisk _ = return ()     -- dummy implementation

We could use the same enum-based solution:

    data OutputDevice = Printer | Disk

    copy'' :: OutputDevice -> IO ()
    copy'' d =
        do {mx <- readKeyboard;
            case mx of {
                Just x -> do {case d of {
                                  Printer -> writePrinter x;
                                  Disk    -> writeDisk x};
                              copy'' d};
                Nothing -> return ()}}

    --usage
    copy'' Printer
    copy'' Disk

Not only is this more complex than the original it makes the copy'' function
dependent on the implementations. But in the FP world such kind of solution
would probably not even be thought because every FP enthusiast would see
that the signatures of writePrinter and WriteDisk are equal so he can
parametrize the copy on the destination based on the signature alone:

    copy''' :: (Char -> IO ()) -> IO ()
    copy''' output =
        do {mx <- readKeyboard;
            case mx of {
                Just x -> do {output x;
                              copy''' output};
                Nothing -> return ()}}

    --usage
    copy''' writePrinter
    copy''' writeDisk

The input can be parametrized as well:

    copy :: (Char -> IO ()) -> IO (Maybe Char) -> IO ()
    copy output input =
        do {mx <- input;
            case mx of {
               Just x -> do {output x; copy output input};
               Nothing -> return ()}}

And the dependency is inverted just like in RCM's solution. Now there's a
catch on my example, because I explicit declared the type of the
input/output functions. If we let the compiler infer the types we have a
more generic type (for free):

    copy :: Monad m => (a -> m b) -> m (Maybe a) -> m ()

That is the input and output can be of any kind of Monad (as long as they're
the same Monad) and it can copy any kind of input to any kind of output.
That's why all FP enthusiasts say classes aren't needed in many problems.

> Here's another example, also from Robert Martin:
>
> A simple example:  The button and lamp.  The button object needs to
> send the 'turnOn' message to the Lamp.  How shall we accomplish this?

[snip]

> From what I've seen of FP, higher order functions are used to abstract
away
> algorithms, but this kind of dependency inversion is rare. In fact, I
> suspect your average FPer would turn their nose up in disgust :-)

This is very interesting because I was re-reading this problem a couple of
weeks ago and tried to come up with a solution in Haskell for it:


module Lamp where
    import IOExts   -- We need those to use IORef (which is a kind of
                    -- first-class variable in Haskell)

-- Device is just sugar for the type of a tuple with three functions. We
could
-- just use the tuple type (IO Bool, IO (), IO ()) and the result would be
the same
-- The "Device" on the rhs is a data constructor.
    data Device = Device {isOn :: IO Bool, turnOn :: IO (), turnOff :: IO
()}

-- An utility operation to flip a device
    switch (Device isOn turnOn turnOff) =
        do on <- isOn
           if on
              then turnOff
              else turnOn

-- An utility operation to check the status of a device
    printStatus (Device isOn _ _) = isOn >>= (putStrLn . ("> " ++) . show)

-- A simple command line interface to control a device
    server device =
        do command <- getLine
           case command of
               "switch" -> switch device >> server device
               "status" -> printStatus device >> server device
               "quit"   -> return ()
               _        -> printErrorMessage command >> server device
      where printErrorMessage command = putStrLn ("> Unrecognized command: "
++ show command ++ ". Type again.")

-- Makes a new light-bulb
    newLightBulb =
        do state <- newIORef False
           return Device {isOn = readIORef state,
                          turnOn  = writeIORef state True >>  putStrLn ">
I'm on!",
                          turnOff = writeIORef state False >> putStrLn ">
I'm off!"}

-- Uses the server with the light-bulb device
    testLamp = newLightBulb >>= server

Now we can test it with the light-bulb device:

Lamp> testLamp
status
> False
switch
> I'm on!
status
> True
switch
> I'm off!
qiut
> Unrecognized command: "qiut". Type again.
quit


Can the server work with another kind of device, say a Fan? ;-)

Obviously the answer is yes, because the server is only interested in three
functions: isOn, turnOn and turnOff (i.e. the Device interface). In FPLs we
can create this interface in several ways (e.g. a tuple of three functions,
a record of three functions) and there's no need for subtyping or
inheritance for this to work. Both copy and server are higher-order
functions, because their final behavior depends on functions they receive as
parameters.

I hope this helps.

> cheers
> -sri

Best regards,
Daniel Yokomizo.

"I know this isn't the "right" way to do it, but it was quick, easy, and it
works pretty well."
 - John Hughes


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.711 / Virus Database: 467 - Release Date: 25/6/2004

0
6/30/2004 6:34:02 PM
TLOlczyk wrote:
> On Tue, 29 Jun 2004 14:18:09 -0400, Simon Helsen
> <where-X=@-in-shelsenXcomputer.org> wrote:
>
>> On another note, you could wonder why this side-effect free style of
>> programming never took off if I (and many here) claim it is so
>> effective.
>
> I routinely throw out a challenge to FPers
> which they never meet.
>
> Write a fully skinable ( with functionality; write
> skins; read skins; create/modify skins; change skins;
> revert to previous skins ) GUI from a basic
> widget set ( Motif, GTK, QT, MFC, OWL ... no skinable
> functionality included --that's cheating )
> in a side effect free manner.

*First* show me a fully skinnable widget set written in anything!  I've
shopped for such beasts, i.e. things suitable for game development.  I have
not found them.

> **
> Thaddeus L. Olczyk, PhD
>
> There is a difference between
> *thinking* you know something,
> and *knowing* you know something.

-- 
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
6/30/2004 6:38:32 PM
Don Groves wrote:
>
> Your so-called FP challenge is ridiculous. I've never read or
> heard any FPer claim that frou-frou programming (skins, etc.)
> is a strength of FP, or even something an FP-oriented programmer
> would care about, much less spend any time writing that sort of
> teenage stuff. I would wager that most subscribers to this group
> use a program for reasons like functionality, robustness, accuracy,
> reliability - not how 'cool' it looks on the screen.

Well, that's a pile of prejudicial crap on your part.  Game developers are
very much interested in how things look, and last I checked it was a $31
billion industry.

-- 
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
6/30/2004 6:40:10 PM
Simon Helsen wrote:
>
> Maybe you are right. Maybe most programmers are only interested in
> creating graphical user interfaces and fancy-looking (and not
> necessarily useful) applications. Maybe it is true that most
> applications at the end of the day are so simple in terms of their
> logic that FP does not bring much.
>
> [...]
>
> Programmers don't *not* like FP because they cannot program what they
> want. A hybrid language would have easily amended the problem. I want
> to know why there is such an negative bias to recursive side-effect
> free solution. In fact, today in my class, I again noticed that some
> students could not "think" without side-effects. They hardly
> understand the notion.

Well, I already conjectured that some problems are better iteratively
expressed, and some recursively expressed.  I add: knocking GUIs together is
not a recursive problem.  It's an ad-hoc abstraction problem, i.e. unifying
lotsa things that are each individually different.  So why would anyone ever
worry about expressing anything recursively?  In GUI development there's no
industrial need for it.  It is not a parser or a 3D scene graph, there's no
hierarchy worth traversing to perform regular operations upon it.  It's a
bunch of hand-cobbled junk with simplistic message passing.

> Also, your argument is very weak because Smalltalk never took off
> either. Yet, they *invented* the notion of such GUIs and replacable
> skins.

It is easier to see C++ as a successor to Smalltalk paradigms than to see
any FP language in that light.  You cannot measure success only by the
progenitors, you must also look at what they did or didn't spawn.

-- 
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
6/30/2004 6:48:06 PM
I spy wrote:
> "Adrian Hey" <ahey@NoSpicedHam.iee.org> wrote in message
> news:jZmdncMmyMaIKnzdRVn-sA@nildram.net...
>> I spy wrote:
>
>>>> FPers apply this principle every time they define a higher order
>>>> function.
>>> I doubt it.
>>
>> You should doubt your doubt, given your evident inexperience with
>> FP and FPLs.
> And yours obviously with OO? Its clear that a discussion's going to
> get nowhere if you start hurling insults dude.

"Doubting your doubt" is not an insult, and he hasn't hurled a darned thing.

-- 
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
6/30/2004 6:55:02 PM
Matthias Blume wrote:
>
> Look.  I think SML is a very good language, and SML/NJ is a very good
> implementation of it.  I am very fond (and proud) of some of its more
> unique features, and I use it daily.  It won't die any time soon.  On
> the other hand, there are clearly things that can be improved (both
> with SML/NJ and the language in general), so I am not going to make it
> my mission in life to go for "world domination".  Doing so would be a
> waste of time, realistically speaking.  Again, as academics we can do
> only so much.

Correct that to "only want to do so much," and it would be honest.

> We can produce ideas, we can make reasonably good
> implementations of those ideas.  But a commercial compilers will
> always be better (in implementation terms) because more time and
> resources can be devoted to details that are important but
> unpublishable.  And, of course, there is no way to seriously compete
> with a commercial marketing campaign.

This is utter nonsense, as Linux, Perl, and Python have all proven.  The
issue is whether you're willing to get your hands dirty with open source
business models.  You do not personally have to market anything.  All you
have to do is facilitate the efforts of open source volunteers who are
willing to do so.  That means dedicating a percentage of your time to
community organization issues rather than just compiler technical issues.
Minimally, enough time to attract enough volunteers to delegate
responsibilities to them.

And, most importantly, a willingness to accept the input of others and not
get in the way of progress.  This is the usual stumbling block as language
progenitors and populist workadaisics come into contact with one another.

> I think you are reading to much into this.  Linux is a fluke.  Try
> repeating it.  You'll never succeed.

Repeating *what* ?  Putting another OS on the market, or putting significant
open source projects on the market?  The latter is done all the time.  For
instance see http://nebuladevice.cubik.org

> Also, it took and takes someone who makes it his/her life's mission.
> In an academic environment this is nearly impossible.

Hmm, how much time *have* Linus, Larry, and Guido spent in academia?

On the other hand you've got Xavier et al over at INRIA, who are as academic
as they come.  They're certainly not focused on propagating OCaml, their
research comes first.  But neither are they hiding from the light of day and
making excuses.  Usable webpages, mailing lists, and software archives all
exist.  The OCaml community is far more viable than the SML/NJ community,
and that's close to an apples-to-apples comparision.  You might argue that
French government funding matters quite a bit, as far as spreading the word.
But I see it as coming down to what a community is willing to do.  I expect
that the OCaml community is going to resolve its standard library problems
through volunteer labor, at some point.  I just don't know when in the next
year that's really going to happen.

So Matthias, what are you willing or not willing to do?  Enough of the
excuses about what you 'can't' do.  There are far too many successful open
source projects, in particular language projects, to buy that line.  It's
almost like, you've got an open source project without open source culture.

>> I personally do not buy into ESRs explination of everything,
>> but I can see the pattern of how academic research gets developed and
>> "deployed". I understand the reward models of research environments
>> and pretty much certain this failure of research to have direct
>> impact on day to day practice is a systematic faliure.
>
> I guess we just have different ideas of what the purpose of academic
> research should be.

You seem to be taking the position that SML/NJ is "about academia" rather
than about getting SML/NJ used.

-- 
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
6/30/2004 7:42:30 PM
On Wed, 30 Jun 2004 11:40:10 -0700, Brandon J. Van Every 
<try_vanevery_at_mycompanyname@yahoo.com> wrote:

> Don Groves wrote:
>>
>> Your so-called FP challenge is ridiculous. I've never read or
>> heard any FPer claim that frou-frou programming (skins, etc.)
>> is a strength of FP, or even something an FP-oriented programmer
>> would care about, much less spend any time writing that sort of
>> teenage stuff. I would wager that most subscribers to this group
>> use a program for reasons like functionality, robustness, accuracy,
>> reliability - not how 'cool' it looks on the screen.
>
> Well, that's a pile of prejudicial crap on your part.  Game developers 
> are
> very much interested in how things look, and last I checked it was a $31
> billion industry.
>


And exactly how many FP types are game programmers?

And aren't even game programmers interested in functionality,
accuracy, and reliability.
--
dg
0
Don
6/30/2004 7:47:57 PM
On Wed, 30 Jun 2004 11:10:15 +0200
"Gergely Buday" <greg@this.is.not.part.of.my.address.xhvg.hu> wrote:

> Java Swing is a nice abstraction for writing GUIs. I doubt if
> there's a _much_ better way of doing this. And yet there are
> application fields (e.g.  compilers) where FPLs shine.

Antony Courtney (http://www.galois.com/~antony/) has been working on
some very cool functional approaches to user interfaces lately.  I
would love to see some group put the time and energy necessary into
something like this to make a useful functional user interface
library.

Benjamin
0
benjaminy (25)
6/30/2004 7:59:17 PM
On Wed, 30 Jun 2004 11:40:10 -0700, Brandon J. Van Every 
<try_vanevery_at_mycompanyname@yahoo.com> wrote:

> Don Groves wrote:
>>
>> Your so-called FP challenge is ridiculous. I've never read or
>> heard any FPer claim that frou-frou programming (skins, etc.)
>> is a strength of FP, or even something an FP-oriented programmer
>> would care about, much less spend any time writing that sort of
>> teenage stuff. I would wager that most subscribers to this group
>> use a program for reasons like functionality, robustness, accuracy,
>> reliability - not how 'cool' it looks on the screen.
>
> Well, that's a pile of prejudicial crap on your part.  Game developers 
> are
> very much interested in how things look, and last I checked it was a $31
> billion industry.
>


I didn't finish:

The guy proposed a benchmark for FP that is entirely outside
the design concepts of FP. As you pointed out yourself, even
the best imperative languages haven't managed that feat.

Isn't most of that $31 billion spent by teenagers? Far from
being prejudicial, my comments were entirely factual (except
for my opinion of skinning features, which I admit is low ;)
--
dg
0
Don
6/30/2004 8:05:34 PM
In article <20040630155917.358efc97.benjaminy@alumni.cmu.edu>,
Benjamin Ylvisaker  <benjaminy@alumni.cmu.edu> wrote:
>On Wed, 30 Jun 2004 11:10:15 +0200
>"Gergely Buday" <greg@this.is.not.part.of.my.address.xhvg.hu> wrote:
>
>> Java Swing is a nice abstraction for writing GUIs. I doubt if
>> there's a _much_ better way of doing this. And yet there are
>> application fields (e.g.  compilers) where FPLs shine.
>
>Antony Courtney (http://www.galois.com/~antony/) has been working on
>some very cool functional approaches to user interfaces lately.  I
>would love to see some group put the time and energy necessary into
>something like this to make a useful functional user interface
>library.

Wow, yes. Does Fruit enjoy any ongoing maintenance? Integration with
native widget sets would be fantastic.

-- Mark
0
markc8 (213)
6/30/2004 9:35:27 PM
Last spring we had a student work on a version of Fruit that is
integrated with wxHaskell.  I've been working on a releasable version
of this that would have enough of the wxHaskell stuff in it to be
somewhat usable but I'm not sure when I'll be able to get it out.
Antony and I haven't decided whether what I'm doing is good enough to
be an "official" follow on to Fruit.  Fruit uses two different arrows:
the standard Yampa SF arrow (pure and commutative) as well as another
arrow, Box, which is impure and non-commutative.  I've elected to add
a name supply to the SF arrow, making it impure but still
commutative.  I think Antony would prefer two arrows so that you could
see purity in the arrow type while I like the convenience and clarity
of a single arrow.  But we're both committed to make something that
combines wxHaskell and Fruit.

Just to clarify a bit, in a pure arrow (Yampa's SF) something like

proc... do
  b1 <- button <- bconfig
  b2 <- button <- bconfig

would yield identical signals for b1 and b2.  To create unique names
for these buttons you would have to add a name supply or place the
buttons in context, for example laying them out in separate places.
The student project used layout position as the name for objects on
the screen but this doesn't scale up well and I'm not sure this works
correctly when the configuration changes dynamically.  If the arrow
contains a name supply then "b1" and "b2" can be separate objects. 

Of course, you lose something when you no longer have purity in the
arrow but on the other hand purity at this level may not be as
important.  Commutativity is important, however, or you lose parallel
composition.  If the meaning of the GUI is sensitive to the ordering
of the subcomponents in a proc that's a bad thing.  If purity of SF
turns out to be problem I could adopt a two arrow design.

I've also cut corners a bit on the container issue.  A GUI system
makes a lot of use of containment, for example frames contain
widgets.  This is typically implemented by passing an argument to an
object that determines its container on initialization.  In the general
case, we need to use dynamic collections in Yampa to capture the
lifetimes of objects within a container.  But most of the time
containers maintain the same set of sub-objects throughout their
lifetime and it's awkward to build a dynamic collection which is in
fact static.  You also lose the simple mutually recursive naming of
signals when your objects are down inside a dynamic collection.  I've
punted on this issue by passing the parent of an object as a psuedo
dynamic parameter, as follows: 

      fr      <- frame  [text := "Close me"]    -< [layout := widget b]
      b       <- button [text := "End it all"]  -< (fr, [])

My arrow doesn't quite commute because "fr" has to come before "b" to
make initialization come out right.  That's not ideal but I couldn't
figure out a way to work what I wanted into arrow notation.  Right
now, a signatire such as "a -> SF b c" denotes a component with static
parameter "a" while "b" and "c" are the dynamic signals in and out of
the component.  I can get a static output using a signature such as 
"a -> (SF b c, d)" but I can't cascade these nicely in arrow
notation.  Last I talked to Antony, he was quite unimpressed with my
solution to this problem.  The student project didn't address this
issue though.  I still haven't got the dynamic collection stuff
completely working but there are no technical reasons we can't handle
dynamic creation and deletion of objects within a frame.

Anyway, that's a quick tour through the design space.  We'll announce
something later this summer and hope to demo at the Haskell workshop.

   John

0
6/30/2004 10:42:50 PM
In article <kbhdssd5w5.fsf@ragged.cs.yale.edu>,
John Peterson  <peterson-john@cs.yale.edu> wrote:
(snip)
>of a single arrow.  But we're both committed to make something that
>combines wxHaskell and Fruit.
(snip)
>Anyway, that's a quick tour through the design space.  We'll announce
>something later this summer and hope to demo at the Haskell workshop.

This is fantastic news - thanks for all the information! I'll
certainly be eager to try out the results of such efforts.

-- Mark
0
markc8 (213)
6/30/2004 11:32:11 PM
I spy wrote:

> "Adrian Hey" <ahey@NoSpicedHam.iee.org> wrote:
> 
>> I spy wrote:
> 
>>> The absence of frameworks (as an example) in the FP world shows
>>> its not a commonly used principle.
>> 
>> Just because FPers don't call thier frameworks "frameworks" doesn't
>> mean they don't exist.
> 
> Hmm..lessee.. what do they call them then?

They have more design patterns, less frameworks.

Frameworks have a disturbing lock-in tendency. They usually cannot be 
combined with each other, particularly GUI frameworks. I'm glad that few 
frameworks exist in the FPL world :-)

Now for the design patterns that I have seen: Monads. Arrows. Combinator 
libraries.

(All of these are often considered rocket science, but they really are 
quite simple concepts. It's just that the terminology comes from a 
rather esoteric branch of mathematics, so people stand there, gaping 
wide-mouthed and wide-eyed at them...)

Regards,
Jo
0
jo427 (1164)
6/30/2004 11:52:49 PM
Matthias Blume wrote:

> "Daniel C. Wang" <danwang74@hotmail.com> writes:
> 
> 
>>Matthias Blume wrote:
>>{stuff deleted}
>>
>>>You are being extremely unfair, and you know it.  What "fiasco"?
>>>What
>>>"stupidities"?  Be glad John and (I believe) Emden are not reading
>>>netnews, otherwise a big, serious apology would be in order.  And by
>>>this I don't mean:
>>
>>They can't ship a tarball of the webpages because of the copyright
>>issues with the publisher. An API that I can't get in electronic form
>>is absolutely useless.
> 
> 
> Now, this takes the prize for the lamest charge ever!
> 
>     wget -r http://www.standardml.org/Basis/

As I understand it. It is not legal for me to *redistrbuite* the webpages as 
a tarball. This was a condition placed on by the publisher.

  Copyright � 2004 AT&T and Lucent Technologies. All rights reserved.

  Permission is granted for internet users to make one paper copy for their
  own personal use. Further hardcopy reproduction is strictly prohibited.
  Permission to distribute the HTML document electronically on any medium
  other than the internet must be requested from the copyright holders by
  contacting the editors.

There is no similar restriction placed on the APIs for Java. The basis 
authors should have balked at this requirement and just published the whole 
thing electronically.

{stuff deleted}
> It takes care of design to produce something people will be willing to
> stay in sync with.  It also takes care (and time!) to keep 400+ pages
> internally consistent.  About the other things one can argue, and the
> process has certainly not been optimal.  But just standing on the
> outside and throwing dirt around doesn't help.

I'm complaining that the process has been more than suboptimal that there is 
a fundamental problem with the processes used to develop it and as an end 
user I feel there should be a serious reevaluation of the process. I do not 
consider this throwing dirt.

It would have been fine to electronically publish a "official draft", and 
have the end users pickup on bugs and debug the spec in a collborative 
fashion. The intention to creat a dead tree version has made the process 
inefficent from an end-user standpoint.

> My very limited archive (9/03-now) of the Basis discussion mailing
> list has around 300 messages.  (None from Dan Wang, though.)
> So, yes, the process has to be lively.  And, yes, it is.
> 

How does one discover that such a mailing-list exists?
One would expect to find a link to it on some SML or SML/NJ webpage. (I can 
only find it via google, which turns up a mailman interface to it.. and darn 
the archive is closed. I'm sure I could join, without a problem if I knew 
such a list existed.) Perhaps, I did know, but I'd be hard pressed to 
imagine an "outsider" figuring this out. The process is closed it should be 
open.

{stuff deleted}
> Look.  I think SML is a very good language, and SML/NJ is a very good
> implementation of it.  I am very fond (and proud) of some of its more
> unique features, and I use it daily.  It won't die any time soon.  On
> the other hand, there are clearly things that can be improved (both
> with SML/NJ and the language in general), so I am not going to make it
> my mission in life to go for "world domination".  

As I understand it the SML97 Standard also has some idiotic issue with it 
that will likely prevent any official revision of it to occur.

{stuff deleted}
> Doing so would be a
> waste of time, realistically speaking.  Again, as academics we can do
> only so much.  We can produce ideas, we can make reasonably good
> implementations of those ideas. 

I assume you will be planning on producing a few good students along the way 
  too? :)

> But a commercial compilers will
> always be better (in implementation terms) because more time and
> resources can be devoted to details that are important but
> unpublishable.  And, of course, there is no way to seriously compete
> with a commercial marketing campaign.

Do you consider gcc a commercial compiler? This academic/commerical 
dichotomy is completely the wrong way to think about things.

{stuff deleted}
> The long-term outcome has noting to do with the development model.
> Long-term outcome is extremely weakly (if at all) related to how the
> language and one particular implementation are being developed.  Also,
> I don't see how a "bazaar" approach could possibly deal with a
> language like SML.

When speaking about the structure of the core language. I tend to agree with 
you but in terms of libraries and related utilities, one only has to look at 
the wide spectrum of languages that adopt a "bazaar" model for the core 
libraries.

{stuff deleted}
> I think you are reading to much into this.  Linux is a fluke.  Try
> repeating it.  You'll never succeed.
> Also, it took and takes someone who makes it his/her life's mission.
> In an academic environment this is nearly impossible

Hmm.. do you consider MySQL, Apache, Perl, PHP, Python, to be flukes?

{stuff deleted}
> I guess we just have different ideas of what the purpose of academic
> research should be.

So, do you disagree with my claim that academic research does not have a 
reward system that leads to direct impact on day to day practice? Or are you 
  saying that no one should have that expectation in the first place?  There 
are very few researchers I know who will claim to their funding agency that 
what they are doing will have no direct impact on the state of the art.

BTW if anything, I'm only complaining that there is something wrong with 
reward models of research in general. The systems that support research seem 
either to be aimed at maximizing profit or maximizing the creation of dead 
trees, both models seem inefficent.

I'm letting this thread die. I think it's clear that their are philsophical 
differences and that is in some sense the whole point. We seem not to 
disagree about the reality of the situations just about whether one should 
be satsifed with it or not. I for one would not find it shocking for someone 
to be very disappointed with the state of the SML/NJ universe and SML in 
general. I however expect the care takers of SML to be more thougthful in 
ensuring SML continue to be a viable language. I personally, am not 
encouraged by the signs that I can observer.
0
danwang742 (171)
7/1/2004 4:17:51 AM
Don Groves wrote:
{stuff deleted}
> Isn't most of that $31 billion spent by teenagers? 

Umm.. no...

http://www.planetgamecube.com/news.cfm?action=item&id=3656
0
danwang742 (171)
7/1/2004 4:26:01 AM
On Wed, 30 Jun 2004 12:47:57 -0700, Don Groves <(. (@ dgroves
ccwebster) net))> wrote:

>On Wed, 30 Jun 2004 11:40:10 -0700, Brandon J. Van Every 
><try_vanevery_at_mycompanyname@yahoo.com> wrote:
>
>> Don Groves wrote:
>>>
>>> Your so-called FP challenge is ridiculous. I've never read or
>>> heard any FPer claim that frou-frou programming (skins, etc.)
>>> is a strength of FP, or even something an FP-oriented programmer
>>> would care about, much less spend any time writing that sort of
>>> teenage stuff. I would wager that most subscribers to this group
>>> use a program for reasons like functionality, robustness, accuracy,
>>> reliability - not how 'cool' it looks on the screen.
>>
>> Well, that's a pile of prejudicial crap on your part.  Game developers 
>> are
>> very much interested in how things look, and last I checked it was a $31
>> billion industry.
>>
>
>
>And exactly how many FP types are game programmers?
>
I see. And it never once occured to you that if there were many
FP types that are game programmers, then FP would be much
more popular precisely because the ranks of FP programmers
would be swollen by game programmers?

So today you exclude games programmers. Tomorrow you eclude
people writing web applications. The day after that you  want to
exclude programmers who interface with databases a lot. 

It seems to me that most FPers don't want FP to become enormously 
popular. They would rather if stay unpopular so that they can
go around shouting what geniuses they are because they know
"esoteric" languages. ( Esoteric  meaning few people use the
languages. Never mind that they deliberately chased away the people. )



The reply-to email address is olczyk2002@yahoo.com.
This is an address I ignore.
To reply via email, remove 2002 and change yahoo to
interaccess,

**
Thaddeus L. Olczyk, PhD

There is a difference between
*thinking* you know something,
and *knowing* you know something.
0
olczyk2002 (317)
7/1/2004 4:26:58 AM
On Wed, 30 Jun 2004 11:40:10 -0700, "Brandon J. Van Every"
<try_vanevery_at_mycompanyname@yahoo.com> wrote:

>Don Groves wrote:
>>
>> Your so-called FP challenge is ridiculous. I've never read or
>> heard any FPer claim that frou-frou programming (skins, etc.)
>> is a strength of FP, or even something an FP-oriented programmer
>> would care about, much less spend any time writing that sort of
>> teenage stuff. I would wager that most subscribers to this group
>> use a program for reasons like functionality, robustness, accuracy,
>> reliability - not how 'cool' it looks on the screen.
>
>Well, that's a pile of prejudicial crap on your part.  Game developers are
>very much interested in how things look, and last I checked it was a $31
>billion industry.

Brandon, most FP programmers don't care if the gaming industry is
making $31 billion. Many don't think that programmers should be paid
to program. Many are communists. ( Even though they don't know
what exactkly communism is. When you discuss their "opinions"
on economy, communisim is almost exactly what they describe. )
Mostly they make what money they make by leaching off the rest of
us. Either working for Universities and "making" their money off of
government grrants, or working for research departments of large
firms. That is until those firms start losing money then make cut
backs. As Mathias fully knows.


The reply-to email address is olczyk2002@yahoo.com.
This is an address I ignore.
To reply via email, remove 2002 and change yahoo to
interaccess,

**
Thaddeus L. Olczyk, PhD

There is a difference between
*thinking* you know something,
and *knowing* you know something.
0
olczyk2002 (317)
7/1/2004 4:26:59 AM
On Wed, 30 Jun 2004 11:38:32 -0700, "Brandon J. Van Every"
<try_vanevery_at_mycompanyname@yahoo.com> wrote:

>
>TLOlczyk wrote:
>> On Tue, 29 Jun 2004 14:18:09 -0400, Simon Helsen
>> <where-X=@-in-shelsenXcomputer.org> wrote:
>>
>>> On another note, you could wonder why this side-effect free style of
>>> programming never took off if I (and many here) claim it is so
>>> effective.
>>
>> I routinely throw out a challenge to FPers
>> which they never meet.
>>
>> Write a fully skinable ( with functionality; write
>> skins; read skins; create/modify skins; change skins;
>> revert to previous skins ) GUI from a basic
>> widget set ( Motif, GTK, QT, MFC, OWL ... no skinable
>> functionality included --that's cheating )
>> in a side effect free manner.
>
>*First* show me a fully skinnable widget set written in anything!  I've
>shopped for such beasts, i.e. things suitable for game development.  I have
>not found them.
 AFAIK there isn't but others might be ( I wouldn't be suprised if
some framework  includes a Document/View type subsystem which
in the next few years will include skins. ) aware of something. I
simply wanted to preclude someone fobbing off the hard part on
a library written in an imperative style.


The reply-to email address is olczyk2002@yahoo.com.
This is an address I ignore.
To reply via email, remove 2002 and change yahoo to
interaccess,

**
Thaddeus L. Olczyk, PhD

There is a difference between
*thinking* you know something,
and *knowing* you know something.
0
olczyk2002 (317)
7/1/2004 4:27:05 AM
Benjamin Ylvisaker <benjaminy@alumni.cmu.edu> wrote:
> On Wed, 30 Jun 2004 11:08:45 +0100
> "I spy" <s_nedunuri@yahoo.com> wrote:

>> Here's another example, also from Robert Martin:
>> 
>> A simple example: The button and lamp.  The button object needs to
>> send the 'turnOn' message to the Lamp.  

> I'll post two different implementations in SML so that we have
> something concrete to talk about and criticize.  

One problem with this is that in the OO example, the objects are
supposed to have state, and the connections between objects are
supposed to model the relationships of the objects in the "real
world". The state is not made visible in the example. But (pure) FP
programming needs to take a different approach to handle state, so
it's difficult to compare the two examples directly.

Assume for example that the button has a counter which counts how often
it is pressed, and that the lamp can either be a lamp that is just
switched on and off, or a lamp that cycles through n levels of
brightness.

(Of course one can use impure features like the objects in OCaml to
handle this...)

- Dirk
0
dthierbach (210)
7/1/2004 5:49:51 AM
Quoth Dirk Thierbach <dthierbach@gmx.de>:
| Benjamin Ylvisaker <benjaminy@alumni.cmu.edu> wrote:
....
|> I'll post two different implementations in SML so that we have
|> something concrete to talk about and criticize.  

| One problem with this is that in the OO example, the objects are
| supposed to have state, and the connections between objects are
| supposed to model the relationships of the objects in the "real
| world". The state is not made visible in the example. But (pure) FP
| programming needs to take a different approach to handle state, so
| it's difficult to compare the two examples directly.
|
| Assume for example that the button has a counter which counts how often
| it is pressed, and that the lamp can either be a lamp that is just
| switched on and off, or a lamp that cycles through n levels of
| brightness.
|
| (Of course one can use impure features like the objects in OCaml to
| handle this...)

See appended example in O'Haskell.  Thought it might be interesting
in this context, because
 - I'm using O'Haskell for its reactive objects, to handle the state,
   but arguably not in an impure way -- they're supposed to be
   interchangeable in principle with Haskell monads, so this isn't
   more impure than a typical Haskell program anyway.
 - O'Haskell is described by its author as an object oriented
   imperative language, but I don't think this example shows the
   OOP approach that has been described here, but rather is only
   superficially OO.  O'Haskell declines to implement the OOP
   feature I believe we call "open recursion", so subclassing
   is significantly limited.

(Also note that O'Haskell (http://www.cs.chalmers.se/~nordland/ohaskell/)
is _not_ a supported, practical programming language for real applications.)

	Donn
------------
module Main (main) where

struct ACDevice =
	switchTo :: Integer -> Action

fan speed env = template
		on := False
	in let
		switchTo volts = action
			if volts > 0
				then do
					on := True
					env.putStrLn ("fan " ++ (show speed)
						++ " rpm")
				else do
					on := False
					env.putStrLn "fan off"
	in struct ..ACDevice

lamp watts env = template
		on := False
	in let
		switchTo volts = action
			if volts > 0
				then do
					on := True
					env.putStrLn ("lamp " ++ (show watts)
						++ " watts")
				else do
					on := False
					env.putStrLn ("lamp off")
	in struct ..ACDevice

struct Button =
	press :: Integer -> Action

button dev env = template
	in let
		press down = action
			if down > 0
				then do
					env.putStrLn "snick"	
					dev.switchTo 110
				else do
					env.putStrLn "sneck"
					dev.switchTo 0
	in struct ..Button

main env = do
	l <- lamp 60 env
	f <- fan 400 env
	bl <- button l env
	bf <- button f env
	bf.press 1
	bl.press 1
	bl.press 0
	bf.press 0
0
donn (251)
7/1/2004 8:04:49 AM
"Adrian Hey" <ahey@NoSpicedHam.iee.org> wrote in message
news:Rd6dna-4LdomOH_dRVn-sQ@nildram.net...
> I spy wrote:
>
> > Fine, then how many FP articles or books talk about any of these things
> > today?
>
> I don't know, you'll have to count them yourself if this an issue for you.
My (admittedly somewhat limited) search tells me the answer is statistically
zero. OTOH they are quite common in any OO discussion. I think they are
useful principles, and IMHO they are worth analyzing and integrating into FP
development, to the extent they fit. Frankly, I don't see what there is to
get worked up about in that sentiment, but, as I see from this newsgroup, it
has many FPers frothing at the mouth.

> > Its clear that a discussion's going to get nowhere if you start hurling
> > insults dude.
>
> Sorry "dude". It's certainly true I do get a little hacked off at people
> who assume they know FP despite having never used any FPL, even once. I've
> been using them in one form or another for over 15 years and I still get
> surpised by their expressive power and the stuff folk come up with.
>
> But, perhaps I was hasty to assume that you were such a person.
>
> >> Just because FPers don't call thier frameworks "frameworks" doesn't
mean
> >> they don't exist.
> > Hmm..lessee.. what do they call them then?
>
> They call them "libraries", or maybe "combinator libraries".
No, libraries are not the same as frameworks. Frameworks employ inversion of
control (also known as the Hollywood Principle ie "Dont Call Us, We'll Call
You"), where the application resides in the framework, and calls out to your
code. In fact the complete opposite of libraries. Neither are combinator
libraries, which are closer to DSL constructs. (I shouldn't have to add
this, but again, for the sake of peace and harmony, let me add tha this does
*not* make libraries or combinators or any other FP construct useless. In
fact, I think that combinators are the key to effective DSL usage. Sheesh.)

cheers
-sri

> Regards
> --
> Adrian Hey
>
>


0
s_nedunuri (52)
7/1/2004 8:51:56 AM
"Joachim Durchholz" <jo@durchholz.org> wrote in message
news:cbvjl6$kb4$1@news.oberberg.net...
> I spy wrote:
>
> > "Adrian Hey" <ahey@NoSpicedHam.iee.org> wrote:
> >
> >> I spy wrote:
> >
> >>> The absence of frameworks (as an example) in the FP world shows
> >>> its not a commonly used principle.
> >>
> >> Just because FPers don't call thier frameworks "frameworks" doesn't
> >> mean they don't exist.
> >
> > Hmm..lessee.. what do they call them then?
>
> They have more design patterns, less frameworks.
>
> Frameworks have a disturbing lock-in tendency. They usually cannot be
> combined with each other, particularly GUI frameworks. I'm glad that few
> frameworks exist in the FPL world :-)
Yes framework composition is a problem. But this wasn't a discussion of
framework pros and cons - a discussion that I don't mind having - it was
about recognizing the prevalence of certain programming principles.

> Now for the design patterns that I have seen: Monads. Arrows. Combinator
> libraries.
Sorry I know nothing about Arrows, but it would be more accurate to equate
monads with classes, and commands with methods, than with entire frameworks
(and ahem talking about composition, monad composition is still a problem).
Combinator libs seem closer to DS libraries. Again a different kettle of
fish

> (All of these are often considered rocket science, but they really are
> quite simple concepts. It's just that the terminology comes from a
> rather esoteric branch of mathematics, so people stand there, gaping
> wide-mouthed and wide-eyed at them...)
Too true. But for most programmers who have very little S/E background, they
*are* esoteric.
cheers
-sri

> Regards,
> Jo


0
s_nedunuri (52)
7/1/2004 8:58:19 AM
"Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com> writes:

> Hmm, how much time *have* Linus, Larry, and Guido spent in academia?

Linus Torvalds has obtained a Master's degree from the University of
Helsinki, Finland, majoring in Computer Science. (He has subsequently
been awarded honorary doctorates elsewhere.)

During a part of this time, he was an employee in research projects of
the department. (Not doing Linux but something else.)  He may also
have been a TA in some courses, but of this I am not sure.

Hence Linus has spent more time in academia than the average student.
(More precisely, about the same amount of time, but partly doing
things beyond the studies of the average student.)

-- 
							Matti Nyk�nen
0
7/1/2004 9:35:10 AM
On Tue, 29 Jun 2004 18:36:20 -0400, Simon Helsen
<where-X=@-in-shelsenXcomputer.org> wrote:

>TLOlczyk wrote:
>
>> I routinely throw out a challenge to FPers
>> which they never meet.
>> 
>> Write a fully skinable ( with functionality; write
>> skins; read skins; create/modify skins; change skins;
>> revert to previous skins ) GUI from a basic
>> widget set ( Motif, GTK, QT, MFC, OWL ... no skinable
>> functionality included --that's cheating )
>> in a side effect free manner.
>> 
>> Tell any fledgling programmer how hard this is and they
>> go running awat from FP as fast as they can.
>> 
>> FP isn't popular, because programmers don't like FP.
>
>Maybe you are right. Maybe most programmers are only interested in 
>creating graphical user interfaces and fancy-looking (and not 
>necessarily useful) applications. 
Of all the code I wrote GUi and nonGUI, the single most valuable
piece was for an investment management company. In a grid they
displayed the difference between the value of an option and the
price of an option. Traders would often make a wrong trade
because they would fail to see a negative sign in this column.
So I wrote a little piece of code:
if(result<0)
   edit_box->color=red;
else
   edit_box->color=black;
which I added to the application.
Those four lines literally saved the company millions.
I would hardly call that not useful. Fact is that that is
probably more useful than anything Simon has ever written
or hopes to write. By a factor of 100.


>Maybe it is true that most 
>applications at the end of the day are so simple in terms of their logic 
>that FP does not bring much.
>
Utter bullshit. I have not seen anything ever written in an FP that
matches the complexity of NT or Linux or MySql or Excel or CVS. 
There is no evidence that FP would bring anything to these large
applications.

>But people do not complain about Micros**t software because of the lack 
>of nice GUIs (well, I am sure one or the other Mac-lover will complain 
>at this point). They complain because subtle incomprehendable bugs slip 
>into programs that cause them to crash, misperform or others. The 
>*logic* of these programs fails.
>
Please stop with the crap. If the bugs in MS products are
incomprehensible then we would never know about them would we?
As much as FPers ( and others ) would like to think it is choice of
language which is responsible for MS bugs, the fact is that it
is more the basic fact that they hire poor prorammers, and have 
poor methodologies. That and the fact that they don't care
if they ship a lot of bugs.

Another company to compare to is HP which ships tons of
embedded software, which generally do not have any
major bugs in the, If they did ship a printer with a major bug, 
the recall would cost them dearly. So they make sure to
ship without bugs, and they do it in C and assembler.

>As somebody else said, that is not the point. There are nice GUI 
>frameworks for FPs, that, of course, do use side-effects.
It seems strange that all the Fpers all glom onto the GUI aspect
and miss the real point of the problem. It is also very strange
that all these people who claim to have a superior handle
on abstraction ( they don't ) can't seem to understand the
concept of producing a prototypical problems with the
idea of abstracting aspects of the solution.

Put simply, the problem is a sample problem. It's solution
in the OO world, involves many techniques that *real
programmers* use every day. You can't solve the problem,
you can solve most of the problems encountered every day
in real world programming. Like Hilbert's problems. That's 
why I propose this problem. Of course since modern FP can't
handle it ...

>Programmers don't *not* like FP because they cannot program what they 
>want. 
Aside from academics programmers come in two flavors ( by 
definition ): profesional and amateur.

Profesional programmers ( at least successfull profesional programmers
) get paid for what the finish. If a programming language
does not allow them to do something that they want ( presumably 
something they get paid for ) they will not use that language.

Amateur programmers program for themselves and others.
In either case they want something in the hands of users.
I know of no amateur programmer that will start a project
he knows he can't finish. They will not use a programming
language that lets them write their programmers.

In other words if FP does not allow them to write what they want,
they will not use FP. If FP makes their lives easier, then they
will use it. If it makes their lives harder, then they will not.
Gee I wonder why they *don't* use FP.

>A hybrid language would have easily amended the problem. 

Then why don't they make it. 

> I want to 
>know why there is such an negative bias to recursive side-effect free 
>solution. 

I wonder why FPers have this obsessive need to force people into
writing recursive side-effect free code. Got to be some kind of anal
control thing I supose.


string input_file(fstream f)
{ 
      string retval;	 
      char c;
      while(!f.eof())
      {
            f.read(c,1);	
            retval+=c;
      }
     return retval;
}

let input_file f=
    let s =
      if (eof f) 
          ""
     else
        let c= read_byte f in
           Str.concat (string_of_char c) (input_file f)
   in
                 s;;

	
>In fact, today in my class, I again noticed that some students 
>could not "think" without side-effects. They hardly understand the notion.
>

Or maybe they did, but just didn't like it.
BTW if they didn't then it says something
about the "naturalness" of FP.

>Also, your argument is very weak because Smalltalk never took off 
>either. 
Which just shows your ignorance of real world programming. 
Smalltalk did "take off" before C++, but Smalltalk had poor
preformance. Especially on the machines at that time. So people
took C++ over Smalltalk because they felt the preformance hit was
too high at the time.

Another thing about Smalltalk is that it forced you to write using OO.
We can see what that got them.

Of course that is all moot since the problem was never about the
difficulties in writing a GUI. The problem was about all the aspects
in the problem that make it hard to solve the problem in FP.


The reply-to email address is olczyk2002@yahoo.com.
This is an address I ignore.
To reply via email, remove 2002 and change yahoo to
interaccess,

**
Thaddeus L. Olczyk, PhD

There is a difference between
*thinking* you know something,
and *knowing* you know something.
0
olczyk2002 (317)
7/1/2004 9:38:10 AM
I spy wrote:
> 
> No, libraries are not the same as frameworks. Frameworks employ inversion of
> control (also known as the Hollywood Principle ie "Dont Call Us, We'll Call
> You"), where the application resides in the framework, and calls out to your
> code.

That is an artificial distinction that makes no sense in FP, in 
particular in lazy languages, where control is inverted *by default*!

   - Andreas

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

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

0
rossberg (600)
7/1/2004 10:05:05 AM
"I spy" <s_nedunuri@yahoo.com> writes:

> No, libraries are not the same as frameworks. Frameworks employ inversion of
> control (also known as the Hollywood Principle ie "Dont Call Us, We'll Call
> You"), where the application resides in the framework, and calls out to your
> code. In fact the complete opposite of libraries.

Doesn't a higher-order function cover this idea?  You give your code
to the HO function, and it calls it in some way of its own choosing.
This seems to me to be very similar to the "inversion of control"
idea, and all combinator libraries work in this fashion.

Regards,
    Malcolm
0
7/1/2004 10:39:56 AM
I spy wrote:
> No, libraries are not the same as frameworks. Frameworks employ inversion
> of control (also known as the Hollywood Principle ie "Dont Call Us, We'll
> Call You"), where the application resides in the framework, and calls out
> to your code. In fact the complete opposite of libraries. Neither are
> combinator libraries, which are closer to DSL constructs. 

"We'll Call You" is a routine aspect of what FPers call "higher order
functions".  Moreover, the "opposite of libraries" is never difficult to
create.  Haskell has 'interact' in the standard Prelude from which a 2-line
framework can be built:
   import Main_
   main = interact main_
To use this framework you just create a module Main_ which defines a
function main_ (from String to String) and your application is complete. 
This framework is for the class of application that in Unix is invoked from
the shell as a "filter".

Now that the "framework" terminology is clarified, let's go back to the
substance:
> > FPers apply this principle every time they define 
> > a higher order function. 
> I doubt it. The absence of frameworks (as an example) in the FP
> world shows its not a commonly used principle.
Looking through the list at http://haskell.org/libraries, I see several that
use inversion of control at the level OOers expect in a framework, e.g.
FRAN.  Have you begun to doubt your doubt yet?

0
news239 (43)
7/1/2004 10:47:32 AM
Daniel C. Wang wrote:

> As I understand it. It is not legal for me to *redistrbuite* the 
> webpages as a tarball. This was a condition placed on by the publisher.
> 
>  Copyright � 2004 AT&T and Lucent Technologies. All rights reserved.
> 
>  Permission is granted for internet users to make one paper copy for their
>  own personal use. Further hardcopy reproduction is strictly prohibited.
>  Permission to distribute the HTML document electronically on any medium
>  other than the internet must be requested from the copyright holders by
>  contacting the editors.

The permission doesn't place any restriction on the format, just on the 
medium.
IOW it's irrelevant whether you republish the thing as tarball, Windows 
Help file, or encoded in Ruritanian, as long as you do it on the 
Internet (as opposed to, say, a CD edition).

> There is no similar restriction placed on the APIs for Java. The basis 
> authors should have balked at this requirement and just published the 
> whole thing electronically.

*shrug* the usual reason for this kind of restriction is that the 
publisher of the paper book wants to make a profit, too. In particular, 
he doesn't want his competitors to rip of the typeset text, publish it, 
and make money from it.

I don't see that the restrictions are serious.

[I can't say anything about the quality of the paper or the process that 
lead to it, since I know neither.]

>> But a commercial compilers will
>> always be better (in implementation terms) because more time and
>> resources can be devoted to details that are important but
>> unpublishable.  And, of course, there is no way to seriously compete
>> with a commercial marketing campaign.
> 
> Do you consider gcc a commercial compiler? This academic/commerical 
> dichotomy is completely the wrong way to think about things.

It's the third possibility.

Given that there is no large open source SML project at this time [*], 
the dichotomy is indeed appropriate.

[*] At least none that I know of.

>> The long-term outcome has noting to do with the development model.
>> Long-term outcome is extremely weakly (if at all) related to how the
>> language and one particular implementation are being developed.  Also,
>> I don't see how a "bazaar" approach could possibly deal with a
>> language like SML.
> 
> When speaking about the structure of the core language. I tend to agree 
> with you but in terms of libraries and related utilities, one only has 
> to look at the wide spectrum of languages that adopt a "bazaar" model 
> for the core libraries.

I think that calls for a language with a C library model: a minimal 
run-time that does just the barest necessities, everything else in the 
library.

In a language like SML (or, for that matter, in any moderately ambitious 
FPL), this would mean a pluggable run-time: an API for plugging in 
modules like the garbage collector, pickling/unpickling, 
multithreading/signal handling/asynchronous stuff, and whatever.

Yes I know it's more work to do it that way. It creates all sorts of 
hassles since you can't change the GC API at a whim if you find that 
things will work more smoothly that way. Language implementors may even 
find that they have to support multiple APIs for the same thing (e.g. 
one API for conservative GC and a slightly different one for cooperative 
GC; multiprocessing is even more varied).

However, I think that would help tremendously. The implementors of such 
a language can concentrate on what they can do best (be it the language 
core proper, or GC, or whatever), and leave all the details that are 
outside their scope of interest to others (who might have their own 
motives for creating top-notch plug-ins, be it GC research, open-source 
fame, or making money).

> {stuff deleted}
> 
>> I think you are reading to much into this.  Linux is a fluke.  Try
>> repeating it.  You'll never succeed.
>> Also, it took and takes someone who makes it his/her life's mission.
>> In an academic environment this is nearly impossible
> 
> Hmm.. do you consider MySQL, Apache, Perl, PHP, Python, to be flukes?

MySQL definitely was, for a long time. It didn't have transactions until 
version 4.0.
(I'm not sure how much of SQL is implemented anyway. MySQL seems to take 
speed more seriously than safety. Which I find distasteful, but that's 
another issue.)

Regards,
Jo
0
jo427 (1164)
7/1/2004 10:54:14 AM
I spy wrote:

> "Joachim Durchholz" <jo@durchholz.org> wrote:
> 
>>Frameworks have a disturbing lock-in tendency. They usually cannot be
>>combined with each other, particularly GUI frameworks. I'm glad that few
>>frameworks exist in the FPL world :-)
> 
> Yes framework composition is a problem. But this wasn't a discussion of
> framework pros and cons - a discussion that I don't mind having - it was
> about recognizing the prevalence of certain programming principles.

Hey, if frameworks are problematic, why do you want them?
FPLs are not into mimicking all the techniques of OO, particularly not 
in mimicking those that have problems.

>>Now for the design patterns that I have seen: Monads. Arrows. Combinator
>>libraries.
> 
> Sorry I know nothing about Arrows,

They are similar to monads, they just have additional information 
channels over those offered by monads.
Or at least that's what I understood about them. My eyes are still 
glazing over when arrow library writers start to ponder things like 
commutability properties of their arrows... which, I'm sure, translates 
into some very practical hands-on programmer-relevant properties of 
these arrow libraries, but I don't know which.

 > but it would be more accurate to equate
> monads with classes, and commands with methods,

That's a gross misrepresentation of monads.
A monad is just a set of collaborating functions that allow you to 
"stick together" a stack of function at runtime, each function taking 
the outputs of the previous function as its input. (The monad is allowed 
to do some systematic additional processing with the intermediate 
results, which is why there is more than just one monad.)

 > than with entire frameworks
> (and ahem talking about composition, monad composition is still a problem).

Hmm... my reflex above was to write "monads are a framework", so it 
seems to fit... maybe it's "the idea of 'monad' is a framework" (which, 
again, qualifies "monad" more as a design pattern).

Monad composition, btw, is less of a problem than you might think. It's 
not possible to automatically compose monads, but you need little glue 
code to create a composite of all monads that you might need. That 
composite monad can then be used just like all the basic monads, without 
the need for boilerplate code. That's a rather mild form of 
composability problem, I'd say... I'd be happy if even using OO design 
patterns was so easy.

>>(All of these are often considered rocket science, but they really are
>>quite simple concepts. It's just that the terminology comes from a
>>rather esoteric branch of mathematics, so people stand there, gaping
>>wide-mouthed and wide-eyed at them...)
> 
> Too true. But for most programmers who have very little S/E background, they
> *are* esoteric.

See my above definition of monads - not very esoteric, I'd say.
(I'm prepared for praises and damnations alike, for doing this kind of 
simplification... I'd prefer corrections though.)

BTW the first contact that most people make with monads is, 
unfortunately, the IO monad which isn't very typical. This leads to all 
sorts of misconceptions, such as the oft-quoted "a monad is for 
composing 'commands'" - which isn't entirely untrue but applies to a lot 
of non-monadic code as well.

Regards,
Jo
0
jo427 (1164)
7/1/2004 11:09:22 AM
TLOlczyk wrote:

> Many [FP programmers] are communists. ( Even though they don't know 
> what exactkly communism is. When you discuss their "opinions" on
> economy, communisim is almost exactly what they describe. )

Communism does have its places and uses. It's unsuitable for organizing
an entire community, of course, and many mistake the atrocities of the
once-Socialist states for consequences of communism (they are
consequences of paying lip service to communism while establishing an
oligarchy).

[Rest of arguments snipped - it's getting off-topic.]

Regards,
Jo
0
jo427 (1164)
7/1/2004 11:15:06 AM
Stefan Axelsson <crap1234@hotmail.com> writes:

> Close. The AXD line of ATM switches has ca 1 million lines of Erlang
> (the logic, failover etc, the 'difficult' stuff), ca 500k lines of C
> (device drivers mostly) and ca 13k lines of Java (management interface
> mostly). If you want the exact line counts as of today you have to ask
> Ulf. :-)

The amount of Erlang code in AXD 301 now exceeds 2 million lines.
So does the amount of C code (i.e. it's more than just drivers ;)

/Uffe
-- 
Ulf Wiger, Senior Specialist,
   / / /   Architecture & Design of Carrier-Class Software
  / / /    Strategic Product & System Management
 / / /     Ericsson AB, Connectivity and Control Nodes
0
ulf.wiger1 (107)
7/1/2004 11:35:37 AM
Don Groves wrote:
> On Wed, 30 Jun 2004 11:40:10 -0700, Brandon J. Van Every
> <try_vanevery_at_mycompanyname@yahoo.com> wrote:
>
>> Don Groves wrote:
>>>
>>> Your so-called FP challenge is ridiculous. I've never read or
>>> heard any FPer claim that frou-frou programming (skins, etc.)
>>> is a strength of FP, or even something an FP-oriented programmer
>>> would care about, much less spend any time writing that sort of
>>> teenage stuff. I would wager that most subscribers to this group
>>> use a program for reasons like functionality, robustness, accuracy,
>>> reliability - not how 'cool' it looks on the screen.
>>
>> Well, that's a pile of prejudicial crap on your part.  Game
>> developers are
>> very much interested in how things look, and last I checked it was a
>> $31 billion industry.
>>
>
>
> And exactly how many FP types are game programmers?

Possibly not enough, if you actually believe the claims of FP.  At this time
I'm investigating it, but I'll suspend judgement until I actually see it
fitting my problems.

> And aren't even game programmers interested in functionality,
> accuracy, and reliability.

Your framing in terms of 'either or' is wrongheaded as far as a game
developer is concerned.

-- 
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
7/1/2004 11:58:04 AM
Don Groves wrote:
>
> The guy proposed a benchmark for FP that is entirely outside
> the design concepts of FP. As you pointed out yourself, even
> the best imperative languages haven't managed that feat.

What the hell is 'the best' imperative language?  I see no call for a
superlative.  *No Language* has implemented an efficient, fully skinnable
GUI widget set.  I've seen some bloated half-assed stuff.  Anyways, we agree
that the proposed design challenge is silly.  A reasonable challenge would
be "show me a FP widget set."

> Isn't most of that $31 billion spent by teenagers?

No, the majority is spent by people over 30.  Which makes sense if you
consider that all the 30-somethings grew up playing games and have higher
incomes than teenagers.

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

"Troll" - (n.) Anything you don't like.
Usage: "He's just a troll."

0
7/1/2004 12:07:27 PM
Joachim Durchholz wrote:
> TLOlczyk wrote:
>
>> Many [FP programmers] are communists. ( Even though they don't know
>> what exactkly communism is. When you discuss their "opinions" on
>> economy, communisim is almost exactly what they describe. )
>
> Communism does have its places and uses. It's unsuitable for
> organizing an entire community, of course, and many mistake the
> atrocities of the once-Socialist states for consequences of communism
> (they are consequences of paying lip service to communism while
> establishing an oligarchy).

The fatal flaw of Communism is that it supposes a special category of
ownership called "ownership by the State."  But if the State owns
everything, then whoever has in-practice control of the State is effectively
the owner by proxy.  We know that human beings always organize themselves to
take advantages of resources and each other, so all that State ownership
does is create a preferred career ladder.  You want to be as high up in the
machinery of the State as possible.

So-called Communism in software development is a little different, because
software can actually be infinitely replicated instead of just being
centrally owned.  Public domain software can literally have no owner.  Once
we start looking at notions of utility, ownership in practice returns
however.  Sure you can run off and do your own thing, but it may not be to
your benefit to provide the 81st version of a similar set of tools.
Possibly nobody will use your bugfixes or even know about your product.  An
organizational + marketing dimension comes into play.  Those that do the
best job of maintaining a common software repository become 'owners' in a
sense, in that people are afraid of the value of the repository being
wrecked.

But, at least in Software Communism it's easier for 'effective ownership' to
change hands.  All you really have to do is provide a more effective
repository.  Of course that takes time, and time is money, so we're really
back to paying for software in some manner....

-- 
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
7/1/2004 12:17:28 PM
TLOlczyk wrote:
>
>> A hybrid language would have easily amended the problem.
>
> Then why don't they make it.

OCaml is such a language.  It is at an early stage of community growth; i.e.
not up to Python levels of popularity yet.  It has a few serious warts: only
31-bit integers, and the C FFI is painful two-step translation shuffle.  I
also consider the lack of 32-bit floats a serious wart, but some kinds of
application writers wouldn't.

> I wonder why FPers have this obsessive need to force people into
> writing recursive side-effect free code. Got to be some kind of anal
> control thing I supose.

They're laboring under the delusion that something great is going to happen
if everyone agrees to do this.  Strategically it's a tempest in a teapot.
FP isn't going to give me a 200% productivity increase.  Dicking around at
the level of textual langauge paradigms just ain't where it's at.  If you're
cobbling it together by hand, you've lost.  No 21st century prize for you.

-- 
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
7/1/2004 12:36:22 PM
TLOlczyk wrote:

> Of all the code I wrote GUi and nonGUI, the single most valuable 
> piece was for an investment management company. In a grid they 
> displayed the difference between the value of an option and the price
> of an option. Traders would often make a wrong trade because they
> would fail to see a negative sign in this column. So I wrote a little
> piece of code: if(result<0) edit_box->color=red; else 
> edit_box->color=black; which I added to the application. Those four
> lines literally saved the company millions. I would hardly call that
> not useful. Fact is that that is probably more useful than anything
> Simon has ever written or hopes to write. By a factor of 100.

You are confounding "valuable for a company" with "valuable for a society".

That color was valuable for that company. It was largely irrelevant for
society as a whole, since the money that that company saved was taken
off from other companies.

There's a tenuous link to global economic value, since things work
somewhat better if traders are making more informed decisions. However,
to have this kind of value, your code (or something equivalent) would
have to be in place in the software of all traders, not just on the
workplaces of the traders in just one company.

>> Maybe it is true that most applications at the end of the day are
>> so simple in terms of their logic that FP does not bring much.
> 
> Utter bullshit. I have not seen anything ever written in an FP that 
> matches the complexity of NT or Linux or MySql or Excel or CVS. There
> is no evidence that FP would bring anything to these large 
> applications.

CVS isn't very complex, so you're erecting quite a low barrier here...
and sieve (exim's server-side mailbox scripting interface and
implementation) is written in an FPL.

>> But people do not complain about Micros**t software because of the
>> lack of nice GUIs (well, I am sure one or the other Mac-lover will
>> complain at this point). They complain because subtle
>> incomprehendable bugs slip into programs that cause them to crash,
>> misperform or others. The *logic* of these programs fails.
> 
> Please stop with the crap. If the bugs in MS products are 
> incomprehensible then we would never know about them would we?

You're wilfully misinterpreting. It's not the bugs that are
uncomprehensible, it's their attribution to concrete faults in the
source code. (Or to settings the configuration. Just kept months to get
that dial-on-demand stuff working again. Just managed today... taking
the entire configuration down and redoing it from scratch did the trick,
with no hint what was *actually* wrong. I once was at that point, and
the "it works" effect was gone after the next reboot, again with no idea
why...)

> As much as FPers ( and others ) would like to think it is choice of 
> language which is responsible for MS bugs, the fact is that it is
> more the basic fact that they hire poor prorammers, and have poor
> methodologies. That and the fact that they don't care if they ship a
> lot of bugs.

Now that's something that I agree with.

> Another company to compare to is HP which ships tons of embedded
> software, which generally do not have any major bugs in the, If they
> did ship a printer with a major bug, the recall would cost them
> dearly. So they make sure to ship without bugs, and they do it in C
> and assembler.

*shrug* I have seen printers that had lots of bugs in their firmware.
Some people in my proximity will violently reject any HP printer...

>> As somebody else said, that is not the point. There are nice GUI 
>> frameworks for FPs, that, of course, do use side-effects.
> 
> It seems strange that all the Fpers all glom onto the GUI aspect and
> miss the real point of the problem. It is also very strange that all
> these people who claim to have a superior handle on abstraction (
> they don't ) can't seem to understand the concept of producing a
> prototypical problems with the idea of abstracting aspects of the
> solution.
> 
> Put simply, the problem is a sample problem. It's solution in the OO
> world, involves many techniques that *real programmers* use every
> day. You can't solve the problem, you can solve most of the problems
> encountered every day in real world programming. Like Hilbert's
> problems. That's why I propose this problem. Of course since modern
> FP can't handle it ...

There's nothing in modern FPLs that prevents them from solving it.
Besides, solutions are in progress (e.g. wxHaskell, OpenGL bindings in
ML, and whatnot). They aren't polished, they haven't been led to
production quality - just like 99% of the other, imperative solutions
that used to exist and have been forgotten.

The problems aren't technical. They are unrelated to FP per se. They are
related to a small user base, so it's less likely that enough people
with a genuine interest and the required skill and time will pop up and
persevere. They are related to a lack of technical resources: searchable
library repositories, tips and advice on programming techniques, etc.

All of this is slowly changing. There's an excellent web page on monads
that gives not only the learner a good introduction, but also gives a
good overview for the casual reader.

Actually I think the most prominent lack right now is that there's
little material for the casual reader. Today's casual readers are
tomorrow's learners, so that's important if you take evangelization
seriously.

>> Programmers don't *not* like FP because they cannot program what
>> they want.
> 
> Aside from academics programmers come in two flavors ( by definition
> ): profesional and amateur.
> 
> Profesional programmers ( at least successfull profesional
> programmers ) get paid for what the finish. If a programming language
>  does not allow them to do something that they want ( presumably 
> something they get paid for ) they will not use that language.

I'm a professional programmer, and not a single language allows me to do
what I want.

I think it's just the opposite: professional programmers know that they
have to strike compromises. They demand that these compromises are
viable. (That's why purist approaches are generally regarded with more
scepticism: purism means that you can't strike a compromise if the
language concept turns out to not work out for some nitty-gritty dark
corner... and we professionals know that such dark corners turn up
despite best intent. Convincing a professional of a purist solution is
possible but far more difficult than with a pragmatic solution.) (That
said, I still like Haskell very much, and I would have tried Haskell if
it had better support for serialization.)

> Amateur programmers program for themselves and others. In either case
> they want something in the hands of users. I know of no amateur
> programmer that will start a project he knows he can't finish. They
> will not use a programming language that lets them write their
> programmers.
> 
> In other words if FP does not allow them to write what they want, 
> they will not use FP. If FP makes their lives easier, then they will
> use it. If it makes their lives harder, then they will not. Gee I
> wonder why they *don't* use FP.

Learning curve.
The point is that FPLs allow them to do everything they want, but they'd
have to sit down for a month or more and learn how to do it. Most
amateurs (and most professionals as well) are not willing to invest that
much effort.

>> I want to know why there is such an negative bias to recursive
>> side-effect free solution.
> 
> I wonder why FPers have this obsessive need to force people into 
> writing recursive side-effect free code. Got to be some kind of anal 
> control thing I supose.

Nonsense.

First, recursion is just the technique needed to write side-effect free
code. Besides, recursion can be and is hidden in HOFs, so FPers aren't
more anal about it than other programmers.

Second, they are anal about side-effect freeness because it has
immediate advantages. Code with side effects tends to be more fragile
than code without it, and this effect increases with program size.

>> In fact, today in my class, I again noticed that some students 
>> could not "think" without side-effects. They hardly understand the
>> notion.
> 
> Or maybe they did, but just didn't like it. BTW if they didn't then
> it says something about the "naturalness" of FP.

"Naturalness" is utterly irrelevant, particularly for an activity that's
so abstract and unnatural as programming. (Playing a musical instrument
requires quite unnatural movements, but nobody cares about that either.)

What counts is programmer productivity and software stability, both
under the constraints of changing requirements.

If FP obtains better results in these disciplines, then so be it; if
that requires an additional month of getting used to it when learning to
program, then so be it.

This discussion happens just because FP advocates feel that there's a
strong potential, and non-advocates don't share that feeling. That's 
unrelated to the question whether FP actually has that potential.

My personal stance here is: the potential exists, demonstrating that to 
non-FPers requires software that wasn't written yet but will be written.

Anyway. The most important push for FP would be the adoption by a highly 
visible actor, such as a large commercial software company or a large 
open-source project.

Such an event can be furthered by advocacy or running code. We've had 
enough of the former, here I agree with the critics; the latter is 
difficult and requires a lot of work, so we can't expect that stuff to 
magically pop up, and that's the point where I disagree with the critics.

Regards,
Jo
0
jo427 (1164)
7/1/2004 12:42:15 PM
TLOlczyk wrote:
> 
> [lot's of ranting]
> 
> Please stop with the crap. If the bugs in MS products are
> incomprehensible then we would never know about them would we?
> As much as FPers ( and others ) would like to think it is choice of
> language which is responsible for MS bugs, the fact is that it
> is more the basic fact that they hire poor prorammers, and have 
> poor methodologies. That and the fact that they don't care
> if they ship a lot of bugs.

Security problems due to simple buffer overflows could not happen in 
decent languages. They cost billions.

> Profesional programmers ( at least successfull profesional programmers
> ) get paid for what the finish. If a programming language
> does not allow them to do something that they want ( presumably 
> something they get paid for ) they will not use that language.

I know that professional programmers in some very real and well-known 
software company used to get paid extra for the number of errors they 
remove. Including errors they introduced themselves.

> let input_file f=
>     let s =
>       if (eof f) 
>           ""
>      else
>         let c= read_byte f in
>            Str.concat (string_of_char c) (input_file f)
>    in
>                  s;;

Man. You don't know much about FP. Using higher-order functions you 
write your own control structures, and don't program them out by hand 
every time:

   input_file f = implode (repeatUntil (\_ -> eof f) (\_ -> read_byte f))

where

   repeatUntil p f = if p () then f () :: repeatUntil p f else []

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

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

0
rossberg (600)
7/1/2004 12:59:31 PM
"Benjamin Ylvisaker" <benjaminy@alumni.cmu.edu> wrote in message
news:20040630132423.36687684.benjaminy@alumni.cmu.edu...
> On Wed, 30 Jun 2004 11:08:45 +0100
> "I spy" <s_nedunuri@yahoo.com> wrote:
>
> > Here's another example, also from Robert Martin:
> >
> > A simple example: The button and lamp.  The button object needs to
> > send the 'turnOn' message to the Lamp.  How shall we accomplish
> > this?
> >
> >   Button<>-----------Lamp
> >
> > Certainly, using the 'has' relationship in this way makes it
> > possible for the button to send the 'turnOn' message to the lamp.
> > However it also means that Button *depends* upon Lamp.  That makes
> > it very difficult for Button to control Fans, Ovens, or Telephones.
> > An alternative is "The Abstract Server" design pattern:
> >
> >
> >   Button<>----------[]ButtonServer
> >                           A
> >                           |
> >                         Lamp
> >
> >
> > Here, ButtonServer is an abstract base class with a pure virtual
> > 'TurnOn' method.  Button contains a pointer to ButtonServer.  Lamp
> > derives from ButtonServer and implements the TurnOn message.
> >
> > Note, that in this case, Button does not depend upon Lamp.  If we
> > want button to control a Fan, we can simply derive Fan from
> > ButtonServer.
> >
> > But what if we have purchased the Fan class from a third party.  We
> > can't modify the source code to have it inherit from ButtonServer.
> > So we employ the "AdaptedServer" design pattern:
> >
> > Button<>--------------[]ButtonServer
> >                             A
> >                             |
> >                             |
> >                          FanAdapter<>---------[]Fan
> >
> > Here, FanAdapter is a simple class that inherits from ButtonServer
> > and which 'has' a Fan.  When the FanAdapter receives the "TurnOn"
> > message, it delegates to the Fan object.
> >
> > Notice that all these relationships are 'one-way'.  Note that Button
> > does not care about anything past the ButtonServer.  We can make
> > changes to Fan, FanAdapter, or any other derivative of ButtonServer,
> > and Button does not care.
> >
> > From what I've seen of FP, higher order functions are used to
> > abstract away algorithms, but this kind of dependency inversion is
> > rare. In fact, I suspect your average FPer would turn their nose up
> > in disgust :-)
> >
> > cheers
> > -sri
>
> I'll post two different implementations in SML so that we have
> something concrete to talk about and criticize.  The first is simpler
> and uses a single higher order function to abstract out the process of
> turning on:
>
> fun buttonDoingItsThing (..., turnOn) =
>   [definition of what a button does that can call turnOn]
>
> Now we can call buttonDoingItsThing wherever we like and pass in a
> function to turn on the appropriate device:
>
> ...
>   buttonDoingItsThing (..., turnOnLamp)
> ...
>
> If the function for turning on a fan that was written by somebody else
> doesn't do exactly what we want we can wrap it in another function.
> We don't need to name this function if we don't want to, probably
> because what it does is so trivial:
>
> ...
>   buttonDoingItsThing (..., fn () => ... turnOnFan ... )
> ...
>
>
> If we want to get fancier, we can use a module system like SML's
> signatures, structures and functors.  Here we have a signature for
> something that can be turned on:
>
> signature TurnOnableThing = sig
>   type turn_onable_thing
>
>   val turnOn turn_onable_thing -> unit
> end
>
> and a lamp implementation of that signature:
>
> structure Lamp : TurnOnableThing = struct
>   type turn_onable_thing = [definition of lamp type]
>
>   fun turnOn lamp = [definition of how to turn on a lamp]
> end
>
> and the opaque fan implementation and a wrapper that subscribes to the
> TurnOnableThing signature:
>
> structure Fan = [definition of a fan that does not subscribe to the
> TurnOnableThing signature]
>
> structure FanWrapper : TurnOnableThing = struct
>   type turn_onable_thing = Fan.[something]
>
>   fun turnOn fan = ... Fan.[something] ...
> end
>
>
> So are there some dependences in the code that I've written
> (hierarchical or otherwise) that are not present in the OO
> implementation suggested by your drawings?
I'm afraid I don't know SML well enough to be able to answer the question,
although I do get the general drift of what you're doing. But let me ask
you - would this be considered an idiomatic solution in SML? And is it a
coding pattern you yourself would use in practice on a large scale (bearing
in mind you or someone else might need to pick up the code 5 years down the
road)

cheers
-sri
> Benjamin


0
s_nedunuri (52)
7/1/2004 1:25:34 PM
Andreas Rossberg wrote:

>
>
> > let input_file f=
> >     let s =
> >       if (eof f)
> >           ""
> >      else
> >         let c= read_byte f in
> >            Str.concat (string_of_char c) (input_file f)
> >    in
> >                  s;;
>
> Man. You don't know much about FP. Using higher-order functions you
> write your own control structures, and don't program them out by hand
> every time:
>
>    input_file f = implode (repeatUntil (\_ -> eof f) (\_ -> read_byte f))
>
> where
>
>    repeatUntil p f = if p () then f () :: repeatUntil p f else []
>

I concede that your version is the more elegant one; it exhibits surely its
merits from a functional-programming-point-of-view. But why the heck is his
version not acceptable? I mean his version is easier to grasp - or isn't it?

What is wrong with his version?

Fensterbrett



>

0
7/1/2004 1:35:53 PM
Siegfried Gonzi wrote:
> 
>>>let input_file f=
>>>    let s =
>>>      if (eof f)
>>>          ""
>>>     else
>>>        let c= read_byte f in
>>>           Str.concat (string_of_char c) (input_file f)
>>>   in
>>>                 s;;
>>
>>Man. You don't know much about FP. Using higher-order functions you
>>write your own control structures, and don't program them out by hand
>>every time:
>>
>>   input_file f = implode (repeatUntil (\_ -> eof f) (\_ -> read_byte f))
>>
>>where
>>
>>   repeatUntil p f = if p () then f () :: repeatUntil p f else []

Just noticed that this should rather be

   repeatUntil p f = if p () then [] else f () :: repeatUntil p f

8-)

> I concede that your version is the more elegant one; it exhibits surely its
> merits from a functional-programming-point-of-view. But why the heck is his
> version not acceptable? I mean his version is easier to grasp - or isn't it?
> 
> What is wrong with his version?

I did not say it is wrong, it is just not making any real use of FP 
techniques. So he can hardly use it for demonstrating that FP "with all 
its recursion" is just pervert.

Btw, I disagree with his version being easier to grasp. May be so for 
the unprepared, but hardly for somebody familiar with FP idioms.

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

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

"Computer games don't affect kids; I mean if Pac Man affected us
  as kids, we would all be running around in darkened rooms, munching
  magic pills, and listening to repetitive electronic music."
  - Kristian Wilson, Nintendo Inc.

0
rossberg (600)
7/1/2004 2:43:56 PM
Joachim Durchholz wrote:

> Daniel C. Wang wrote:
> 
>> As I understand it. It is not legal for me to *redistrbuite* the 
>> webpages as a tarball. This was a condition placed on by the publisher.
>>
>>  Copyright � 2004 AT&T and Lucent Technologies. All rights reserved.
>>
>>  Permission is granted for internet users to make one paper copy for 
>> their
>>  own personal use. Further hardcopy reproduction is strictly prohibited.
>>  Permission to distribute the HTML document electronically on any medium
>>  other than the internet must be requested from the copyright holders by
>>  contacting the editors.
> 
> 
> The permission doesn't place any restriction on the format, just on the 
> medium.
> IOW it's irrelevant whether you republish the thing as tarball, Windows 
> Help file, or encoded in Ruritanian, as long as you do it on the 
> Internet (as opposed to, say, a CD edition).

Someone once asked for a link to a tarball of the basis spec on some ML 
specific mailing list. They were told that it was not possible because of 
this restriction. I think the intent of the resriction is to allow for only 
distribution via the website. If I'm wrong about this I'm happy to be mistaken.

{stuff deleted}
>>
>>> I think you are reading to much into this.  Linux is a fluke.  Try
>>> repeating it.  You'll never succeed.
>>> Also, it took and takes someone who makes it his/her life's mission.
>>> In an academic environment this is nearly impossible
>>
>>
>> Hmm.. do you consider MySQL, Apache, Perl, PHP, Python, to be flukes?
> 
> 
> MySQL definitely was, for a long time. It didn't have transactions until 
> version 4.0.
> (I'm not sure how much of SQL is implemented anyway. MySQL seems to take 
> speed more seriously than safety. Which I find distasteful, but that's 
> another issue.)

This argueably is the right tradeoff when you're just using your DB as a 
backend for serving web-content.

0
danwang742 (171)
7/1/2004 3:18:28 PM
"Dirk Thierbach" <dthierbach@gmx.de> wrote in message
news:v8lcr1-di.ln1@ID-7776.user.uni-berlin.de...
> Benjamin Ylvisaker <benjaminy@alumni.cmu.edu> wrote:
> > On Wed, 30 Jun 2004 11:08:45 +0100
> > "I spy" <s_nedunuri@yahoo.com> wrote:
>
> >> Here's another example, also from Robert Martin:
> >>
> >> A simple example: The button and lamp.  The button object needs to
> >> send the 'turnOn' message to the Lamp.
>
> > I'll post two different implementations in SML so that we have
> > something concrete to talk about and criticize.
>
> One problem with this is that in the OO example, the objects are
> supposed to have state, and the connections between objects are
> supposed to model the relationships of the objects in the "real
> world". The state is not made visible in the example. But (pure) FP
> programming needs to take a different approach to handle state, so
> it's difficult to compare the two examples directly.
Precisely. The bog standard FP answer of "just use higher order functions"
ignores the fact that its not only the abstraction of turning something on
but the state of the thing being turned on. So now you have to have the two
hand in hand at which point you have something that walks and quacks like a
class. (I say class, and not monad (for example), because classes were
designed for solving exactly this kind of problem. Monads have their origin
in denotational semantics. The difference is subtle but it shows. Classes
can be extended, and composed as mixins. Again, all with a view to solving
real world problems)

> Assume for example that the button has a counter which counts how often
> it is pressed, and that the lamp can either be a lamp that is just
> switched on and off, or a lamp that cycles through n levels of
> brightness.
>
> (Of course one can use impure features like the objects in OCaml to
> handle this...)
>
> - Dirk




0
s_nedunuri (52)
7/1/2004 3:37:59 PM
On Thu, 1 Jul 2004 04:58:04 -0700, Brandon J. Van Every 
<try_vanevery_at_mycompanyname@yahoo.com> wrote:

> Don Groves wrote:
>> On Wed, 30 Jun 2004 11:40:10 -0700, Brandon J. Van Every
>> <try_vanevery_at_mycompanyname@yahoo.com> wrote:
>>
>>> Don Groves wrote:
>>>>
>>>> Your so-called FP challenge is ridiculous. I've never read or
>>>> heard any FPer claim that frou-frou programming (skins, etc.)
>>>> is a strength of FP, or even something an FP-oriented programmer
>>>> would care about, much less spend any time writing that sort of
>>>> teenage stuff. I would wager that most subscribers to this group
>>>> use a program for reasons like functionality, robustness, accuracy,
>>>> reliability - not how 'cool' it looks on the screen.
>>>
>>> Well, that's a pile of prejudicial crap on your part.  Game
>>> developers are
>>> very much interested in how things look, and last I checked it was a
>>> $31 billion industry.
>>>
>>
>>
>> And exactly how many FP types are game programmers?
>
> Possibly not enough, if you actually believe the claims of FP.  At this 
> time
> I'm investigating it, but I'll suspend judgement until I actually see it
> fitting my problems.
>
>> And aren't even game programmers interested in functionality,
>> accuracy, and reliability.
>
> Your framing in terms of 'either or' is wrongheaded as far as a game
> developer is concerned.
>

Please don't put words in my mouth, you're the only one who
mentioned either/or. I'm pointing out that FP is far more
suited to providing accuracy and reliability than it is to
providing fancy user interfaces. Fancy user interfaces were
not a priority in the design of any FP language I know of.

If your search proves that FP languages care suitable for
game programming as well, then that is icing, not the cake.
--
dg



0
Don
7/1/2004 4:12:28 PM
"Daniel C. Wang" <danwang74@hotmail.com> writes:

> As I understand it the SML97 Standard also has some idiotic issue with
> it that will likely prevent any official revision of it to occur.

It just won't be called "Standard ML", that's all.  In any case, this
has nothing to do with the process, only with personal decisions of
certain people.  (I won't say more here about that.)

> I assume you will be planning on producing a few good students along
> the way too? :)

Hopefully.

> Do you consider gcc a commercial compiler?

It certainly isn't "academic" either.  (And gcc isn't that good a
compiler on many platforms, with vendor compilers waaaay outperforming
it.)

> BTW if anything, I'm only complaining that there is something wrong
> with reward models of research in general. The systems that support
> research seem either to be aimed at maximizing profit or maximizing
> the creation of dead trees, both models seem inefficent.

I can even agree with you on these things.  Just don't blame me for
being bound by those things as I can't easily change them.  I will
continue to try and do my best as far as SML/NJ is concerned.  Whether
my best will be enough remains to be seen.

Matthias
0
find19 (1244)
7/1/2004 4:12:52 PM
TLOlczyk wrote:

> Of all the code I wrote GUi and nonGUI, the single most valuable
> piece was for an investment management company. In a grid they
> displayed the difference between the value of an option and the
> price of an option. Traders would often make a wrong trade
> because they would fail to see a negative sign in this column.
> So I wrote a little piece of code:
> if(result<0)
>    edit_box->color=red;
> else
>    edit_box->color=black;
> which I added to the application.
> Those four lines literally saved the company millions.
> I would hardly call that not useful. Fact is that that is
> probably more useful than anything Simon has ever written
> or hopes to write. By a factor of 100.

wow, lovely insulting. You obviously have no clue of what I think, know, 
and have done. That is also not very relevant for the discussion. I only 
tried to explain how my experience with FP taught me to identify 
nuisances while programming in a non-FP. Unlike some people here in 
c.l.f., I am pragmatic and do not dismiss different paradigms. I 
regularly program Java these days and just notice over and over again 
that I miss the ability to write side-effect free code easily whenever 
approriate.

Your argument why FP is not used is plain naive (if not just plain 
stupid). You are assuming that because industry today is not using 
something, it is pointless. Let me give you a reminder. When I started 
out college, garbage collection was still considered by many as 
something that could not be seriously used or trusted. At the time 
(early 90s), Lisp and Smalltalk (with GC) had been around for decades. 
Today, a large amount of software developers in the world expect GC 
(being present in Java and C#). The reason is obvious, something like 
30% of all bugs in non-GC-languages is due to prematurely deallocated 
structures. Nobody is laughing at Lisp and Smalltalk for their GC anymore.

Also, you have no clue about the real world either. Your ideologically 
biased and unwilling to broaden your spectrum. Smalltalk never took off, 
ven though big companies like Daimler used it for a while. The reasons 
they abonded it is because the overall industry did not catch on (for a 
whole lot other reasons that just speed). It would have been desastrous 
if a company like Daimler would have been locked in 1 (or even 2) 
suppliers of Smalltalk environments. Today, Java is beating the drums. 
Notice that modern Smalltalk implementations are at least as efficient 
as Java. Today, there is not much difference between Smalltalk and your 
average FP in terms of acceptance.

Finally, to really rebut anything of the nonsense you are shouting 
around, there are companies in the world who have extremely succesfully 
used FPLs to develop their products. Erlang in Ericsson is the more 
famous one, but Galois Connections use Haskell to develop "stuff" for 
the NSA. Polyspace for industrial (C and Ada) program verification, etc. 
Notice that the products of these companies do not involve GUIs, yet 
each one of them is tremendously complex. Also, notice that Erlang is 
hybrid: purely functional with side-effecting I/O and most importantly, 
concurrent from the ground up.

Please, do me a favor and read what the following column by Philip 
Wadler (FYI, Phil was a co-designer of the GJ-extension now present in 
Java 1.5)

http://www2-data.informatik.unibw-muenchen.de/Lectures/FP/sigplan-why.pdf

Note that this was written in 98, so some of the info on both the 
functional and non-functional world is somewhat out of date now. The 
arguments are not though. (Also, Phil is now working for Avaya I beleive).

I am on his stance for the most part. If you think that is naive and 
useless, then we should stop talking. I rather trust Phil's vast 
experience and capacity than some random idiot like you (oops, I am 
insulting you... hmmm, sorry)

> There is no evidence that FP would bring anything to these large
> applications.

And there is no evidence to the contrary either.

> Or maybe they did, but just didn't like it.

No, they do not understand it. They have never been taught it. And, so 
it seems, you never learned it either.

> There is a difference between
> *thinking* you know something,
> and *knowing* you know something.

There is a difference between
*knowing* you know something and
*knowing* you do *not* know something
0
Simon
7/1/2004 4:20:43 PM
I spy <s_nedunuri@yahoo.com> wrote:
> "Dirk Thierbach" <dthierbach@gmx.de> wrote in message

>> One problem with this is that in the OO example, the objects are
>> supposed to have state, [...] so it's difficult to compare the two
>> examples directly.

> Precisely. The bog standard FP answer of "just use higher order functions"

BTW, higher order functions (HOFs) are still a lot more powerful and
easier to handle compared to any abstraction facility OO has to offer.

> ignores the fact that its not only the abstraction of turning
> something on but the state of the thing being turned on. So now you
> have to have the two hand in hand at which point you have something
> that walks and quacks like a class.

But now you're not comparing abstraction facilities, you're comparing
the ability to represent state. If you want to compare abstraction
facilities, I suggest you either make a stateless example, or you
allow impure state representations. (You already got two of the latter
kind, and it's probably very easy to make an OCaml one that does
exactly the same as your example does).

> (I say class, and not monad (for example), because classes were
> designed for solving exactly this kind of problem. Monads have their
> origin in denotational semantics. The difference is subtle but it
> shows.

Yes. Monads are a lot cleaner in many respects :-) Though they don't
offer any new solution to representing state; they just allow you to
do the same as an imperative language in a lazy functional context
in a safe way.

> Classes can be extended, and composed as mixins. Again, all with a
> view to solving real world problems)

And all class-based type systems I have seen so far are not very good.
Sooner or later they all have to fall back to type-casting. Recently,
people seem to have become aware that parametric polymorphism in
FP-style is a good thing, but it is still much too awkward in all the
OO language extensions I am aware of.

And FPs are pretty good at solving real world problems, too. Not
all real world problems require you to model a lot of state.

And one thing FP natural excell at is avoiding dependencies. They
also allow you to refactor everything easily with HOFs; something that
is impossible in OO languages (unless you invest a lot of effort to
simulate that "by hand").

Both FP and OO approaches have good and bad sides. Every programmer
should know both of them, and pick the more suitable one for the
problem at hand.

- Dirk
0
dthierbach (210)
7/1/2004 5:06:52 PM
On Wed, 30 Jun 2004 23:26:58 -0500, TLOlczyk <olczyk2002@yahoo.com> wrote:

> On Wed, 30 Jun 2004 12:47:57 -0700, Don Groves <(. (@ dgroves
> ccwebster) net))> wrote:
>
>> On Wed, 30 Jun 2004 11:40:10 -0700, Brandon J. Van Every
>> <try_vanevery_at_mycompanyname@yahoo.com> wrote:
>>
>>> Don Groves wrote:
>>>>
>>>> Your so-called FP challenge is ridiculous. I've never read or
>>>> heard any FPer claim that frou-frou programming (skins, etc.)
>>>> is a strength of FP, or even something an FP-oriented programmer
>>>> would care about, much less spend any time writing that sort of
>>>> teenage stuff. I would wager that most subscribers to this group
>>>> use a program for reasons like functionality, robustness, accuracy,
>>>> reliability - not how 'cool' it looks on the screen.
>>>
>>> Well, that's a pile of prejudicial crap on your part.  Game developers
>>> are
>>> very much interested in how things look, and last I checked it was a 
>>> $31
>>> billion industry.
>>
>> And exactly how many FP types are game programmers?

>>
> I see. And it never once occured to you that if there were many
> FP types that are game programmers, then FP would be much
> more popular precisely because the ranks of FP programmers
> would be swollen by game programmers?

I'm quite sure that game programmers, not being dummies, would
be using FP for games right now if FP languages provided what
game programmers want/need in a language.


> So today you exclude games programmers. Tomorrow you eclude
> people writing web applications. The day after that you  want to
> exclude programmers who interface with databases a lot.

I've not *excluded* anyone, I've merely pointed out the obvious
fact that not many game programmers use FP. Game programmers
want speed and great graphics, not exactly the kind of things
FP languages were designed to provide.

Currently, OCaml is the only FP language that can compare to
the fastest imperative languages in speed, so it may be a
reasonable candidate for games. OCaml is also not a "pure" FP
language so switching to it would be less of a shock to imperative
language programmers and OCaml's syntax is not as different
 from what game programmers are used to as, for example, Haskell.


> It seems to me that most FPers don't want FP to become enormously
> popular. They would rather if stay unpopular so that they can
> go around shouting what geniuses they are because they know
> "esoteric" languages. ( Esoteric  meaning few people use the
> languages. Never mind that they deliberately chased away the people. )

Hmmm, now who's being exclusive?
--
dg
0
Don
7/1/2004 5:16:10 PM
On Thu, 01 Jul 2004 00:26:01 -0400, Daniel C. Wang <danwang74@hotmail.com> 
wrote:

> Don Groves wrote:
> {stuff deleted}
>> Isn't most of that $31 billion spent by teenagers?
>
> Umm.. no...
>
> http://www.planetgamecube.com/news.cfm?action=item&id=3656

Ah, yes, how to misinterpret statistics.

That the average age of gamers is rising in no way indicates
that older people are taking up gaming.  It merely indicates
that people age.

I'll change my assertion to this: Most of that $31 billion is
spent by teenagers or by adults who started gaming as teenagers
and continue to be gamers as they age.
--
dg


0
Don
7/1/2004 5:20:32 PM
Don Groves wrote:

> I've not *excluded* anyone, I've merely pointed out the obvious
> fact that not many game programmers use FP. Game programmers
> want speed and great graphics, not exactly the kind of things
> FP languages were designed to provide.
> 
> Currently, OCaml is the only FP language that can compare to
> the fastest imperative languages in speed, so it may be a
> reasonable candidate for games. OCaml is also not a "pure" FP
> language so switching to it would be less of a shock to imperative
> language programmers and OCaml's syntax is not as different
> from what game programmers are used to as, for example, Haskell.

In fact, several years ago, a bunch of Ocaml-guys wrote an effective 
Doom-engine in Ocaml and demonstrated it on the ML-workshop. I don't 
remember what point they were trying to make with that, but I suspect 
they wanted to see if Ocaml's object extensions were up to the task. I 
do remember that their implementation at the time was only modestly 
slower than the real Doom. There are a lot of other Ocaml applications 
that try to address the issues Mr. Olczyk is addressing, including 
database access, COM access, graphics and GUI-building. This, despite 
the fact that Ocaml is entirely academic.

I wish people stop beating one paradigm or the other based on the "my 
dady is stronger than yours" approach.

(Thaddeus L. Olczyk, PhD simply does not get any of this differentiation 
because he is idiologically biased - it is an uphill battle and I have 
had enough)

	Simon
0
Simon
7/1/2004 5:24:55 PM
Don Groves wrote:

[...]

> I've not *excluded* anyone, I've merely pointed out the obvious
> fact that not many game programmers use FP. Game programmers
> want speed and great graphics, not exactly the kind of things
> FP languages were designed to provide. [...]

There is nothing about FP languages as such that makes them 
inappropriate for game programming. The real problem is a matter of 
culture and infrastructure. Graphics APIs are highly C-centric and 
evolving with great speed. If you want a "high-level" language, the 
choice by default is C++. No one has the time to explore other options 
given that C++ seems to be "good enough." When people actually do look 
beyond C++ for game programming, it's usually toward Java, which just 
seems insane to me, but Java is nothing if not ubiquitous.

-thant

0
thant (332)
7/1/2004 5:43:54 PM
On Thu, 1 Jul 2004 05:07:27 -0700, Brandon J. Van Every 
<try_vanevery_at_mycompanyname@yahoo.com> wrote:

> Don Groves wrote:
>>
>> The guy proposed a benchmark for FP that is entirely outside
>> the design concepts of FP. As you pointed out yourself, even
>> the best imperative languages haven't managed that feat.
>
> What the hell is 'the best' imperative language?  I see no call for a
> superlative.

Learn to read before flaming. I said "best imperative languages",
plural, not singular. You yourself implied the same in your earlier
response to another poster - and again below!

You say "no language..." Doesn't that include even the best (most
suitable) languages?


*No Language* has implemented an efficient, fully skinnable
> GUI widget set.  I've seen some bloated half-assed stuff.  Anyways, we 
> agree
> that the proposed design challenge is silly.  A reasonable challenge 
> would
> be "show me a FP widget set."

FP languages are not designed to be user interface oriented. They were
originally designed primarily in response to an ACM Turning Award
lecture in 1977 by John W. Backus, "Can Programming Be Liberated From
the von Neumann Style". The von Neumann style mandates a single
instruction thread coupled with R/W memory holding both code and
mutable data.

One of the primary original design goals was to enhance parallel
evaluation of expressions by multiple processors. Other goals are to
provide increased reliability, accuracy, and provability in programming
languages.

Modern FP languages interface to Tk, wxWidgets, and other GUI solutions,
so someone could "show you a FP widget set" but that just isn't a priority
in FP-land.  Maybe *you* are the one to do the job since you care about
it so fervently.


>> Isn't most of that $31 billion spent by teenagers?
>
> No, the majority is spent by people over 30.  Which makes sense if you
> consider that all the 30-somethings grew up playing games and have higher
> incomes than teenagers.

Ok, so they started gaming as teenagers and haven't grown out of it yet.
--
dg

0
Don
7/1/2004 5:52:31 PM
On Thu, 01 Jul 2004 12:20:43 -0400, Simon Helsen 
<where-X=@-in-shelsenXcomputer.org> wrote:

> TLOlczyk wrote:
>
>> There is a difference between
>> *thinking* you know something,
>> and *knowing* you know something.
>
> There is a difference between
> *knowing* you know something and
> *knowing* you do *not* know something

My version:
There is a difference between *thinking*
you know something and knowing something.

Actually, Richard Feynmann, in response to
Descarte, said it best:
"I think therefore I think I am"
--
dg



0
Don
7/1/2004 6:38:05 PM
Simon Helsen <where-X=@-in-shelsenXcomputer.org> wrote:

> I wish people stop beating one paradigm or the other based on the "my 
> daddy is stronger than yours" approach.

Same here! Ever since structured programming was all the rage, many
have been looking for the silver bullet to solve all their programming
needs in one package. Unless one is a specialist in a narrow field,
'it ain't happened yet and it ain't never gonna happen'.


> (Thaddeus L. Olczyk, PhD simply does not get any of this differentiation 
> because he is idiologically biased - it is an uphill battle and I have 
> had enough)

I'll carry on a while longer, you've earned a rest ;-)
--
dg

0
Don
7/1/2004 6:53:14 PM
Daniel, thank you for your detailed reply. Comments below
----- Original Message ----- 
From: "Daniel Yokomiso" <daniel_yokomiso@yahoo.com.br>
Newsgroups: comp.lang.functional
Sent: Wednesday, June 30, 2004 7:34 PM
Subject: Re: FP tutorial for OO programmers? [LONG]


>
> "I spy" <s_nedunuri@yahoo.com> escreveu na mensagem
> news:2kfhpcF1mifdU1@uni-berlin.de...
>
> [snip]
>
> > To continue Robert Martin's example, then, do you abstract out strings,
> > devices, and files into streams in your code and then pass around the
> > appropriate "driver"?
>
> First I have two things to say: I was a Java programmer until very
recently
> and I have read almost everything written by RCM, so IMHO I understand was
> are you trying to say.
>
> Saying that such form of abstraction is so common that people don't give
it
> a name. The original program could be written as (all code tested in Hugs
> version Jan 2001 beta):
>
>
>     readKeyboard :: IO (Maybe Char)
>     readKeyboard = return Nothing  -- dummy implementation
>
>     writePrinter :: Char -> IO ()
>     writePrinter _ = return ()     -- dummy implementation
>
>     copy' :: IO ()
>     copy' =
>         do {mx <- readKeyboard;
>             case mx of {
>                 Just x -> do {writePrinter x; copy'};
>                 Nothing -> return ()}}
>
>     --usage
>     copy'
>
> So we have a copy' function that depends on two other functions (i.e.
> readKeyboard and writePrinter). Now we have to write to either the printer
> or to the disk and the disk writing function has this type signature:
>
>     writeDisk :: Char -> IO ()
>     writeDisk _ = return ()     -- dummy implementation
>
> We could use the same enum-based solution:
>
>     data OutputDevice = Printer | Disk
>
>     copy'' :: OutputDevice -> IO ()
>     copy'' d =
>         do {mx <- readKeyboard;
>             case mx of {
>                 Just x -> do {case d of {
>                                   Printer -> writePrinter x;
>                                   Disk    -> writeDisk x};
>                               copy'' d};
>                 Nothing -> return ()}}
>
>     --usage
>     copy'' Printer
>     copy'' Disk
>
> Not only is this more complex than the original it makes the copy''
function
> dependent on the implementations. But in the FP world such kind of
solution
> would probably not even be thought because every FP enthusiast would see
> that the signatures of writePrinter and WriteDisk are equal so he can
> parametrize the copy on the destination based on the signature alone:
>
>     copy''' :: (Char -> IO ()) -> IO ()
>     copy''' output =
>         do {mx <- readKeyboard;
>             case mx of {
>                 Just x -> do {output x;
>                               copy''' output};
>                 Nothing -> return ()}}
>
>     --usage
>     copy''' writePrinter
>     copy''' writeDisk
>
> The input can be parametrized as well:
>
>     copy :: (Char -> IO ()) -> IO (Maybe Char) -> IO ()
>     copy output input =
>         do {mx <- input;
>             case mx of {
>                Just x -> do {output x; copy output input};
>                Nothing -> return ()}}
>
> And the dependency is inverted just like in RCM's solution. Now there's a
> catch on my example, because I explicit declared the type of the
> input/output functions. If we let the compiler infer the types we have a
> more generic type (for free):
>
>     copy :: Monad m => (a -> m b) -> m (Maybe a) -> m ()
>
> That is the input and output can be of any kind of Monad (as long as
they're
> the same Monad) and it can copy any kind of input to any kind of output.
> That's why all FP enthusiasts say classes aren't needed in many problems.
Looks like a good Haskell solution to me and makes use of higher order
functions as any good Haskell program should, but still falls in the
category of algorithm abstraction. The reason I say algorithm abstraction is
that you are capturing a function, not a class. What if the copy program
needed to first
check the reader and writer were ready before starting? To do this, not only
do you need additional methods, but the actual reader and writer derived
class instances will need to check their state. Ideally I'd want to make
them ADTs and place them in modules, but you can't parameterize over modules
or inherit from them :-(

> > Here's another example, also from Robert Martin:
> >
> > A simple example:  The button and lamp.  The button object needs to
> > send the 'turnOn' message to the Lamp.  How shall we accomplish this?
>
> [snip]
>
> > From what I've seen of FP, higher order functions are used to abstract
> away
> > algorithms, but this kind of dependency inversion is rare. In fact, I
> > suspect your average FPer would turn their nose up in disgust :-)
>
> This is very interesting because I was re-reading this problem a couple of
> weeks ago and tried to come up with a solution in Haskell for it:
Excellent.

>
> module Lamp where
>     import IOExts   -- We need those to use IORef (which is a kind of
>                     -- first-class variable in Haskell)
>
> -- Device is just sugar for the type of a tuple with three functions. We
> could
> -- just use the tuple type (IO Bool, IO (), IO ()) and the result would be
> the same
> -- The "Device" on the rhs is a data constructor.
>     data Device = Device {isOn :: IO Bool, turnOn :: IO (), turnOff :: IO
> ()}
>
> -- An utility operation to flip a device
>     switch (Device isOn turnOn turnOff) =
>         do on <- isOn
>            if on
>               then turnOff
>               else turnOn
>
> -- An utility operation to check the status of a device
>     printStatus (Device isOn _ _) = isOn >>= (putStrLn . ("> " ++) . show)
>
> -- A simple command line interface to control a device
>     server device =
>         do command <- getLine
>            case command of
>                "switch" -> switch device >> server device
>                "status" -> printStatus device >> server device
>                "quit"   -> return ()
>                _        -> printErrorMessage command >> server device
>       where printErrorMessage command = putStrLn ("> Unrecognized command:
"
> ++ show command ++ ". Type again.")
>
> -- Makes a new light-bulb
>     newLightBulb =
>         do state <- newIORef False
>            return Device {isOn = readIORef state,
>                           turnOn  = writeIORef state True >>  putStrLn ">
> I'm on!",
>                           turnOff = writeIORef state False >> putStrLn ">
> I'm off!"}
>
> -- Uses the server with the light-bulb device
>     testLamp = newLightBulb >>= server
>
> Now we can test it with the light-bulb device:
>
> Lamp> testLamp
> status
> > False
> switch
> > I'm on!
> status
> > True
> switch
> > I'm off!
> qiut
> > Unrecognized command: "qiut". Type again.
> quit
>
>
> Can the server work with another kind of device, say a Fan? ;-)
>
> Obviously the answer is yes, because the server is only interested in
three
> functions: isOn, turnOn and turnOff (i.e. the Device interface). In FPLs
we
> can create this interface in several ways (e.g. a tuple of three
functions,
> a record of three functions) and there's no need for subtyping or
> inheritance for this to work.
True there's no *need* for it. But what if you're developing a product line
family, and wanted Devices that carry additional state or Devices that can
query the button, or... You'll be replicating all the code you have above
where you do "return Device..." (which is more akin to how I might
occassionally use anonymous classes in Java). Now scale that up to methods
with more than one line, and a product line family of 100's of controls and
you'll have a major maintenance headache on you hands

> Both copy and server are higher-order
> functions, because their final behavior depends on functions they receive
as
> parameters.

I think I'm going to take a little time to look into Scala, O'Haskell and
the like to see if they really do provide the best of both worlds. In
particular, what facilities they provide for expressing these kinds of
problems.

cheers
-sri

> I hope this helps.
>
> > cheers
> > -sri
>
> Best regards,
> Daniel Yokomizo.
>
> "I know this isn't the "right" way to do it, but it was quick, easy, and
it
> works pretty well."
>  - John Hughes
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.711 / Virus Database: 467 - Release Date: 25/6/2004
>


0
s_nedunuri (52)
7/1/2004 7:28:46 PM
Don Groves wrote:
{stuff deleted}
> I'll change my assertion to this: Most of that $31 billion is
> spent by teenagers or by adults who started gaming as teenagers
> and continue to be gamers as they age.

http://www.usatoday.com/tech/news/2004-05-12-gamer-demographics_x.htm

Given your assertion andassuming gamers continute to game till around 30 and 
start to game around 13. With a constant rate of population growth in the 
steady state one should expect their to be more gamers over 18 then under 
18.  In anycase, gaming is "main stream" and profitable.
0
danwang742 (171)
7/1/2004 8:23:00 PM
On Thu, 1 Jul 2004, I spy wrote:

> (I say class, and not monad (for example), because classes were
> designed for solving exactly this kind of problem. Monads have their origin
> in denotational semantics. The difference is subtle but it shows. Classes
> can be extended, and composed as mixins. Again, all with a view to solving
> real world problems)
>

Monads can be made to fit interfaces (and those interfaces extended), and
monad transformers can be composed. There's certainly a difference, but in
a number of ways monads could even be argued to generalise classes!

-- 
flippa@flippac.org
0
flippa (196)
7/1/2004 9:28:02 PM
On Thu, 01 Jul 2004 16:23:00 -0400, Daniel C. Wang <danwang74@hotmail.com> 
wrote:

> Don Groves wrote:
> {stuff deleted}
>> I'll change my assertion to this: Most of that $31 billion is
>> spent by teenagers or by adults who started gaming as teenagers
>> and continue to be gamers as they age.
>
> http://www.usatoday.com/tech/news/2004-05-12-gamer-demographics_x.htm
>
> Given your assertion andassuming gamers continute to game till around 30 
> and start to game around 13. With a constant rate of population growth 
> in the steady state one should expect their to be more gamers over 18 
> then under 18.  In anycase, gaming is "main stream" and profitable.


Ok, I withdraw my assertion, the adult population, in the
US anyway, is farther gone than I thought. Plenty of time
for movies and video games, yet more than half don't even
take the time to vote. How sad...
--
dg
0
Don
7/1/2004 10:38:02 PM
Dirk Thierbach wrote:
> I spy <s_nedunuri@yahoo.com> wrote:
> 
>>"Dirk Thierbach" <dthierbach@gmx.de> wrote in message
> 
> 
>>>One problem with this is that in the OO example, the objects are
>>>supposed to have state, [...] so it's difficult to compare the two
>>>examples directly.
> 
> 
>>Precisely. The bog standard FP answer of "just use higher order functions"
> 
> 
> BTW, higher order functions (HOFs) are still a lot more powerful and
> easier to handle compared to any abstraction facility OO has to offer.

This is hog-wash. They are equal in power, argueably HOFs are improvished 
when compared to a prototype-based OO calculus. The fact that most OO 
languages are broken for other reasons does not mean HOF are any more powerful.

If you disagree with this claim please give me an example of something you 
can abstract with a HOF that you can not do with OO techniques.

Maybe you can show me something that easy to do in ML/Hasekll but hard to do 
in Java/Smalltalk.. but that say much about the languages and not so much 
about OO vs HOF.




0
danwang742 (171)
7/1/2004 10:38:38 PM
In article <cc17vc$4v61e$5@hades.rz.uni-saarland.de>, Andreas Rossberg wrote:
> Btw, I disagree with his version being easier to grasp. May be so for 
> the unprepared, but hardly for somebody familiar with FP idioms.

Besides, the act of reading in a file is inherently side-effectual, so
you'll have to do the "execute it in your head" thing even in the recursive
version.  Recursion *really* shines over iteration when you're walking over
complicated data structures, which is arguably more the meat of most
programs than the I/O.

cheers,
William
0
wlovas (87)
7/1/2004 11:19:17 PM
Don Groves wrote:
> On Thu, 1 Jul 2004 05:07:27 -0700, Brandon J. Van Every
> <try_vanevery_at_mycompanyname@yahoo.com> wrote:
>
>> Don Groves wrote:
>>>
>>> The guy proposed a benchmark for FP that is entirely outside
>>> the design concepts of FP. As you pointed out yourself, even
>>> the best imperative languages haven't managed that feat.
>>
>> What the hell is 'the best' imperative language?  I see no call for a
>> superlative.
>
> Learn to read before flaming.

It's not a flame.  Settle down.

> I said "best imperative languages",
> plural, not singular. You yourself implied the same in your earlier
> response to another poster - and again below!

What the hell are 'the best' imperative language_s_??  The question does not
change.  Are Python, Java, C#, and C++ 'the best' imperative languages?
They are widely used, I see nothing 'best' about them.  I am picking on your
use of the word 'best' as a meaningless superlative, although possibly
overly-hard, as maybe you only meant it as a figure of speech.  Still, I
think it is unfair to characterize the GUI skinning problem as something
"the best of breed" has failed at.  Nobody has gotten anything done
regardless of any breeding at all.

In other words, the problem might be industrial rather than anything to do
with any language.  Show me who wants skinnable GUIs as their business
model.  I think game developers would be into it.  Now, show me the forces
arrayed against that vision.  That would be the legions of accounting
software developers who don't care.  Throw a monopoly OS into the mix, i.e.
Microsoft, and I think you get predictable results.

On the other hand, one could argue that trivial GUIs work fine for most
games, and that only accounting software needs complicated GUIs.  So that
may be why the problem hasn't been industrially solved.

There may be other lines of reasoning.

> FP languages are not designed to be user interface oriented.

That's the cart before the horse.  User interfaces have not been designed to
be FP-oriented.

> Modern FP languages interface to Tk, wxWidgets, and other GUI
> solutions, so someone could "show you a FP widget set" but that just
> isn't a priority in FP-land.

An accident of historical interest, both in academia and industry.

> Maybe *you* are the one to do the job since you care about
> it so fervently.

How on Earth did you come up with the supposition that I give a rat's ass
about GUIs in *any* language?  I care about 3D graphics and AI.  I think
"the way out" of the GUI skinning dilemma is to write GUIs that run entirely
within OpenGL.  Screw these operating systems.

>>> Isn't most of that $31 billion spent by teenagers?
>>
>> No, the majority is spent by people over 30.  Which makes sense if
>> you consider that all the 30-somethings grew up playing games and
>> have higher incomes than teenagers.
>
> Ok, so they started gaming as teenagers and haven't grown out of it
> yet.

There's plenty of information on the demographics of gamedom if you actually
want to learn something about it.  Otherwise, enjoy your prejudice.

-- 
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
7/1/2004 11:56:34 PM
On Thu, 1 Jul 2004 16:56:34 -0700, Brandon J. Van Every 
<try_vanevery_at_mycompanyname@yahoo.com> wrote:

> What the hell are 'the best' imperative language_s_??  The question does 
> not
> change.  Are Python, Java, C#, and C++ 'the best' imperative languages?
> They are widely used, I see nothing 'best' about them.  I am picking on 
> your
> use of the word 'best' as a meaningless superlative, although possibly
> overly-hard, as maybe you only meant it as a figure of speech.  Still, I
> think it is unfair to characterize the GUI skinning problem as something
> "the best of breed" has failed at.  Nobody has gotten anything done
> regardless of any breeding at all.


This is getting hilarious! You use an all-inclusive phrase like
"nobody has gotten anything done", and then fail to see that
the set you define includes even those that may be called "best".

I am using "best" in the sense of GUI/widget or gaming languages
since that was the topic of your previous posts in this thread.
You are using "best" in an absolute sense which I never intended.

In any sufficiently large enough group of languages, some will be
considered among the best *at a given task* and others will not.
In general, FP languages are not and never have been claimed to be
among the best for GUI/widget stuff.


> In other words, the problem might be industrial rather than anything to 
> do
> with any language.  Show me who wants skinnable GUIs as their business
> model.  I think game developers would be into it.  Now, show me the 
> forces
> arrayed against that vision.  That would be the legions of accounting
> software developers who don't care.

Not caring about game programming does NOT mean being against it!
It only means "let someone else do it, I'm not interested".

There are no forces here arrayed against any vision, only some of
us defending FP against attacks that it isn't what it never was
designed to be!


>> Modern FP languages interface to Tk, wxWidgets, and other GUI
>> solutions, so someone could "show you a FP widget set" but that just
>> isn't a priority in FP-land.
>
> An accident of historical interest, both in academia and industry.

No, a decision by people about what they find important to work on.


>> Maybe *you* are the one to do the job since you care about
>> it so fervently.
>
> How on Earth did you come up with the supposition that I give a rat's ass
> about GUIs in *any* language?

Because *you* said, <quote> A reasonable challenge would be "show me a FP
widget set." </quote>

How could an FP widget set be a *reasonable* challenge for a
language in which widgets are not a high priority and never
have been a design criteria?
--
dg

0
Don
7/2/2004 1:30:59 AM
Daniel C. Wang wrote:

> Dirk Thierbach wrote:
>> BTW, higher order functions (HOFs) are still a lot more powerful and
>> easier to handle compared to any abstraction facility OO has to offer.
> 
> This is hog-wash. They are equal in power, argueably HOFs are improvished
> when compared to a prototype-based OO calculus. The fact that most OO
> languages are broken for other reasons does not mean HOF are any more
> powerful.

Well I don't want to dispute the truth of what you say (I'll leave that to
Dirk:-), but I believe the context of this discussion is expressive power
real programming languages that are available now, not the power of various
underlying formal calculi (which seem not have influenced the design of the
of the current crop of "main stream" OOPLs in any case :-).

Regards
--
Adrian Hey
0
ahey (217)
7/2/2004 1:37:36 AM
On Wed, 30 Jun 2004 23:26:59 -0500, TLOlczyk <olczyk2002@yahoo.com> wrote:

> On Wed, 30 Jun 2004 11:40:10 -0700, "Brandon J. Van Every"
> <try_vanevery_at_mycompanyname@yahoo.com> wrote:
>
>> Don Groves wrote:
>>>
>>> Your so-called FP challenge is ridiculous. I've never read or
>>> heard any FPer claim that frou-frou programming (skins, etc.)
>>> is a strength of FP, or even something an FP-oriented programmer
>>> would care about, much less spend any time writing that sort of
>>> teenage stuff. I would wager that most subscribers to this group
>>> use a program for reasons like functionality, robustness, accuracy,
>>> reliability - not how 'cool' it looks on the screen.
>>
>> Well, that's a pile of prejudicial crap on your part.  Game developers 
>> are
>> very much interested in how things look, and last I checked it was a $31
>> billion industry.
>
> Brandon, most FP programmers don't care if the gaming industry is
> making $31 billion. Many don't think that programmers should be paid
> to program. Many are communists. ( Even though they don't know
> what exactkly communism is. When you discuss their "opinions"
> on economy, communisim is almost exactly what they describe. )
> Mostly they make what money they make by leaching off the rest of
> us. Either working for Universities and "making" their money off of
> government grrants, or working for research departments of large
> firms. That is until those firms start losing money then make cut
> backs. As Mathias fully knows.


And Brandon accused *me* of a prejudicial pile of crap!

It's undoubtedly true that most FPers don't care about the
size of the gaming market, most FPers are not into designing
games - duh. If they were into designing games, they would
choose a language more suited to game design - another duh!

Many don't think programmers should be paid?  We'll that is
certainly an individual choice but I think you'll find more
of those types using the Free Software Foundation tools than
you will using FP languages. You aren't confusing the two,
are you?

Many are communists but they don't know what communism is?
I presume this means you do know but are not one. So, if
I want to learn more about communism who should I ask, you,
or a communist?

Mostly make money by leaching off of the rest of us? You
claim to have a PhD. By far the great proportion of PhDs
work for universities, research departments of large
corporations, and/or on government grants, the very employment
groups you decry above. Are you in one of these groups.
If yes, you have no right to complain.  If no, then how
would you like to be painted with the same broad brush you
used above in your diatribe against FPers.
--
dg










0
Don
7/2/2004 2:49:08 AM
Don Groves wrote:
>
> I am using "best" in the sense of GUI/widget or gaming languages
> since that was the topic of your previous posts in this thread.
> You are using "best" in an absolute sense which I never intended.
>
> In any sufficiently large enough group of languages, some will be
> considered among the best *at a given task* and others will not.
> In general, FP languages are not and never have been claimed to be
> among the best for GUI/widget stuff.

Well at least we have a definition now.

>> In other words, the problem might be industrial rather than anything
>> to do
>> with any language.  Show me who wants skinnable GUIs as their
>> business model.  I think game developers would be into it.  Now,
>> show me the forces
>> arrayed against that vision.  That would be the legions of accounting
>> software developers who don't care.
>
> Not caring about game programming does NOT mean being against it!

Yes it does.  It's a matter of what Microsoft will invest in.  Their market
is accounting software, so they do not solve game GUI problems.

> It only means "let someone else do it, I'm not interested".

Apple might see itself as interested in skinnable GUIs at the OS level,
given all the 'cool consumer' stuff they do.  The Linux folk aren't a game
market.  Some support at the OS level has to exist for this stuff to be
viable.  There are few meaningful players in the OS market, i.e. I just
named them.

>>> Modern FP languages interface to Tk, wxWidgets, and other GUI
>>> solutions, so someone could "show you a FP widget set" but that just
>>> isn't a priority in FP-land.
>>
>> An accident of historical interest, both in academia and industry.
>
> No, a decision by people about what they find important to work on.

Our sentences agree when you remove the word 'no'.

-- 
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
7/2/2004 2:59:06 AM
On Thu, 1 Jul 2004 19:59:06 -0700, Brandon J. Van Every 
<try_vanevery_at_mycompanyname@yahoo.com> wrote:

> Don Groves wrote:

>> Not caring about game programming does NOT mean being against it!
>
> Yes it does.  It's a matter of what Microsoft will invest in.  Their 
> market
> is accounting software, so they do not solve game GUI problems.
>
>> It only means "let someone else do it, I'm not interested".
>
> Apple might see itself as interested in skinnable GUIs at the OS level,
> given all the 'cool consumer' stuff they do.  The Linux folk aren't a 
> game
> market.  Some support at the OS level has to exist for this stuff to be
> viable.  There are few meaningful players in the OS market, i.e. I just
> named them.

This is turning to quicksand... I thought we were discussing
individual choices about what languages are appropriate to
what, and choices about what kind of programming a person may
be interested in. Suddenly it's about corporate interest.


>>>> Modern FP languages interface to Tk, wxWidgets, and other GUI
>>>> solutions, so someone could "show you a FP widget set" but that just
>>>> isn't a priority in FP-land.
>>>
>>> An accident of historical interest, both in academia and industry.
>>
>> No, a decision by people about what they find important to work on.
>
> Our sentences agree when you remove the word 'no'.
>

yours:
An accident of historical interest, both in academia and industry.

mine (without the no):
A decision by people about what they find important to work on.

You really think decisions made by people today about what
they find important, what their priorities are, are accidents
of historical interest?  I don't think you intend it that way,
but it sounds kinda insulting.
--
dg




0
Don
7/2/2004 3:13:27 AM
Don Groves wrote:
>
> It's undoubtedly true that most FPers don't care about the
> size of the gaming market, most FPers are not into designing
> games - duh.

True as a matter of history.  Most FPers are academics.

> If they were into designing games, they would
> choose a language more suited to game design - another duh!

Why do you suppose FP is not suited to game design?  If OCaml didn't have
certain warts, it would be suited for game design.  It can be interpreted,
bytecode compiled, and natively compiled, which is useful when trying to
prototype.  It produces fairly efficient code.  It has higher level
functions suitable for 3D graphics and AI problems, which is what a lot of
people in the game industry work on.  It's got an active community and a
reasonable if not fantastic number of support libraries, including OpenGL
support.  The main hangup are it doesn't support 32-bit ints or 32-bit
floats, and it's got an awfully funky C FFI.

Lisp has proven use in the game industry.  Naughty Dog created an in-house
language called GOAL (Game Object Assembly Lisp) and used it for their Jak
and Daxter titles.

> So, if
> I want to learn more about communism who should I ask, you,
> or a communist?

Ask all sides and get all opinions.

-- 
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
7/2/2004 3:58:03 AM
Don Groves wrote:
> On Thu, 1 Jul 2004 19:59:06 -0700, Brandon J. Van Every
> <try_vanevery_at_mycompanyname@yahoo.com> wrote:
>
>> Don Groves wrote:
>
>>> Not caring about game programming does NOT mean being against it!
>>
>> Yes it does.  It's a matter of what Microsoft will invest in.  Their
>> market
>> is accounting software, so they do not solve game GUI problems.
>>
>>> It only means "let someone else do it, I'm not interested".
>>
>> Apple might see itself as interested in skinnable GUIs at the OS
>> level, given all the 'cool consumer' stuff they do.  The Linux folk
>> aren't a game
>> market.  Some support at the OS level has to exist for this stuff to
>> be viable.  There are few meaningful players in the OS market, i.e.
>> I just named them.
>
> This is turning to quicksand... I thought we were discussing
> individual choices about what languages are appropriate to
> what, and choices about what kind of programming a person may
> be interested in. Suddenly it's about corporate interest.

Perhaps the challenge problem of "make a fully skinnable GUI widget set in a
FP" is exceedingly ill-formed.  It begs the question of whether OS support
exists to do it in any language.

> yours:
> An accident of historical interest, both in academia and industry.
>
> mine (without the no):
> A decision by people about what they find important to work on.
>
> You really think decisions made by people today about what
> they find important, what their priorities are, are accidents
> of historical interest?

Largely yes.  Certainly, I look at OCaml, Scheme, or Lisp for game
development because that's what seems to be readily available and usable.
Most people stick with Windows stuff as a matter of mindshare and network
effect, not a strong desire to exert their own opinion as to what to use.

> I don't think you intend it that way,

I did exactly intend it that way.

> but it sounds kinda insulting.

You find your lack of control over the world insulting?

-- 
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
7/2/2004 4:02:19 AM
Don Groves <(. (@ dgroves ccwebster) net))> wrote:
> I'm quite sure that game programmers, not being dummies, would
> be using FP for games right now if FP languages provided what
> game programmers want/need in a language.

Actually, from what I have heard, many game programmers use some
sort of functional language (e.g. Lisp, or even something homegrown)
as a scripting engine in their games, and for the AI.

- Dirk
0
dthierbach (210)
7/2/2004 4:36:13 AM
On Fri, 2 Jul 2004 06:36:13 +0200, Dirk Thierbach <dthierbach@gmx.de> 
wrote:

> Don Groves <(. (@ dgroves ccwebster) net))> wrote:
>> I'm quite sure that game programmers, not being dummies, would
>> be using FP for games right now if FP languages provided what
>> game programmers want/need in a language.
>
> Actually, from what I have heard, many game programmers use some
> sort of functional language (e.g. Lisp, or even something homegrown)
> as a scripting engine in their games, and for the AI.
>
> - Dirk


Sure, Lisp is a hybrid FP language that is fast (when
compiled), has many imperative features needed for game
programming, and can be embedded in other languages
for interactive scripting.  Many programs have done this,
AutoCad and Emacs being the most famous. I doubt gamers
are using Lisp for its functional nature, but for the
other things.
--
dg
0
Don
7/2/2004 5:19:21 AM
Don Groves <(. (@ dgroves ccwebster) net))> wrote:
> On Fri, 2 Jul 2004 06:36:13 +0200, Dirk Thierbach <dthierbach@gmx.de> 
> wrote:

>> Actually, from what I have heard, many game programmers use some
>> sort of functional language (e.g. Lisp, or even something
>> homegrown) as a scripting engine in their games, and for the AI.

> Sure, Lisp is a hybrid FP language that is fast (when compiled),

In games its usually interpreted AFAIK. All the time-critical stuff
(graphics, etc.) is done natively, it's just the scripting. That is
not time-critical.

> has many imperative features needed for game programming, and can be
> embedded in other languages for interactive scripting.  [...] I
> doubt gamers are using Lisp for its functional nature, but for the
> other things.

Then why are the gamers make the effort to use an extra language? If
they want imperative features and speed, they just could stick to C
(or whatever).

I think the point is that it is easier in an FP language to program
at a higher level of abstraction. And that's what is needed for
scripting (which sits at a very high level of the game logic).

- Dirk

0
dthierbach (210)
7/2/2004 5:46:13 AM
On Thu, 1 Jul 2004 20:58:03 -0700, Brandon J. Van Every 
<try_vanevery_at_mycompanyname@yahoo.com> wrote:

> Don Groves wrote:
>>
>> It's undoubtedly true that most FPers don't care about the
>> size of the gaming market, most FPers are not into designing
>> games - duh.
>
> True as a matter of history.  Most FPers are academics.

Also true as a matter of current usage.


>> If they were into designing games, they would
>> choose a language more suited to game design - another duh!

> Why do you suppose FP is not suited to game design?  If OCaml didn't have
> certain warts, it would be suited for game design.  It can be 
> interpreted,
> bytecode compiled, and natively compiled, which is useful when trying to
> prototype.  It produces fairly efficient code.  It has higher level
> functions suitable for 3D graphics and AI problems, which is what a lot 
> of
> people in the game industry work on.  It's got an active community and a
> reasonable if not fantastic number of support libraries, including OpenGL
> support.  The main hangup are it doesn't support 32-bit ints or 32-bit
> floats, and it's got an awfully funky C FFI.

So then by your own analysis, OCaml is *not* suited to game
programming in it's current state. You prove my point.


> Lisp has proven use in the game industry.  Naughty Dog created an 
> in-house
> language called GOAL (Game Object Assembly Lisp) and used it for their 
> Jak
> and Daxter titles.

Lisp is not really a functional language, rather it's a
hybrid which *can* be used in a functional manner but
rarely is because there are better choices for FP, namely
Haskell, OCaml, Clean, etc...


>> So, if
>> I want to learn more about communism who should I ask, you,
>> or a communist?
>
> Ask all sides and get all opinions.

My question was for Dr. Know-it-all whose tirade I was
responding to.
--
dg

>

0
Don
7/2/2004 5:51:46 AM
On Thu, 1 Jul 2004 21:02:19 -0700, Brandon J. Van Every 
<try_vanevery_at_mycompanyname@yahoo.com> wrote:

> Perhaps the challenge problem of "make a fully skinnable GUI widget set 
> in a
> FP" is exceedingly ill-formed.  It begs the question of whether OS 
> support
> exists to do it in any language.

We certainly agree on that! My entire reason for being
in this thread is to refute Dr. Know-it-all's exceedingly
ill-formed, as you put it so well, challenge to FPers to
produce just such a beast.



>> yours:
>> An accident of historical interest, both in academia and industry.
>>
>> mine (without the no):
>> A decision by people about what they find important to work on.
>>
>> You really think decisions made by people today about what
>> they find important, what their priorities are, are accidents
>> of historical interest?
>
> Largely yes.  Certainly, I look at OCaml, Scheme, or Lisp for game
> development because that's what seems to be readily available and usable.
> Most people stick with Windows stuff as a matter of mindshare and network
> effect, not a strong desire to exert their own opinion as to what to use.

I guess I have a more generous view of "most" people than you do.
--
dg
0
Don
7/2/2004 6:08:54 AM
Daniel C. Wang <danwang74@hotmail.com> wrote:
> Dirk Thierbach wrote:

>> BTW, higher order functions (HOFs) are still a lot more powerful and
>> easier to handle compared to any abstraction facility OO has to offer.

> This is hog-wash. They are equal in power, argueably HOFs are improvished 
> when compared to a prototype-based OO calculus. 

I am not sure what kind of prototype-based OO calculus you're thinking of.
Some OO calculi are very similar to lambda calculi.

What I often need and don't have in most OO languages is some kind of
lightweight abstraction facility. Blocks in Smalltalk come very close,
so you get very FP-like iterators and fold operations, that are also
stateless. Objects can be substituted, but are in general much 
to heavy.

It's difficult to do similar things in, say, C++, Eiffel, or Java, without a 
lot more effort.

> The fact that most OO languages are broken for other reasons does
> not mean HOF are any more powerful.

I didn't mean "powerful" in the sense "it's impossible to do in an OO
language". I meant it in the sense "it's easy to do and straighforward
in an FP language, and clumsy in an OO language".

All languages are Turing complete. There is no difference in "power"
here. It's the way you can shape your program into code, and how
easily or how hard this is to do, that counts.

> If you disagree with this claim please give me an example of something you 
> can abstract with a HOF that you can not do with OO techniques.

(Substitute "can not do" with "is clumsy to do".)

Maps and folds on algebraic data types, for example. The corresponding
OO equivalent is a class hierarchie together with the visitor pattern.

That forces me to make a heavyweight class every time I want to
use it, and to split logically coherent code into different places.
I also have to invent different types for them, and pass them any
external parameters "by hand" when there are no closures.

Another example is refactoring: Whenever I see similar code in a FP
program, I can just move the subexpression, add a function header,
maybe do a little bit of cleanup, and I am done. In a OO language, I
could use a function (also with a fair amount of effort, when currying
and closures are missing), but that's not a OO-technique. And an
object is usually overkill (and not a clean solution), because there
is no state involved.

So for little things, I usually end up keeping similar code ("copy and
paste programming" is quicker). It's only worth to do this if there's
a larger chunk I can reuse, or if I need it multiple times.

- Dirk

0
dthierbach (210)
7/2/2004 6:13:34 AM
Don Groves wrote:
> On Thu, 1 Jul 2004 21:02:19 -0700, Brandon J. Van Every
>>>
>>> You really think decisions made by people today about what
>>> they find important, what their priorities are, are accidents
>>> of historical interest?
>>
>> Largely yes.  Certainly, I look at OCaml, Scheme, or Lisp for game
>> development because that's what seems to be readily available and
>> usable. Most people stick with Windows stuff as a matter of
>> mindshare and network effect, not a strong desire to exert their own
>> opinion as to what to use.
>
> I guess I have a more generous view of "most" people than you do.

If you are honest about industrial practices, I don't see how you can see it
any way other than my way.  The vast majority of industrial programmers are
sheep.

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

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

0
7/2/2004 6:39:32 AM
Dirk Thierbach wrote:
> Don Groves <(. (@ dgroves ccwebster) net))> wrote:
>> I'm quite sure that game programmers, not being dummies, would
>> be using FP for games right now if FP languages provided what
>> game programmers want/need in a language.
>
> Actually, from what I have heard, many game programmers use some
> sort of functional language (e.g. Lisp, or even something homegrown)

Yes, the canonical example is GOAL from Naughty Dog.  It may also be the
only example.  It's certainly the only one that's been written up and people
commonly know about.  It is also worth noting that GOAL wasn't deemed
suitable for developing the entire game, only the game logic stuff.  Their
3D engines et al were written in C++, the standard industry practice.

> as a scripting engine in their games,

To the extent that scripting langauges are popular in game development, they
are popular because they are simple and don't need to be compiled.  Not
because they have advanced functionality.  For instance, Lua has mindshare
among game developers, although not so much actual use.  Lua does not have
any particularly advanced functionality.  It's main strength is it's the
easiest scripting language to embed.  It also has an undeserved reputation
for speed, whereas in reality, it is simply not quite as slow as the other
scripting languages.

> and for the AI.

I haven't really tracked down what's most often used for industrial AI
implementations.  It is certainly possible to gain this information, for
instance http://www.aiwisdom.com/ has a few books on the subject of "what
this or that project did" in industry.  My cursory impression is that game
AI industrialists / professionals do not think in terms of exotic language
choices.  Rather, they apply AI algorithmic techniques in perfunctory
languages.

I don't think anybody in the game industry is really into productivity
improvement or saving labor.  I don't think they know what that means or
what it would imply.  Rather, the vast majority of game development is
completely dysfunctional.  Those that aren't, still do shitloads of work.
The game industry would have the most to gain from improved managerial
technique rather than any language technology per se.

-- 
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
7/2/2004 6:52:00 AM
Don Groves wrote:
>
> Sure, Lisp is a hybrid FP language that is fast (when
> compiled), has many imperative features needed for game
> programming,

At the risk of repeating the substance of all that has gone before, why does
game programming need imperative features?  I see no a priori reason for
this.  I see plenty of in-practice reasons, like matters of habit, legacy
support, interfacing with imperative 3D engines, etc.  But those are
industrialization issues, not theoretical preventives.  A soloist like
myself *can* write a commercial game using a FP paradigm, if he chooses to.
In fact, maybe that's required in practice... have to be your own boss so
you can make that kind of decision.

> and can be embedded in other languages for interactive scripting.

A practice which I find to be regressive for certain classes of problems,
mainly high performance problems.  What we really want are languages that
scale, not languages that make us do awkward barrier shuffles over C FFIs.

> Many programs have done this,
> AutoCad and Emacs being the most famous. I doubt gamers
> are using Lisp for its functional nature, but for the
> other things.

Well, one Lisp / Scheme adherant working on the Nebula2 3D engine was of the
opinion that the vast majority of Lisp code he'd ever seen was imperative.

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

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

0
7/2/2004 7:00:26 AM
Don Groves wrote:
>
> So then by your own analysis, OCaml is *not* suited to game
> programming in it's current state. You prove my point.

But not for any FP reason.  31-bit ints, no 32-bit floats, and a tacky C FFI
are all grungy industrialization issues, not FP issues.  It's a side effect
of FP users being primarily academics.

> Lisp is not really a functional language, rather it's a
> hybrid which *can* be used in a functional manner but
> rarely is because there are better choices for FP, namely
> Haskell, OCaml, Clean, etc...

OCaml is a hybrid.

-- 
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
7/2/2004 7:04:48 AM
On Fri, 2 Jul 2004 07:46:13 +0200, Dirk Thierbach <dthierbach@gmx.de> 
wrote:

> Don Groves <(. (@ dgroves ccwebster) net))> wrote:
>> On Fri, 2 Jul 2004 06:36:13 +0200, Dirk Thierbach <dthierbach@gmx.de>
>> wrote:
>
>>> Actually, from what I have heard, many game programmers use some
>>> sort of functional language (e.g. Lisp, or even something
>>> homegrown) as a scripting engine in their games, and for the AI.
>
>> Sure, Lisp is a hybrid FP language that is fast (when compiled),
>
> In games its usually interpreted AFAIK. All the time-critical stuff
> (graphics, etc.) is done natively, it's just the scripting. That is
> not time-critical.
>
>> has many imperative features needed for game programming, and can be
>> embedded in other languages for interactive scripting.  [...] I
>> doubt gamers are using Lisp for its functional nature, but for the
>> other things.
>
> Then why are the gamers make the effort to use an extra language? If
> they want imperative features and speed, they just could stick to C
> (or whatever).
>
> I think the point is that it is easier in an FP language to program
> at a higher level of abstraction. And that's what is needed for
> scripting (which sits at a very high level of the game logic).
>
> - Dirk


If speed is not an issue, Tcl would work as well as Lisp as
a game scripting language and Tcl is not a functional language.
(and it doesn't have all those parentheses)

I still don't see Lisp being used in games for its *functional*
characteristics. In fact, I just noticed that Lisp isn't even
included in the list of functional languages in the FAQ for this
newsgroup.
--
dg
0
Don
7/2/2004 7:11:51 AM
On Thu, 1 Jul 2004 23:52:00 -0700, Brandon J. Van Every 
<try_vanevery_at_mycompanyname@yahoo.com> wrote:

> Dirk Thierbach wrote:

>> Don Groves <(. (@ dgroves ccwebster) net))> wrote:

>>> I'm quite sure that game programmers, not being dummies, would
>>> be using FP for games right now if FP languages provided what
>>> game programmers want/need in a language.
>>
>> Actually, from what I have heard, many game programmers use some
>> sort of functional language (e.g. Lisp, or even something homegrown)
>
> Yes, the canonical example is GOAL from Naughty Dog.  It may also be the
> only example.  It's certainly the only one that's been written up and 
> people commonly know about.  It is also worth noting that GOAL wasn't 
> deemed
> suitable for developing the entire game, only the game logic stuff.


As I just wrote in another post, Lisp isn't even included in
the list of functional languages in the FAQ for this newsgroup.
So let's stop referring to Lisp as a functional language.
--
dg
0
Don
7/2/2004 7:17:19 AM
Don Groves <(. (@ dgroves ccwebster) net))> writes:

> Mostly make money by leaching off of the rest of us? You
> claim to have a PhD. By far the great proportion of PhDs
> work for universities, research departments of large
> corporations, and/or on government grants, the very employment
> groups you decry above

But not all!  From the spam I get, there are plenty of (apparently)
for-profit outfits who are happy to sell you a Ph.D.  I'll refrain
from commenting on the Ph.D. in question, but just think how great it
would be for the economy if people stopped going to those damn commie
Universities, and just bought their degrees in the free market. 

But what do I know, I'm just a recursion-loving commie bastard.
(Perhaps I should start calling people 'imperativist lackeys'?)

-kzm
-- 
If I haven't seen further, it is by standing in the footprints of giants
0
ketil (99)
7/2/2004 7:23:18 AM
On Thu, 1 Jul 2004 23:39:32 -0700, Brandon J. Van Every 
<try_vanevery_at_mycompanyname@yahoo.com> wrote:

> Don Groves wrote:

>> On Thu, 1 Jul 2004 21:02:19 -0700, Brandon J. Van Every
>>>>
>>>> You really think decisions made by people today about what
>>>> they find important, what their priorities are, are accidents
>>>> of historical interest?
>>>
>>> Largely yes.  Certainly, I look at OCaml, Scheme, or Lisp for game
>>> development because that's what seems to be readily available and
>>> usable. Most people stick with Windows stuff as a matter of
>>> mindshare and network effect, not a strong desire to exert their own
>>> opinion as to what to use.
>>
>> I guess I have a more generous view of "most" people than you do.
>
> If you are honest about industrial practices, I don't see how you can 
> see it any way other than my way.  The vast majority of industrial 
> programmers are sheep.


Wow. I'm nearly at a loss for words here. I've never
heard such a ... I don't even know what to call it.

The vast majority of programmers do what they're told
to do and do it with the tools they're told to use
because they are working for a salary and need the money
to support themselves and their families.

This makes them sheep?

You and I must move in different industries --
I've spent time in the aerospace industry, the process
control industry, the real-time embedded systems industry,
some telephony, and I honestly can't remember ever meeting
a sheep.

I'm going to bed now, it's been a long day...
--
dg



0
Don
7/2/2004 7:40:40 AM
On Fri, 2 Jul 2004 00:04:48 -0700, Brandon J. Van Every 
<try_vanevery_at_mycompanyname@yahoo.com> wrote:

> Don Groves wrote:
>>
>> So then by your own analysis, OCaml is *not* suited to game
>> programming in it's current state. You prove my point.
>
> But not for any FP reason.  31-bit ints, no 32-bit floats, and a tacky C 
> FFI
> are all grungy industrialization issues, not FP issues.  It's a side 
> effect
> of FP users being primarily academics.


No, FPs don't allow side effects ;)

Who said anything about having to be an *FP* reason?
You through that requirement in just now. Quit changing
the specs of the discussion! It's hard enough keeping
track as it is.


>>> Lisp is not really a functional language, rather it's a
>> hybrid which *can* be used in a functional manner but
>> rarely is because there are better choices for FP, namely
>> Haskell, OCaml, Clean, etc...
>
> OCaml is a hybrid.

Ture, but much less of one than Lisp which I mention elsewhere
is not even included in the list of FP langugages in the FAQ for
this group.
--
dg

0
Don
7/2/2004 7:50:35 AM
On Fri, 02 Jul 2004 09:23:18 +0200, Ketil Malde <ketil@ii.uib.no> wrote:

> Don Groves <(. (@ dgroves ccwebster) net))> writes:
>
>> Mostly make money by leaching off of the rest of us? You
>> claim to have a PhD. By far the great proportion of PhDs
>> work for universities, research departments of large
>> corporations, and/or on government grants, the very employment
>> groups you decry above
>
> But not all!  From the spam I get, there are plenty of (apparently)
> for-profit outfits who are happy to sell you a Ph.D.  I'll refrain
> from commenting on the Ph.D. in question, but just think how great it
> would be for the economy if people stopped going to those damn commie
> Universities, and just bought their degrees in the free market.
>
> But what do I know, I'm just a recursion-loving commie bastard.
> (Perhaps I should start calling people 'imperativist lackeys'?)
>
> -kzm


I love it!  Imperativist lackeys it is!
--
dg (another recursive, lambda-loving commie-educated bastard)

0
Don
7/2/2004 7:55:37 AM
On Fri, 2 Jul 2004 00:00:26 -0700, Brandon J. Van Every 
<try_vanevery_at_mycompanyname@yahoo.com> wrote:

> Don Groves wrote:
>>
>> Sure, Lisp is a hybrid FP language that is fast (when
>> compiled), has many imperative features needed for game
>> programming,
>
> At the risk of repeating the substance of all that has gone before, why 
> does
> game programming need imperative features?  I see no a priori reason for
> this.

Assignment statements come to mind. I know they can be done in
most FPs but I don't think as efficiently. Really fast C pointer
constructs also come to mind. Neat side-effect tricks like *p++
or a[i++] too. These are all foreign to FP.


> Well, one Lisp / Scheme adherant working on the Nebula2 3D engine was of 
> the opinion that the vast majority of Lisp code he'd ever seen was 
> imperative.

Exactly!
--
dg


0
Don
7/2/2004 8:09:29 AM
Don Groves wrote:

> Assignment statements come to mind. I know they can be done in
> most FPs but I don't think as efficiently. Really fast C pointer
> constructs also come to mind. Neat side-effect tricks like *p++
> or a[i++] too. These are all foreign to FP.

I am not objecting your pointer-tricks as they are; it is C business.

But your statement "Thes are all foreign to FP" makes me wondering. I find
the proposition really strange. Why is it that bad that "FP programming" is
as it actually is?



> > Well, one Lisp / Scheme adherant working on the Nebula2 3D engine was of
> > the opinion that the vast majority of Lisp code he'd ever seen was
> > imperative.

There is some truth in that gist.

What I have learned in my academic career (writing and reasearching for my
PhD in physcis) is the following: In the meantime I am more after organizing
and re-using my data and programming code ? If you write tiny programs
everything is okay with pure functional programming, but once you start
producing bigger code you do not see the advantages any longer. And yes I had
some basic knowledge of Clean and produced even working code with it.
However, I must honestly say that a strong type system is a stumbling block
for me; personally so to speak. But Bigloo let me do things much quickier and
I started the other day to use Bigloo its module and object system for
organizing my code and programs.

I gather that in industry all is about "how to organize and integrate your
many thousand lines of code".

Fensterbrett

0
7/2/2004 8:32:43 AM
On Fri, 2 Jul 2004, Brandon J. Van Every wrote:

> Don Groves wrote:
> >
> > Sure, Lisp is a hybrid FP language that is fast (when
> > compiled), has many imperative features needed for game
> > programming,
>
> At the risk of repeating the substance of all that has gone before, why does
> game programming need imperative features?

It doesn't. See "The Yampa Arcade".

-- 
flippa@flippac.org
0
flippa (196)
7/2/2004 8:54:40 AM
Siegfried Gonzi wrote:

> And yes I had
> some basic knowledge of Clean and produced even working code with it.
> However, I must honestly say that a strong type system is a stumbling block
> for me; personally so to speak. But Bigloo let me do things much quickier and
> I started the other day to use Bigloo its module and object system for
> organizing my code and programs.
>

I may add: the most important things for me:

a) garbage collection

b) I do not have to define every variable and array prior to using it

c) I give types in Bigloo based on my desire.

d) I may collect everything in a list or array and not only one data type
without special constructs

e) and a bit of speed

[Python is crap but it comes close to my requirements but for speed and types,
though, my requirements are very weak and not well thout out]


My brain has it itself adapted to Scheme in the meantime. I have a hard time
when reading Fortran code - which is common in atmospheric science - from other
people, because my reading flow of Fortran (and to some degree C code) is
strongly impaired by all that type assignments to variables; I have a lot to
jump - mentally - around the code.

Believe it or not I have seen a Fortran program which was written in the /year
1997/. That is not necessarily a tragedy, but the program was one big 2000 lines
of code program without any! subfunction and the loop were written by means of
gotos. Really. The guys have never heard of Fortran  95 as it seems.

Fensterbrett


0
7/2/2004 8:56:22 AM
Don Groves <(. (@ dgroves ccwebster) net))> writes:

>> At the risk of repeating the substance of all that has gone before,
>> why does game programming need imperative features?  I see no a
>> priori reason for this.

> Assignment statements come to mind. 

You don't need to mutate variables.  It can be more efficient, sure. 

> I know they can be done in most FPs but I don't think as
> efficiently. Really fast C pointer constructs also come to
> mind. Neat side-effect tricks like *p++ or a[i++] too. These are all
> foreign to FP.

Oh, come on!  How's that important, compared to *p followed by p++ (or
for that matter, p := p+1?  

Basically, games are written in C because it gives you decent
performance, because it's what game developers understand, and it's
easy to get tools and people for it.  It's the traditional thing, just
like in most of industry.

It's not imperative or OO vs FP, it's C vs. the rest of the world.  If
there were a host of games written in niche OO languages, okay, that
would be a point, but AFAICT, it is no more common to develop games in
Eiffel, ADA, Fortran, Objective-C... than in Ocaml.

But looking at games, sure, they are relatively good at squeezing
performance out of the iron; we get wild and wonderful 3D rendering
compared to the pac men of yore.  However, game AI still sucks. 

-kzm
-- 
If I haven't seen further, it is by standing in the footprints of giants
0
ketil (99)
7/2/2004 9:51:57 AM
Ulf Wiger wrote:

> The amount of Erlang code in AXD 301 now exceeds 2 million lines.
> So does the amount of C code (i.e. it's more than just drivers ;)

Ah, you've been busy since I saw you last. :-) Watch out for that 
creeping featuritis. :-)

Stefan,
-- 
Stefan Axelsson  (email at http://www.cs.chalmers.se/~sax)
0
crap1234 (43)
7/2/2004 10:42:41 AM
Dirk Thierbach wrote:

> And all class-based type systems I have seen so far are not very
> good. Sooner or later they all have to fall back to type-casting.

I have seen type systems that can fully express the usual type 
relationships, so you don't need type casts.

Most of these type systems had quite subtle semantics (such as F-bounded 
polymorphism), and I doubt that even a library writer will be able to 
work with them and have confidence in the results.

I've been toying with the idea of making the type a relatively normal 
attribute of an object, with the border condition that most type 
expressions should be evaluated at compile time. It seemed to work out 
pretty lovely, but it never got beyond the pen-and-paper stage so I 
can't say whether such an approach would scale.

I agree if you meant the type systems of existing mainstream languages, 
of course :-)

Regards,
Jo
0
jo427 (1164)
7/2/2004 10:48:46 AM
Don Groves wrote:

> If speed is not an issue, Tcl would work as well as Lisp as a game
> scripting language and Tcl is not a functional language. (and it
> doesn't have all those parentheses)

Tcl is rather weak (read: low on expressivity) when it comes to dealing
with nested or linked-up data structures, something that's important in
a game.
A fairer comparison would be languages like Python or Ruby. Actually I 
dimly recall having read something about Python in a gaming context, but 
I can't remember any details.

Regards,
Jo
0
jo427 (1164)
7/2/2004 10:52:17 AM
Don Groves wrote:

> Really fast C pointer constructs also come to mind. Neat side-effect
> tricks like *p++ or a[i++] too. These are all foreign to FP.

This kind of side-effect tricks have long vanished in the dust of time.
Any decent modern C compiler will apply them where appropriate (as most
FPL compilers).

In fact, the possibility that some subroutine is using such kinds of
pointer tricks is *preventing* C compilers from applying optimizations.

Regards,
Jo
0
jo427 (1164)
7/2/2004 10:56:37 AM
Don Groves wrote:

> As I just wrote in another post, Lisp isn't even included in the list
> of functional languages in the FAQ for this newsgroup. So let's stop
> referring to Lisp as a functional language.

The FAQ isn't authoritative on the subject, you know.

Personally, I don't draw a sharp line between functional and 
non-functional languages anyway - and Lisp is simply a borderline case, 
functional in some respects and not-so-functional in others. It's 
certainly "functional enough" to be quoted as an example in this 
discussion, and it would be "not functional enough" in discussions on, 
say, referential transparency or type inference.

Regards,
Jo
0
jo427 (1164)
7/2/2004 10:59:44 AM
Brandon J. Van Every wrote:

> User interfaces have not been designed to be FP-oriented.

In fact I see that the praise for a widget set is directly proportional
to the percentage of state that they hide from the application programmer.

Examples:
Tk and GTK+ have ways to statically describe the layout and even the
resizing behaviour of widgets.
Even MFC tries to do static associations of hotkeys to actions.

I.e. GUIs are deeply stateful and imperative, yes, but people have been
trying to eliminate as much of that state as possible. (I suspect it's
the widget authors who are constantly reintroducing new state into GUIs...)

> I think "the way out" of the GUI skinning dilemma is to write GUIs
> that run entirely within OpenGL.  Screw these operating systems.

A better GUI framework is more a question of design choices above the
graphics layer. Things like how widget hierarchies interact, how they
resize, how user input is routed, when to redraw and who's responsible
for doing it. It's large, complex, full of design trade-offs, and has a
good deal of ergonomic questions thrown in (and both kinds of
ergonomics: programmers and end users).

The graphics layer is a very, very small part of the whole picture.

Regards,
Jo
0
jo427 (1164)
7/2/2004 11:10:44 AM
"Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com> writes:

> Don Groves wrote:
>
> >>> Modern FP languages interface to Tk, wxWidgets, and other GUI
> >>> solutions, so someone could "show you a FP widget set" but that just
> >>> isn't a priority in FP-land.
> >>
> >> An accident of historical interest, both in academia and industry.
> >
> > No, a decision by people about what they find important to work on.
> 
> Our sentences agree when you remove the word 'no'.

From the industry side, one of Erlang's long-standing weaknesses
has been the lack of a powerful GUI library. There are some 
connections to Tk. There is also one to GTK, but so far, no
really strong user support has been mounted behind any particular
solution(*). This situation is quite understandable considering the
roots of Erlang (embedded systems for telecoms.) It's fair to say
that there has been interest in, but no business case for, for a 
good GUI framework. Given the effort required, one may assume that 
nothing ever happens until the business case is there - or until
a sufficiently amount of interest builds up in the Open Source 
world.

The cutest proposal for an Erlang-based GUI is Joe Armstrong's
Ex11 (http://www.sics.se/~joe/ex11/) At this point, it's to be
reviewed as a proof of concept - not as a mature GUI library.
This solution takes full advantage of Erlang's lightweight
processes and message passing (i.e. the non-FP aspects.)
It's a bit sluggish on old hardware (e.g. my 400MHz SPARC),
but is said to be quite nice on modern PCs.

/Uffe

(*) A notable exception is the Wings3D application, which 
uses OpenGL, is otherwise written in Erlang, and scores 
nearly 20,000 downloads/month.
-- 
Ulf Wiger, Senior Specialist,
   / / /   Architecture & Design of Carrier-Class Software
  / / /    Strategic Product & System Management
 / / /     Ericsson AB, Connectivity and Control Nodes
0
ulf.wiger1 (107)
7/2/2004 11:13:37 AM
TLOlczyk wrote:

> ... most FP programmers don't care if the gaming industry is
> making $31 billion. Many don't think that programmers should be paid
> to program. Many are communists. ( Even though they don't know
> what exactkly communism is....

> Thaddeus L. Olczyk, PhD

Monsieur Le Docteur (Ph) Thaddeus L. Olczyk, Doctor (Ph), Sir!

I would like to ask you humbly a favour, please help me to solve my
moral dilemma, because I cannot sleep anymore...

Some time ago I met a Communist. I didn't know that he was a Communist,
but after some time he confessed that he was one. In France it happens.
He even didn't look like a Communist, but I suspected something, when
he pronounced the word "game". It was as if this word had four letters.

He told me that they Communists are very Strict People.

But, you see, I have to admit that I practise Lazy programming. Which
is not Strict, on the contrary.
And, more generally I am a Lazy Programmer. Which is even worse, although
I don't know (yet) worse than what.

The problem is the following: do Lazy Functional Programmers have moral
rights to become Communists, and if yes, then what.

Thank you for your profound and inspiring postings, and I ask for more,
the life becomes more interesting with you around.



Jerzy Karczmarczuk
Caen, France.
0
karczma (331)
7/2/2004 2:15:00 PM
"I spy" <s_nedunuri@yahoo.com> escreveu na mensagem
news:2kj6veF31kbuU1@uni-berlin.de...
> Daniel, thank you for your detailed reply. Comments below
> ----- Original Message ----- 
> From: "Daniel Yokomiso" <daniel_yokomiso@yahoo.com.br>
> Newsgroups: comp.lang.functional
> Sent: Wednesday, June 30, 2004 7:34 PM
> Subject: Re: FP tutorial for OO programmers? [LONG]
> >
> > "I spy" <s_nedunuri@yahoo.com> escreveu na mensagem
> > news:2kfhpcF1mifdU1@uni-berlin.de...
> >
> > [snip]
> >
> > > To continue Robert Martin's example, then, do you abstract out
strings,
> > > devices, and files into streams in your code and then pass around the
> > > appropriate "driver"?

[snip]

> Looks like a good Haskell solution to me and makes use of higher order
> functions as any good Haskell program should, but still falls in the
> category of algorithm abstraction. The reason I say algorithm abstraction
is
> that you are capturing a function, not a class.

Please don't do that. You picked a problem and was given a solution in a
FPL. Don't back-pedal and say that the FP solution doesn't work because of
new requirements. The DIP article is simple and I showed you how can you
achieve dependency inversion with HOFs.

> What if the copy program needed to first check the reader and writer were
ready
> before starting? To do this, not only do you need additional methods, but
the
> actual reader and writer derived class instances will need to check their
state.

Just like the Button/Lamp example I gave. In FPLs we have closures (i.e.
functions that carry a state) sharing some state, just like the three Device
functions shared the "state" reference. So instead of having two HOF
parameters we can have four:

    copy2 :: MonadPlus m => (a -> m b, m Bool) -> (m (Maybe a), m Bool) -> m
()
    copy2 (output, checkOutput) (input, checkInput)  =
        do {inputOk <- checkInput;
            guard inputOk;
            mx <- input;
            case mx of {
                Just x -> do {outputOk <- checkOutput;
                              guard outputOk;
                              output x;
                              copy output input};
                Nothing -> return ()}}

Notice how I packed the check operations together with the respective
input/output operations, they should belong to a single type/adt, so I can
define it:

    type Input m a = (m (Maybe a), m Bool)
    type Output m a b = (a -> m b, m Bool)
    copy2 :: MonadPlus m => Output m a b -> Input m a -> m ()

And show the change in the signature of copy2. I used a simple type
definition, but we could use a data declaration, don't export the
constructors from our module and get a real ADT for each type. But if we
follow good OOP practices we should first ask ourselves: Why do we need to
ask for the state of input/output before telling them to do their jobs?
Isn't it a violation of the "Tell, don't ask!" principle? What I'm trying to
say is that in all years I spent working with Java I would rarely have a
method sending more than a couple of different messages to another object.

> Ideally I'd want to make them ADTs and place them in modules, but you
can't
> parameterize over modules or inherit from them :-(

Of course you can (but not in Haskell). In languages of the ML family (e.g.
SML, O'Caml) modules are first class citizens and you can have parametrized
modules, but they're called functors. Here's an O'Caml example (courtesy of
Neel Krishnaswami) using higher-order modules, functors and the object
system to extend a ref-like object (i.e. something with get and set methods)
to have undo facilities:

(*A simple module with no parameters*)
module type REF =
  sig
(*Defines the type of a ref-like class. If could have a type parameter
instead of a hard-coded string type but it isn't important in this
example.*)
    class t :
      object
        method get : string
        method set : string -> unit
      end
  end

(*This module is a functor. It can take parameters, including other modules
as parameters.*)
module Add_Undo(Base : REF) =
  struct
(*Defines a subclass of class parameter. It's similar to the C++ templates
for mixins where we have the superclasses as template parameters. This class
can be used wherever the super-class can be used and it doesn't depend on
the implementation of the super-class, just on its interface.*)
    class t =
      object
        inherit Base.t as super

        val mutable history = []

        method set s =
          begin
            history <- super#get :: history; (*super#get is like super.get()
in Java.*)
            super#set s;
          end

        method undo =
          match history with
            | [] -> ()
            | x :: xs -> (super#set x; history <- xs)
      end
  end



> > > Here's another example, also from Robert Martin:
> > >
> > > A simple example:  The button and lamp.  The button object needs to
> > > send the 'turnOn' message to the Lamp.  How shall we accomplish this?

[snip]

> True there's no *need* for it. But what if you're developing a product
line
> family, and wanted Devices that carry additional state or Devices that can
> query the button, or... You'll be replicating all the code you have above
> where you do "return Device..." (which is more akin to how I might
> occassionally use anonymous classes in Java). Now scale that up to methods
> with more than one line, and a product line family of 100's of controls
and
> you'll have a major maintenance headache on you hands

That's one thing I don't like: theoretical examples from the top of our
heads. It's an impossible to win situation because no matter how complete is
my solution you can always say "But if I change the scenario to this your
solution would be cumbersome". If you're going to play this game don't even
bother answering this post, otherwise we can continue this.

And just to remember something again I am a non-academic Java programmer
from the industry, so I'm not saying that we could FPL to solve the
academical OO problems (e.g. collection frameworks, idiotic shape problems)
but to solve the n-tiered SQL/HTML problems.

So answering your question let's say that we have a Device with additional
capabilities, for example it can call a function to tell when it needs
repair. We can use composition to model this:

    data Repairable d = Repairable {thing :: d, onFailure :: String -> IO
()}

We could put the switch and printStatus operations on a type-class:

    class Operable o where
        switch :: o -> IO ()
        printStatus :: o -> IO ()

Declaring instances for both Device and Repairable Device:

-- The old definitions inside a class
    instance Operable Device where
-- An utility operation to flip a device
        switch (Device isOn turnOn turnOff) =
            do on <- isOn
               if on
                  then turnOff
                  else turnOn
-- An utility operation to check the status of a device
        printStatus (Device isOn _ _) = isOn >>= (putStrLn . ("> " ++) .
show)

-- Delegate the operations to the device
    instance Operable (Repairable Device) where
        switch (Repairable device _) = switch device
        printStatus (Repairable device _) = printStatus device

Now our server works on operables rather than devices:

    server :: Operable a => a -> IO ()

We can make a composition function to extend a device with an additional
state and callback operation. In this example the extra operation doesn't
make sense but you get the idea:

    makeBreakable failWith super =
        do counter <- newIORef 0
           let updateCounter = modifyIORef counter (+1)
           let shoutIfBroken = do {x <- readIORef counter;
                                   when (x >= 2)
                                        (failWith "I'm too old")}
           return $ Repairable {thing = super {turnOn = do {shoutIfBroken;
turnOn super},
                                               turnOff = do {updateCounter;
shoutIfBroken; turnOff super}},
                                onFailure = failWith}

    testBreakableLamp = newLightBulb >>= makeBreakable onFailure >>= server
        where onFailure message = putStrLn ("Fix-me, because " ++ message
++"!")

Here's the results I get with Hugs:

    Lamp> testBreakableLamp
    status
    > False
    switch
    > I'm on!
    status
    > True
    switch
    > I'm off!
    switch
    > I'm on!
    switch
    Fix-me, because I'm too old!
    > I'm off!
    quit

There are two interesting things in this code: makeBreakable extends a
device with additional state using old-fashioned prototype techniques and
the Operable type-classe allow different implementations of a similar
protocol much like Java-interfaces (actually they-re much more powerful than
interfaces and this comparison is too simplistic).

We could have another type-class "extending" Operable (not extension per-se
but the results are similar in this context) or even make the original
Device data-type a type-class too. I'm pretty much confident that, despite
my newbie knowledge of Haskell, I can come up with solutions to any
extension problems you might think of and they all will be simpler and more
concise than the usual class-based OO equivalent. But IME and what other
people are trying to say here is that in practice one or two HOF do the job
most of the times and only in a few cases we need to pack a group of related
operations in a single object.

> > Both copy and server are higher-order
> > functions, because their final behavior depends on functions they
receive
> as
> > parameters.
>
> I think I'm going to take a little time to look into Scala, O'Haskell and
> the like to see if they really do provide the best of both worlds. In
> particular, what facilities they provide for expressing these kinds of
> problems.
>
> cheers
> -sri

Best regards,
Daniel Yokomizo.

"Both [G.J. Sussman and D.S. Wise] belonged very much to the LISP
subculture, neither of the two proved a single theorem, both showed too much
and made such heavy use of anthropomorphic terminology that they were
painful to listen to."
 - Edsger W. Dijkstra


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.713 / Virus Database: 469 - Release Date: 30/6/2004

0
7/2/2004 2:57:04 PM
Daniel C. Wang wrote:
> Dirk Thierbach wrote:
> 
>> I spy <s_nedunuri@yahoo.com> wrote:
>>
>>> "Dirk Thierbach" <dthierbach@gmx.de> wrote in message
>>
>>
>>
>>>> One problem with this is that in the OO example, the objects are
>>>> supposed to have state, [...] so it's difficult to compare the two
>>>> examples directly.
>>
>>
>>
>>> Precisely. The bog standard FP answer of "just use higher order 
>>> functions"
>>
>>
>>
>> BTW, higher order functions (HOFs) are still a lot more powerful and
>> easier to handle compared to any abstraction facility OO has to offer.
> 
> 
> This is hog-wash. They are equal in power, argueably HOFs are 
> improvished when compared to a prototype-based OO calculus. The fact 
> that most OO languages are broken for other reasons does not mean HOF 
> are any more powerful.
> 
> If you disagree with this claim please give me an example of something 
> you can abstract with a HOF that you can not do with OO techniques.

I have no idea what you mean by prototype-based OO calculus. (I think I 
got sick to my stomach long before I reached that part in Abadi 
Cardelli's "A Theory of Objects." But here's my favorite concise example 
of how HOFs are so cool:

	http://makeashorterlink.com/?X5F4425B8

(Yes, I'm repeating myself.)

(The 'makeashorterlink' website is better than 'tinyurl' in that it 
allows you a couple seconds before it forwards you to the address.)

> Maybe you can show me something that easy to do in ML/Hasekll but hard 
> to do in Java/Smalltalk.. but that say much about the languages and not 
> so much about OO vs HOF.

If indeed "prototype-based OO calculus" has the properties you attribute 
to it, I suspect it is only to the degree that it smells like just a 
different kind of HOF.

-thant


0
thant (332)
7/2/2004 3:09:16 PM
I spy wrote:
> 
> I'm afraid I don't know SML well enough to be able to answer the question,
> although I do get the general drift of what you're doing. But let me ask
> you - would this be considered an idiomatic solution in SML? And is it a
> coding pattern you yourself would use in practice on a large scale (bearing
> in mind you or someone else might need to pick up the code 5 years down the
> road)

If you don't mind me answering for Benjamin (who appearently is not 
reading news on a daily basis): a definite yes to both your questions. 
This is what ML-style modules have been designed for, and what I do all 
the time when writing ML code.

Cheers,

	- Andreas

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

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

0
rossberg (600)
7/2/2004 3:20:17 PM
Don Groves wrote:

[...]

> Ok, I withdraw my assertion, the adult population, in the
> US anyway, is farther gone than I thought. Plenty of time
> for movies and video games, yet more than half don't even
> take the time to vote. How sad...

What would be the point of voting? Do you think it's pure chance the 
Democratic Party astoundingly managed to find a candidate that actually 
has a chance of losing against Bush the Younger? Who (against all odds) 
is *also* a Yale Skull 'n Bones fratboy? Who has no intention of pulling 
out of Iraq and is in fact likely to increase U.S. military presence 
there? "They" have already won the election.

Sorry, I'll shut up now.

-thant

0
thant (332)
7/2/2004 3:21:27 PM
Daniel Yokomiso wrote:
> 
>>Ideally I'd want to make them ADTs and place them in modules, but you
>>can't parameterize over modules or inherit from them :-(

In ML (SML or OCaml), you can do both (although "inheritance" is just 
inclusion, it does not allow overriding). You can even parameterize over 
parameterized modules (a feature known as higher-order functors).

> Here's an O'Caml example (courtesy of
> Neel Krishnaswami) using higher-order modules, functors and the object
> system to extend a ref-like object (i.e. something with get and set methods)
> to have undo facilities:

To be honest, I don't understand the point you are trying to demonstrate 
  with your example. I mean, it *is* using OO features.

	- Andreas

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

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

0
rossberg (600)
7/2/2004 3:36:00 PM
Don Groves wrote:
{stuff deleted}
> 
> 
> Lisp is not really a functional language, rather it's a
> hybrid which *can* be used in a functional manner but
> rarely is because there are better choices for FP, namely
> Haskell, OCaml, Clean, etc...

Please give me your precise technical definition of a functional language.
Of the languages you listed as "FP" above, the only thing they have in 
common that Lisp does not have is a static type system. I'm sure most people 
would consider the pure untyped lambda calculus to be a functional language.
So I have no idea how you are make this distinction other than via your own 
arbitrary personal opinion.

0
danwang742 (171)
7/2/2004 4:32:23 PM
Dirk Thierbach wrote:
{stuff deleted}
> 
> I didn't mean "powerful" in the sense "it's impossible to do in an OO
> language". I meant it in the sense "it's easy to do and straighforward
> in an FP language, and clumsy in an OO language".

Rephrase the above:

  It is easy to do and straightforward in  *existing* FP languages, and 
clumsy to do in *existing* OO languages.

I won't argue with that. My only point is that there is nothing wrong with 
the OO approach just the design of existing OO languages. There are many 
things that drive me mad about Java. The lack of tuples and type inference. 
These features have nothing to do with HOF vs Objects.

People, are amazingly sloppy when they compare languages. There are specific 
  language design choices that make certain languages a pain to use. Some 
how  all those painful features get turned into one big ugly tarball used to 
complain about not only one given language but a whole family of languages.

I think it is fair to say that because of the design philosophy and history 
many OO languages are not as elegant from an mathematical perspective as FP 
languages. FP languages are of course not as elegant from an engineering 
perspective when compared to OO languages.




0
danwang742 (171)
7/2/2004 4:47:44 PM
On Fri, 02 Jul 2004 09:21:27 -0600, Thant Tessman <thant@acm.org> wrote:

> Don Groves wrote:
>
> [...]
>
>> Ok, I withdraw my assertion, the adult population, in the
>> US anyway, is farther gone than I thought. Plenty of time
>> for movies and video games, yet more than half don't even
>> take the time to vote. How sad...
>
> What would be the point of voting? Do you think it's pure chance the 
> Democratic Party astoundingly managed to find a candidate that actually 
> has a chance of losing against Bush the Younger? Who (against all odds) 
> is *also* a Yale Skull 'n Bones fratboy? Who has no intention of pulling 
> out of Iraq and is in fact likely to increase U.S. military presence 
> there? "They" have already won the election.
>
> Sorry, I'll shut up now.
>
> -thant
>


No, you make good points. But we still must vote!

True, there is little difference between Bush and Kerry
but at least Kerry is not (yet) in the pocket of the
neocons who are running (ruining) the country.

With Kerry, we have some chance of turning the US around
and becoming good world citizens, with Bush, the chance
is zero.
--
dg
0
Don
7/2/2004 4:55:14 PM
Thant Tessman wrote:
{stuff deleted}
> got sick to my stomach long before I reached that part in Abadi 
> Cardelli's "A Theory of Objects." But here's my favorite concise example 
> of how HOFs are so cool:
> 
>     http://makeashorterlink.com/?X5F4425B8
> 
> (Yes, I'm repeating myself.)


http://www.dina.dk/~sestoft/gcsharp/#parsercomb

If they had some decent type inference it wouldn't be soo bad.

{stuff delete}
> If indeed "prototype-based OO calculus" has the properties you attribute 
> to it, I suspect it is only to the degree that it smells like just a 
> different kind of HOF.
Or the reverse. i.e. a HOF is just some weird object.
0
danwang742 (171)
7/2/2004 5:04:14 PM
On Fri, 02 Jul 2004 10:32:43 +0200, Siegfried Gonzi 
<siegfried.gonzi@kfunigraz.ac.at> wrote:

> Don Groves wrote:
>
>> Assignment statements come to mind. I know they can be done in
>> most FPs but I don't think as efficiently. Really fast C pointer
>> constructs also come to mind. Neat side-effect tricks like *p++
>> or a[i++] too. These are all foreign to FP.
>
> I am not objecting your pointer-tricks as they are; it is C business.
>
> But your statement "Thes are all foreign to FP" makes me wondering. I 
> find
> the proposition really strange. Why is it that bad that "FP programming" 
> is
> as it actually is?


I think FP programming is perfectly fine the way it is!

Others seem to think FP languages should do a lot more,
specifically be able to "provide a fully functioning,
skinnable, user interface".

I'm saying if you want something like that, then use a
language that is good at that, don't complain that FP
languages can't do it as easily, or quickly, or <insert
your criterium here>, as others can - or that's it's "hard
to do" in FP.

If you are inserting a screw, you don't use a hammer and
then complain it doesn't do the job well. Some folks seem
to want a hammer that will do every job well.
--
dg


0
Don
7/2/2004 5:12:43 PM
On Fri, 02 Jul 2004 11:51:57 +0200, Ketil Malde <ketil@ii.uib.no> wrote:

> Basically, games are written in C because it gives you decent
> performance, because it's what game developers understand, and it's
> easy to get tools and people for it.  It's the traditional thing, just
> like in most of industry.


This has been my point all along. Others have implied
that when they look at FP languages for game programming,
the FP languages come up short, they have warts that prevent
them from being suitable for programming games.

This is fine, it's their opinion. However, they then try
to blame the FP language for having shortcomings!!!

It doesn't have good enough GUI/widget support.
It doesn't do 32-bit ints.
It has wart #17 and I want #30.
....

"'Tis a poor workman who blames the tool"
--
dg



0
Don
7/2/2004 5:29:06 PM
Don Groves wrote:
> On Fri, 2 Jul 2004 00:00:26 -0700, Brandon J. Van Every
> <try_vanevery_at_mycompanyname@yahoo.com> wrote:
>
>> Don Groves wrote:
>>>
>>> Sure, Lisp is a hybrid FP language that is fast (when
>>> compiled), has many imperative features needed for game
>>> programming,
>>
>> At the risk of repeating the substance of all that has gone before,
>> why does game programming need imperative features?  I see no
>> a priori reason for this.
>
> Assignment statements come to mind.

Assignment is synonymous with imperative programming?  I'd thought that was
more of a 'pure' vs. 'impure' debate.

> I know they can be done in
> most FPs but I don't think as efficiently. Really fast C pointer
> constructs also come to mind. Neat side-effect tricks like *p++
> or a[i++] too. These are all foreign to FP.

Pointer semantics aren't the only route to efficiency.  Other routes are:
unboxed arrays, first class support of native machine types, low overhead C
FFIs, exotic FP compilation technologies.

-- 
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
7/2/2004 5:29:43 PM
On Fri, 2 Jul 2004 10:29:43 -0700, Brandon J. Van Every 
<try_vanevery_at_mycompanyname@yahoo.com> wrote:

> Don Groves wrote:
>> On Fri, 2 Jul 2004 00:00:26 -0700, Brandon J. Van Every
>> <try_vanevery_at_mycompanyname@yahoo.com> wrote:
>>
>>> Don Groves wrote:
>>>>
>>>> Sure, Lisp is a hybrid FP language that is fast (when
>>>> compiled), has many imperative features needed for game
>>>> programming,
>>>
>>> At the risk of repeating the substance of all that has gone before,
>>> why does game programming need imperative features?  I see no
>>> a priori reason for this.
>>
>> Assignment statements come to mind.
>
> Assignment is synonymous with imperative programming?  I'd thought that 
> was more of a 'pure' vs. 'impure' debate.


What makes an FP language "impure" is the inclusion of
imperative, side-effecting features - like assignment.
--
dg

0
Don
7/2/2004 5:47:38 PM
Daniel C. Wang wrote:
> Thant Tessman wrote:
> {stuff deleted}
> 
>> got sick to my stomach long before I reached that part in Abadi 
>> Cardelli's "A Theory of Objects." But here's my favorite concise 
>> example of how HOFs are so cool:
>>
>>     http://makeashorterlink.com/?X5F4425B8
>>
>> (Yes, I'm repeating myself.)
> 
> 
> 
> http://www.dina.dk/~sestoft/gcsharp/#parsercomb
> 
> If they had some decent type inference it wouldn't be soo bad.
> 
> {stuff delete}
> 
>> If indeed "prototype-based OO calculus" has the properties you 
>> attribute to it, I suspect it is only to the degree that it smells 
>> like just a different kind of HOF.
> 
> Or the reverse. i.e. a HOF is just some weird object.

Comparing the size of the C# implementation with mine would suggest that 
it is in fact weirder to use objects as HOFs than the other way 
around--which is all I've ever been saying.

More than that, the main objection to OO is that it can't be reconciled 
with static type systems without crippling it. That is, if you choose to 
make OO your pervasive programming paradigm, you must use dynamic typing 
(CLOS, Dylan, Smalltalk(?)), or cripple your object system to the point 
that you must introduce other mechanisms (C++, Ada). HOFs just seem to 
be an all-around better way to go.

And again to repeat myself, I think there are valuable lessons to be 
learned from OO, but when distilled, these lessons would be 
unrecognizeable by the OO community as OO.

-thant


0
thant (332)
7/2/2004 6:05:21 PM
Thant Tessman wrote:

{stuff deleted}
> Comparing the size of the C# implementation with mine would suggest that 
> it is in fact weirder to use objects as HOFs than the other way 
> around--which is all I've ever been saying.

Of course there are a completely different set of applications where the 
reverse is true. In anycase, ignoring syntax and just focusing on semantics 
there isn't that big a difference.

> More than that, the main objection to OO is that it can't be reconciled 
> with static type systems without crippling it. That is, if you choose to 
> make OO your pervasive programming paradigm, you must use dynamic typing 
> (CLOS, Dylan, Smalltalk(?)), or cripple your object system to the point 
> that you must introduce other mechanisms (C++, Ada). HOFs just seem to 
> be an all-around better way to go.
> 
> And again to repeat myself, I think there are valuable lessons to be 
> learned from OO, but when distilled, these lessons would be 
> unrecognizeable by the OO community as OO.

I think one could say the same thing about FP. :)

0
danwang742 (171)
7/2/2004 6:09:31 PM
Daniel C. Wang wrote:
> Thant Tessman wrote:
> 
> {stuff deleted}
> 
>> Comparing the size of the C# implementation with mine would suggest 
>> that it is in fact weirder to use objects as HOFs than the other way 
>> around--which is all I've ever been saying.
> 
> 
> Of course there are a completely different set of applications where the 
> reverse is true. 

Yet there is a derth of examples once you allow for destructive updates.

[...]

-thant

0
thant (332)
7/2/2004 6:27:58 PM
On Fri, 02 Jul 2004 17:20:17 +0200
Andreas Rossberg <rossberg@ps.uni-sb.de> wrote:

> I spy wrote:
> > 
> > I'm afraid I don't know SML well enough to be able to answer the
> > question, although I do get the general drift of what you're
> > doing. But let me ask you - would this be considered an idiomatic
> > solution in SML? And is it a coding pattern you yourself would use
> > in practice on a large scale (bearing in mind you or someone else
> > might need to pick up the code 5 years down the road)
> 
> If you don't mind me answering for Benjamin (who appearently is not
> reading news on a daily basis): a definite yes to both your
> questions. This is what ML-style modules have been designed for, and
> what I do all the time when writing ML code.

Apologies, I recently began the packing process for a long distance
move; my newsgroup time has been limited.

I also consider the code that I wrote fairly idiomatic SML.  Note that
I was not claiming (nor would I claim) that higher order functions
give FPLs the expressiveness to do *everything* more concisely than
OOPLs.  I was making the more modest point that dependence inversion
as I have come, so recently, to understand it, can be done perfectly
straightforwardly in FPLs.

I would further guess (though I am no expert in these matters) that
*most* of the design patterns that people have come up with for and
expressed in object oriented terms have simple analogues in the FPL
domain.  Of course, this heads us back in the direction of where this
thread started.  To my knowledge, no one has invested the time and
energy in making a significant collection of FPL-termed design
patterns (or design strategies, or tricks of the trade, or whatever).
Compiling and publishing such a collection is a lot of work and I
guess authors and publishers don't believe there is a large enough
audience to make it worthwhile.  And the absence of such a collection
discourages many professional programmers from learning functional
programming.  And such feedback loops provide endless fodder for
arguments about who has a better programming language.

Cheers,
Benjamin
0
benjaminy (25)
7/2/2004 7:47:59 PM
In article <cc4857$a1n$1@news.xmission.com>, Thant Tessman wrote:
> 
> More than that, the main objection to OO is that it can't be reconciled 
> with static type systems without crippling it. That is, if you choose to 
> make OO your pervasive programming paradigm, you must use dynamic typing 
> (CLOS, Dylan, Smalltalk(?)), or cripple your object system to the point 
> that you must introduce other mechanisms (C++, Ada). HOFs just seem to 
> be an all-around better way to go.

Look at Daniel Bonniot's Nice language <http://nice.sourceforge.net>
for a counterexample to this claim. To me, the OO vs. FP argument has
the flavor of an argument about whether products or sums are the more
important types. It's weird even to make the argument because you want
the features of both.


-- 
Neel Krishnaswami
neelk@cs.cmu.edu
0
neelk (298)
7/2/2004 8:28:26 PM
Neelakantan Krishnaswami wrote:
> In article <cc4857$a1n$1@news.xmission.com>, Thant Tessman wrote:
> 
>>More than that, the main objection to OO is that it can't be reconciled 
>>with static type systems without crippling it. That is, if you choose to 
>>make OO your pervasive programming paradigm, you must use dynamic typing 
>>(CLOS, Dylan, Smalltalk(?)), or cripple your object system to the point 
>>that you must introduce other mechanisms (C++, Ada). HOFs just seem to 
>>be an all-around better way to go.
> 
> 
> Look at Daniel Bonniot's Nice language <http://nice.sourceforge.net>
> for a counterexample to this claim. To me, the OO vs. FP argument has
> the flavor of an argument about whether products or sums are the more
> important types. It's weird even to make the argument because you want
> the features of both.

No, I think the Nice programming language makes my point exactly. 
According to the first page, it supports parameterized types and 
"anonymous functions" i.e. lambda. These are exactly the kind of "other 
mechanisms" to which I was refering.

-thant


0
thant (332)
7/2/2004 8:41:35 PM
Thant Tessman wrote:

> Daniel C. Wang wrote:
> 
>> Thant Tessman wrote:
>>
>> {stuff deleted}
>>
>>> Comparing the size of the C# implementation with mine would suggest 
>>> that it is in fact weirder to use objects as HOFs than the other way 
>>> around--which is all I've ever been saying.
>>
>>
>>
>> Of course there are a completely different set of applications where 
>> the reverse is true. 
> 
> 
> Yet there is a derth of examples once you allow for destructive updates.

Umm.. please reimplement the functionality of the Java Swing API in your 
favorite FPL and tell me how much more pretty the code looks. I don't think 
you are being fair. Sure you can transliterate everything to a record of 
functions, but that will get tedious after a while, and then you'll just 
slowly reinvent Java embedded in your language.

Perhaps, you have the mind blowing different way of restructuring the whole 
API that makes it so much more natural. I have yet to see such a mind 
blowing different way to structure GUIs that is equally efficient as the OO 
approaches.
0
danwang742 (171)
7/2/2004 10:17:08 PM
Don Groves wrote:
>
> I think FP programming is perfectly fine the way it is!
>
> Others seem to think FP languages should do a lot more,
> specifically be able to "provide a fully functioning,
> skinnable, user interface".
>
> I'm saying if you want something like that, then use a
> language that is good at that,

Why are you saying FP wouldn't be any good at it?  Sure, all the OSes have
their legacy support issues, and all are written in imperative languages.
But if you had a clean slate to work with, what would stop you from
expressing GUIs using FP?

If you can answer *that* question, then we can start talking about how easy
/ difficult it would be to provide FP interfaces to imperative GUI code.  I
am not convinced it is so difficult.  It's probably only tough if you insist
on 'pure' FP, i.e. no function side effects.

I am again seeing historical accidents.  Most FPers are academics, and most
academics don't like to sully themselves with GUI systems.

-- 
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
7/3/2004 5:31:02 AM
Don Groves wrote:
> On Fri, 2 Jul 2004 10:29:43 -0700, Brandon J. Van Every
> <try_vanevery_at_mycompanyname@yahoo.com> wrote:
>
>> Don Groves wrote:
>>> On Fri, 2 Jul 2004 00:00:26 -0700, Brandon J. Van Every
>>> <try_vanevery_at_mycompanyname@yahoo.com> wrote:
>>>
>>>> Don Groves wrote:
>>>>>
>>>>> Sure, Lisp is a hybrid FP language that is fast (when
>>>>> compiled), has many imperative features needed for game
>>>>> programming,
>>>>
>>>> At the risk of repeating the substance of all that has gone before,
>>>> why does game programming need imperative features?  I see no
>>>> a priori reason for this.
>>>
>>> Assignment statements come to mind.
>>
>> Assignment is synonymous with imperative programming?  I'd thought
>> that was more of a 'pure' vs. 'impure' debate.
>
>
> What makes an FP language "impure" is the inclusion of
> imperative, side-effecting features - like assignment.

Yes, that's what I said.  But people don't talk about impure FP not being
FP.

-- 
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
7/3/2004 5:32:16 AM
Don Groves wrote:
> On Fri, 02 Jul 2004 11:51:57 +0200, Ketil Malde <ketil@ii.uib.no>
> wrote:
>
>> Basically, games are written in C because it gives you decent
>> performance, because it's what game developers understand, and it's
>> easy to get tools and people for it.  It's the traditional thing,
>> just like in most of industry.
>
>
> This has been my point all along. Others have implied
> that when they look at FP languages for game programming,
> the FP languages come up short, they have warts that prevent
> them from being suitable for programming games.

Well, certain FP languages *are* warted.  OCaml does not support 32-bit
ints, 32-bit floats, and has a damn awkward C FFI.  As a 3D graphics game
programmer, I find this unacceptable.  But these aren't FP problems, they're
OCaml problems.  There are all sorts of FP languages that are 'too academic'
for my use.  I've been gravitating towards those that are less academic and
more performance oriented, like SML/NJ and MLton.  Although, I think it
would be unfair to call OCaml 'not performance oriented', they're just
insufficiently performance oriented for my problem domain.

Haskell is damn slow and a poster child for exotic FP.  Meanwhile, Lisp and
Scheme compilers really don't have performance problems.

> This is fine, it's their opinion. However, they then try
> to blame the FP language for having shortcomings!!!

I don't blame the paradigm of FP for these problems.  I blame specific
researchers who aren't terribly interested in industrial performance
problems.  I can say the same thing about Python.  But, Python has enough
critical mass behind it that within a few years, someone will solve most of
the performance problems.  That isn't today though.

> "'Tis a poor workman who blames the tool"

I don't think that's a valid proverb in software development.  As someone
who has spent a *lot* of time trying to fit languages to my problem domains,
I can say with confidence that no options meet all desired criteria.  All of
our language tools are woefully inadequate in at least 1 or 2 key respects.
They just differ as to which respect.  There's much room for improvement of
computer languages, and unfortunately the evolution is sloooooooooooow.

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

"Trollhunter" - (n.) A person who habitually accuses
people of being Trolls.

0
7/3/2004 5:41:55 AM
On Fri, 2 Jul 2004 22:41:55 -0700, Brandon J. Van Every 
<try_vanevery_at_mycompanyname@yahoo.com> wrote:

> Don Groves wrote:
>> On Fri, 02 Jul 2004 11:51:57 +0200, Ketil Malde <ketil@ii.uib.no>
>> wrote:
>>
>>> Basically, games are written in C because it gives you decent
>>> performance, because it's what game developers understand, and it's
>>> easy to get tools and people for it.  It's the traditional thing,
>>> just like in most of industry.
>>
>>
>> This has been my point all along. Others have implied
>> that when they look at FP languages for game programming,
>> the FP languages come up short, they have warts that prevent
>> them from being suitable for programming games.
>
> Well, certain FP languages *are* warted.  OCaml does not support 32-bit
> ints, 32-bit floats, and has a damn awkward C FFI.  As a 3D graphics game
> programmer, I find this unacceptable.  But these aren't FP problems, 
> they're
> OCaml problems.  There are all sorts of FP languages that are 'too 
> academic'
> for my use.  I've been gravitating towards those that are less academic 
> and
> more performance oriented, like SML/NJ and MLton.  Although, I think it
> would be unfair to call OCaml 'not performance oriented', they're just
> insufficiently performance oriented for my problem domain.


So, you've corroborated my point again, today's available FP
languages are not suitable for game programming, as defined
by your performance criteria.  You're saying the same thing
I am, just using more words.


> Haskell is damn slow and a poster child for exotic FP.

You think Haskell is an exotic FP? - check out K, an almost
pure combinator language. Blazing fast too, if you can believe
their specs. It's not cheap, though.


>> This is fine, it's their opinion. However, they then try
>> to blame the FP language for having shortcomings!!!
>
> I don't blame the paradigm of FP for these problems.  I blame specific
> researchers who aren't terribly interested in industrial performance
> problems.

Why "blame" anyone? It is the way it is! So FP researchers are
not into performance issues as much as you'd like - fact of life.
Accept it and get on with it - if you think FP can be used
effectively for games, then start writing, prove it and I'll shut
up. For myself, (and I think 99% of others) if I was into writing
games, I'd choose something else. This doesn't mean you're wrong
and I'm right, or vice versa - as I've been saying all along, it's
personal choice.


>> "'Tis a poor workman who blames the tool"
>
> I don't think that's a valid proverb in software development.  As someone
> who has spent a *lot* of time trying to fit languages to my problem 
> domains,
> I can say with confidence that no options meet all desired criteria.  
> All of
> our language tools are woefully inadequate in at least 1 or 2 key 
> respects.
> They just differ as to which respect.  There's much room for improvement 
> of
> computer languages, and unfortunately the evolution is sloooooooooooow.
>

Yeah, you're probably more correct than I about this one.
--
dg
0
Don
7/3/2004 6:31:52 AM
On Fri, 2 Jul 2004 22:31:02 -0700, Brandon J. Van Every 
<try_vanevery_at_mycompanyname@yahoo.com> wrote:

> Don Groves wrote:
>>
>> I think FP programming is perfectly fine the way it is!
>>
>> Others seem to think FP languages should do a lot more,
>> specifically be able to "provide a fully functioning,
>> skinnable, user interface".
>>
>> I'm saying if you want something like that, then use a
>> language that is good at that,
>
> Why are you saying FP wouldn't be any good at it?  Sure, all the OSes 
> have
> their legacy support issues, and all are written in imperative languages.
> But if you had a clean slate to work with, what would stop you from
> expressing GUIs using FP?

I've never said you *can't* express a gui in FP, I've only
said it won't be an efficient solution compared to many
other choices of langauge and it will very likely take more
programmer time as well.


> I am again seeing historical accidents.  Most FPers are academics, and 
> most
> academics don't like to sully themselves with GUI systems.

I won't speculate on their motives but GUIs don't seem
to be a high research priority, true.
--
dg

0
Don
7/3/2004 6:36:02 AM
On Fri, 2 Jul 2004 22:41:55 -0700, Brandon J. Van Every 
<try_vanevery_at_mycompanyname@yahoo.com> wrote:

> ...  I can say the same thing about Python.  But, Python has enough
> critical mass behind it that within a few years, someone will solve most 
> of the performance problems.  That isn't today though.


It may be closer than you think, look here:

http://psyco.sourceforge.net
--
dg
0
Don
7/3/2004 6:38:32 AM
Daniel C. Wang <danwang74@hotmail.com> wrote:
> Dirk Thierbach wrote:
> {stuff deleted}
>> 
>> I didn't mean "powerful" in the sense "it's impossible to do in an OO
>> language". I meant it in the sense "it's easy to do and straighforward
>> in an FP language, and clumsy in an OO language".

> Rephrase the above:

>  It is easy to do and straightforward in  *existing* FP languages, and 
> clumsy to do in *existing* OO languages.

I can only talk about things I know, i.e. *existing* languages. 

> I won't argue with that. My only point is that there is nothing wrong with 
> the OO approach just the design of existing OO languages. 

I didn't say there is anything wrong in the OO approach (and I agree
there are lots of things wrong in the design of existing OO languages).

The point I am trying to make is that lambda abstraction is often a
better (read: simpler, more straightforwd) abstraction facility than
the OO approach (i.e., creating a class hierarchie and a "net" of
objects to model the abstraction). If the OO language offers some way
to simulate making lambda abstractions (blocks in Smalltalk, or some
features in some OO calculi), then all the better. But this is still
an inherently functional idea (after all, it's the fundamental idea of
the lambda calculus), and not an idea that comes out of the OO
aproach.

> There are many things that drive me mad about Java. The lack of
> tuples and type inference.  These features have nothing to do with
> HOF vs Objects.

Yes. I wasn't talking about those at all.

> People, are amazingly sloppy when they compare languages. 

Yes. And I am not comparing languages, all I wanted to was to make
some point about two particular approaches to abstraction. Lambda
abstraction and HOFs are very good for certain things, and OO-inspired
class hierarchies and object models are very good for other
things. None subsumes the other (though one can simulate the other to
some degree), but the first is more general, and more straightforward
in many cases. Though it's IMHO still a pain to simulate a large
amount of state with closures, or with any of the other ways people
have tried to do it in pure FP. In this case, the OO aproach is more
straightforward.

And you need experience in both of them to appreciate that. Both
approaches lead to a different kind of thinking, and unsurprisingly
people with only experience in one of them are "blind" to the
advantages of the other, and to the disadvantages of the one they
know.

[Other comments snipped]
I completely agree with the rest of your comments, but they have nothing
to do with the point I am trying to make :-)

- Dirk
0
dthierbach (210)
7/3/2004 7:22:27 AM
Daniel C. Wang wrote:
> Thant Tessman wrote:
> 
>> Daniel C. Wang wrote:
>>
>>> Thant Tessman wrote:
>>>
>>> {stuff deleted}
>>>
>>>> Comparing the size of the C# implementation with mine would suggest 
>>>> that it is in fact weirder to use objects as HOFs than the other way 
>>>> around--which is all I've ever been saying.
>>>
>>>
>>>
>>>
>>> Of course there are a completely different set of applications where 
>>> the reverse is true. 
>>
>>
>>
>> Yet there is a derth of examples once you allow for destructive updates.
> 
> 
> Umm.. please reimplement the functionality of the Java Swing API in your 
> favorite FPL and tell me how much more pretty the code looks. [...]

It's funny you should bring this up as an example, because it was 
exactly my dissatisfaction with traditional input event messaging that 
convinced me that OO was the Wrong Thing (TM) and eventually inspired me 
to add pseudo-closures to C++ to allow for a more FP-like approach.

Take the simplest example one could imagine: Suppose you have a UI 
component such as a slider that produces data when manipulated. How do 
you send that data to some other object in a type-safe manner? (By 
"type-safe manner" I mean in a way where you know at compile time that 
there will be no "message not understood" error.)

Traditional OO suggests that the object that receives the data implement 
a method corresponding to the "message" the slider is sending. But if 
the slider was written before the receiving object (which is something 
we should expect if it is an "off-the-shelf" UI component), how can it 
know at compile time that the object supports the assumed method? The 
answer, we are told, is that the receiving object must inherit from a 
superclass which the slider knows about, and implement its version of a 
virtual method specified in the superclass.

But this is far from satisfactory. Why should my consumer object have to 
care where the data comes from? Why should the semantics of the data be 
pinned down in advance in the form of a message? What if the consumer 
object has several inputs, all of which should be able to accept data 
from UI slider components?

What you want is to package up the receiver, and the "method" into a 
single function-like object and pass that to the slider. This can be 
done in a type-safe manner. But once you have this kind of capability, 
it becomes less clear why you need the "method" (as opposed to merely 
other functions) in the first place.

At this point one might just come to the conclusion that OO is a bunch 
of nonsense.

-thant


0
thant (332)
7/3/2004 9:57:47 AM
On Tue, 22 Jun 2004 16:28:11 -0400, Simon Helsen wrote:

> I understand this, but I find it bizar to call a variable first-class.

Variables in Java are not first-class, and this is its weakness. When you
want to pass a variable (not its value) to a function, you have to replace
the variable with an object- (either a custom object with one field, or a
one-element array hack.

Variables are first-class in several other languages. Quite a lot I would
say, even though the most common modern paradigm of variables being
references to objects doesn't naturally provide first-class variables.

They are first-class in C, C++, Turbo Pascal (not standard Pascal), and
Perl. You can take a pointer to a variable and do everything with the
variable through the pointer. These languages keep objects inside
variables, not referred to by variables. Except in Perl, the lifetime
of the variable is statically determined, unfortunately.

They are first-class in SML, OCaml and Glasgow Haskell. In these languages
immutable variables are equivalent to their values, and mutable variables
are explicit objects. Writing a name of a variable denotes the variable
itself, and you must explicitly dereference them.

They are first-class in Algol 68. The type system with its rules of
implicit coercions determines when you pass the variable and when you pass
its current value.

They are first-class in Prolog. When you use a predicate with a variable,
the predicate can instantiate its parameter, which is propagated to the
variable.

They are first-class in my languge Kogut
<http://kokogut.sourceforge.net/kogut.html>, even though syntactically
the name of a mutable variable denotes its current value. You write
"ref variable" to pass it around - it's an ordinary object similar to ML
ref, only living in a dynamically typed language.

They are not quite first-class in C#. You can pass "ref variable" to
a function, but you can't store it in a data structure nor return it
from a function.

Global variables are first-class in Common Lisp, because such variable
is embedded in a symbol and you can pass a whole symbol around. Local
variables are not first-class though.

* * *

There are some languages where variables are not first-class, but it's
possible to wrap a variable in a pair of functions and pass the functions
around. The distinction from the previous group is not strict, but I would
say that the amount of code needed to wrap the variable in an object
changes the classification.

Languages in this group include Scheme, Common Lisp, Smalltalk, and Ruby.
They all support closures. The runtime typically represents the variable
by a first-class object if it's attached to a closure.

I'm not sure about C#. If you can assign variables from local functions,
it's in this group.

* * *

Finally in some languages you can't pass a variable even using elaborate
wrapping. You must change the way a variable is defined, and the way it is
read and written, if you want to pass it as an object in one plce.

They include Java and Python.

In Python the runtime is ready for first-class variables (variables
attached to closures are *represented* by first-class objects, because
the function which created them may change their value before the closure
is used), but Python provides no source syntax for changing such variables
from local functions.

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

0
qrczak (1266)
7/3/2004 1:27:19 PM
Dirk Thierbach wrote:

{stuff deleted}
> The point I am trying to make is that lambda abstraction is often a
> better (read: simpler, more straightforwd) abstraction facility than
> the OO approach (i.e., creating a class hierarchie and a "net" of
> objects to model the abstraction). If the OO language offers some way
> to simulate making lambda abstractions (blocks in Smalltalk, or some
> features in some OO calculi), then all the better. But this is still
> an inherently functional idea (after all, it's the fundamental idea of
> the lambda calculus), and not an idea that comes out of the OO
> aproach.

Okay, let me make my claims a bit more clear. First, I am completely 
ignoring issues of syntax, and how ugly it is or isn't to create these 
things. I'm concerned with the underlying "semantic" notion of a HOF or an 
Object.

What is an HOF? One could say it's just a closure consisting of a function 
pointer and associated lexical environment.

What is an Object? Well it's just a record of functions plus some private 
state. To me at a very abstract level these two things are basically the 
same. In fact one can see the object as a generalization of the closure.

Of course this is not exactly true and gets complicated because of typing 
issues. However, on the face of it it's not immediately obvious why one 
concept should be preferable to the other.

There are many many practical issues, I'm completely shoving under the rug. 
There is this whole historical practice of OO programing I'm ignoring. I'm 
just asking the simple question conceptually speaking how different are HOF 
and Objects.

They are more alike then different. Unfortunately, there is so much 
historical and sociological cruft that makes them seem different. Anyway, 
I'm happy both C# and Java now have generics. There seems to be some hope of 
  sneaking in useful advanced features from the FP academic universe into 
"real systems".

There's this great POPL paper last year that explains how to use quite 
sophisticated thype systems based on intensional type analysis to implement 
generics in C#. The other tidbit I turned up was that both the C# and Java 
support of generics was a result of a "my languages is obviously cooler than 
yours" marketing issue. I.e. competition in the marketplace is encouraging 
the two camps to add features so they can claim they have the "uber language".

Who knows maybe we will see type-inference for Java and C# next! Then maybe 
even pattern matching which they will all call "multi-methods" or some such 
confusing term. Maybe, they will even build in better syntax for iterators 
(aka. lazy streams) and lightweight anonymous objects (lambda). Then support 
for call-cc which they will call something entirely confusing but say its 
great for building web apps!

Perhaps, I'm dreaming but who knows maybe one day we will be programming 
functionally in C# version 10.0 or Java version 10.0. (Okay, I'm dreaming a 
bit.... but actually only a bit...)
0
danwang742 (171)
7/3/2004 2:46:23 PM
Don Groves wrote:
> On Fri, 2 Jul 2004 22:41:55 -0700, Brandon J. Van Every
>>
>> Well, certain FP languages *are* warted.  OCaml does not support
>> 32-bit ints, 32-bit floats, and has a damn awkward C FFI.  As a 3D
>> graphics game programmer, I find this unacceptable.  But these
>> aren't FP problems, they're
>> OCaml problems.  There are all sorts of FP languages that are 'too
>> academic'
>> for my use.  I've been gravitating towards those that are less
>> academic and
>> more performance oriented, like SML/NJ and MLton.  Although, I think
>> it would be unfair to call OCaml 'not performance oriented', they're
>> just insufficiently performance oriented for my problem domain.
>
>
> So, you've corroborated my point again, today's available FP
> languages are not suitable for game programming, as defined
> by your performance criteria.  You're saying the same thing
> I am, just using more words.

No, you're making a sweeping generalization about FP languages and I'm not.
I think SML/NJ and MLton probably *are* suited to game development, although
I don't have proof of concept yet.  Various Lisps and Schemes will work,
some being better options than others.  Even OCaml would work if I was
willing to give certain things up.  It's fairly fast, has an OpenGL binding,
and a strong programming community.  I'm just anal about performance which
is why I'm trying SML/NJ and MLton.  Erlang would be appropriate for a MMOG.

> You think Haskell is an exotic FP? - check out K, an almost
> pure combinator language. Blazing fast too, if you can believe
> their specs. It's not cheap, though.

Looks like it's oriented towards banks, not games.  I'd be interested if I
was writing a MMOG.  On the other hand, if I was doing that, I'd look at
Erlang first.

>> I don't blame the paradigm of FP for these problems.  I blame
>> specific researchers who aren't terribly interested in industrial
>> performance problems.
>
> Why "blame" anyone? It is the way it is!

Because specific researchers make choices that help or hinder language
adoption.  I don't agree with your fatalism.  I think academics can be
educated on how to foster open source culture and growth, without tremendous
resource expenditure on their parts.  The key is delegating tasks to
volunteers actually willing to do the work, and not getting in their way.

> if you think FP can be used
> effectively for games, then start writing, prove it and I'll shut
> up.

I really don't care whether you wish to shut up or not.  I was already on a
FP gaming R&D trajectory long before we started having this conversation.
The only 'proof' that matters to the game industry is me making lotsa money.
That's not going to happen for awhile no matter what goes right, so you've
got lotsa time to say whatever you want to say.  You might, however, be
interested in broadening your horizons rather than just saying things.

The bottom line is I see no a priori, theoretical reasons why FP can't be
used for game development.  I see plenty of industrial, in-practice reasons
why it could be a PITA.  Those hurdles can be overcome, if one chooses the
right language and builds a community.  It's all a question of whether
you're going to take the high road, or persist in the low road / what
everybody else is doing.

> For myself, (and I think 99% of others) if I was into writing
> games, I'd choose something else. This doesn't mean you're wrong
> and I'm right, or vice versa - as I've been saying all along, it's
> personal choice.

Would you care to elucidate your values as a game developer?  What's most
important to you?

-- 
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
7/3/2004 4:42:23 PM
Don Groves wrote:
> On Fri, 2 Jul 2004 22:41:55 -0700, Brandon J. Van Every
> <try_vanevery_at_mycompanyname@yahoo.com> wrote:
> 
>> ...  I can say the same thing about Python.  But, Python has enough
>> critical mass behind it that within a few years, someone will solve
>> most of the performance problems.  That isn't today though.
> 
> 
> It may be closer than you think, look here:
> 
> http://psyco.sourceforge.net

Psyco does not provide the kind of performance I'm interested in.

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

Taking risk where others will not.

0
7/3/2004 4:43:06 PM
Thant Tessman wrote:
>
> What you want is to package up the receiver, and the "method" into a
> single function-like object and pass that to the slider. This can be
> done in a type-safe manner. But once you have this kind of capability,
> it becomes less clear why you need the "method" (as opposed to merely
> other functions) in the first place.
>
> At this point one might just come to the conclusion that OO is a bunch
> of nonsense.

Well, I've certainly been back and forth over many 'ownership problems' when
creating OO class hierarchies.  This has led me to observe that many things
are relations, not objects with clean boundaries.  A generalized graph can
describe relations.  If you now take that same graph and enforce acyclicity,
or worse, a single inheritance hierarchy, you have arbitrarily destroyed
quite a lot of relations.  If you consider the permutation complexity of
which relations you should destroy and which you should preserve, you see
that nailing an OO design is highly problematic.

-- 
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
7/3/2004 4:52:51 PM