The copy everything worry

The copy everything worry

Post by Brandon J. » Thu, 21 Oct 2004 19:39:10


Once upon a time, someone described pure FP as this big tree of expanded,
unchanging, constant states in cloud cuckooland that does absolutely
nothing. No 'computation' is done; you just walk the graph from wherever
your starting input is.

As compared to the 'stateful' programming typical of imperative languages,
this strikes me as a good idea only if you have few states to manage. If
your app expands many states, and those state expansions are actually needed
to deal with the problem domain, then who are you kidding with this cloud
cuckoo tree? You are going to consume all of your available system
resources trying to lay out this thing. The iterative approach is far more
compressed, it doesn't have to lay out the cloud cuckoo tree in advance.

But, someone had to call state changes "the goto of something or other." So
we get all these FPers running around with the copying worry. Copy
everything! Gads don't change that state! Most of the iterative guys
object that it's inefficient in the small. I think for many classes of
problems, it's important to realize it's also inefficient in the big! You
can't afford to 'lay out' the permutations of every problem in advance.

I suppose that people more clever than I am will now have a strictness vs.
laziness discussion.

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

"Troll" - (n.) Anything you don't like.
Usage: "He's just a troll."
 
 
 

The copy everything worry

Post by Marcin 'Qr » Thu, 21 Oct 2004 19:56:13

"Brandon J. Van Every" < XXXX@XXXXX.COM > writes:


It's not like this. It's not static: computation is done by constantly
producing new trees and forgetting about some old trees. (And it's not
one tree, but separate trees in separate variables, possibly sharing
their parts, but the previous issue is more important.)

--
__("< Marcin Kowalczyk
\__/ XXXX@XXXXX.COM
^^ http://www.yqcomputer.com/ ~qrczak/

 
 
 

The copy everything worry

Post by Jerzy Karc » Thu, 21 Oct 2004 20:04:00


Now, will this trolling start again...? Marcin, whom are you trying to
convince?


Jerzy Karczmarczuk
 
 
 

The copy everything worry

Post by Brandon J. » Thu, 21 Oct 2004 20:31:39


I'm thinking about problems that are so complicated in their state expansion
that you cannot simply forget the trees. AI problems in particular. Well,
then again, maybe one admits the intractability of various problems and
chooses to forget something. Regardless of language, or 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.
 
 
 

The copy everything worry

Post by Brandon J. » Thu, 21 Oct 2004 20:32:17


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

"Troll" - (n.) Anything you don't like.
Usage: "He's just a troll."
 
 
 

The copy everything worry

Post by Vincenzo C » Thu, 21 Oct 2004 22:43:01


In purely functional programming you don't "do" state, but you interact with
it using various methods - if you want to "lay out" the state graph surely
you can use lazyness, even in strict languages using closures, and you
often do such a thing even in imperative languages, but sometimes as you
noticed this just doesn't pay off, so you want "true" mutable state. There
are techniques interact with it even in pure languages, this meaning that
the "functional programming guys" already knew.

V.

--
Please notice that my e-mail address has been altered to prevent spam
 
 
 

The copy everything worry

Post by Alex Drumm » Thu, 21 Oct 2004 23:26:49

You're really not making any sense. It's very easy to simulate state in a
pure language without being too inefficient (assuming a decent compiler).
There are a few difficulties (e.g. it's not trivial to implement an
efficient hash-table like data structure without using mutable values), but
all your vague waffling about "state expansion" and "trees" seems to be
ignoring any concrete or theoretical issue that could possibly arise. Can
you give us an actual example of a program in a pure language which
exhibites the problems you are attempting to allude to?

Alex
 
 
 

The copy everything worry

Post by Jonathan B » Thu, 21 Oct 2004 23:51:00


If you can't forget the trees then you couldn't do without the trees in
an imperative language. If an imperative language can modify the value,
then a functional language can forget the tree.

Jon
----
Learn to program using Linux assembly language
http://www.yqcomputer.com/
 
 
 

The copy everything worry

Post by Brandon J. » Fri, 22 Oct 2004 02:31:25


Nah, I can't. Rather, I'm seeing an abstract motive for the imperative
paradigm, as more useful than a mere GOTO. Avoiding state is a lot of
*** and discipline for unclear gains.

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

The copy everything worry

Post by Tomasz Zie » Fri, 22 Oct 2004 03:55:09


Did you try to learn programming in functional style? If you honestly
did, maybe you wouldn't be posting such rubbish. The motive you gave
for imperative paradigm doesn't make much sense.

There are reasons for imperative programming - you may want to be as
close to the (imperative) machine as possible, your problem may be
easier/more efficient/more natural to solve imperatively, you may want
to implement a run-time system for a functional language, etc.

Functional programmers don't claim that imperative paradigm is
unnecessary, after all almost all functional programming languages, even
the pure ones, allow to use imperative mechanisms. The claim is rather
that imperative paradigm is needed much less often than imperative guys
think and that often functional solution is nicer in many ways.

Tomasz

--
.signature: Too many levels of symbolic links
 
 
 

The copy everything worry

Post by Daniel C. » Fri, 22 Oct 2004 12:28:40


I have read this paper. It is completely unconvincing and wrong.

<flame>
If you read the above paper and believe it's conclusion.
You clearly have never written "real" software, and will believe anything
just be cause it's written up in TeX by a reputable academic.
</flame>

In particular this final comment by Hughes is completely unsupported
non-sense and reflects his personal bias.


There are many reasons to *believe* that lazy evaluation is a "good thing".
In practice I'd say there is little evidence that shows it is as a good
thing as it is believed to be.
 
 
 

The copy everything worry

Post by Vincenzo C » Fri, 22 Oct 2004 16:26:34


I am graduated in computer science and work as a coder, and just don't need
such an article to know what functional programming is good for, so I can't
judge it - I adviced it just because it's one of the most popular, but I
warned that there are "lots of papers" on the subject, which seems the
topic of the discussion, i.e. "why don't you always use mutable state". OK,
shame on me :)

V.

--
Please notice that my e-mail address has been altered to prevent spam
 
 
 

The copy everything worry

Post by Joachim Du » Fri, 22 Oct 2004 20:03:12


Right on: higher-orderness is an excellent abstraction facility.

One nit to pick: I'd even say that absence of side effects matters even
if you don't have lazy evaluation. In a strict language, it helps if the
HOF doesn't have to observe constraints on the order in which some
submitted functions may be called, or how often to call them.


It's even simpler.

For communication between subroutines, it's better to move all
communication channels into the parameters and return values, because it
makes them explicit. Implicit channels are viable only if you have
strong modularization (and OO with implementation inheritance doesn't
offer this because subclasses may decide to play by different rules).

For communication within a subroutine, state isn't a problem. It's
already a general recommendation to use a local variable just for a
single purpose, so people are already working in a functional style
(unless they're programming loops, which can be conveniently wrapped
using HOFs in a functional language).

The trend is towards avoiding program-internal state anyway :-)

The exceptions being:
a) Efficiency (as always), sometimes even with good reason (large
arrays). This is a serious issue, since large arrays aren't going to go
away (array sizes tend to grow with available RAM, and if it's graphics,
there's always a better frame rate to achieve). Various approaches
exist, it's just unclear which of them lends itself to the cleanest
approach.
b) Interaction with external state. Several satisfactory approaches
exist (I know about at least two, the IO monad and modal systems), and
it remains to be seen which of them works best in practice.
c) Interaction with C libraries. That's a mess. Well, interfacing with C
is generally a mess, and C libraries tend to have more gratuitous state
than anything else. There's a *large* conceptual gap between most C
libraries and the stateless world. My expectation is that FPLs are
"ready for the masses" as soon as they have a critical mass of
libraries, many of them "functionalized" interfaces to classical C APIs,
others complete rewrites. (This could be furthered if an FPL can
generate libraries with an easy-to-use C interface. I think such
libraries would make far better showcases for FPL ideas than anything else.)

Regards,
Jo
 
 
 

The copy everything worry

Post by gmatthe » Sat, 23 Oct 2004 00:50:33


If the problem is so complicated that you cannot simply forget trees,
then whether you are using an imperative or functional language won't
make any difference whatsoever, as in either case you will have to
remember past trees ...

graham