But the real world has mutable state...
Dave Benjamin
Every so often, I get into an argument with another programmer about side
effects and mutable state. I'm sure you've heard this argument before: "But
the real world has mutable state!" (or "side effects!", etc.). My first
instinct is to just laugh, thinking to myself, "obviously this person has
never tried functional programming or they wouldn't be saying such a thing."
But if I were to verbalize this opinion, I'd just come out sounding like a
snob, so I usually just say something pragmatic, like "yeah, but the idea is
to reduce state dependency as much as possible", or "if you can write
something without side effects, you probably should."
I'm not looking for better ammunition for pointless arguments, or supporting
evidence that I am right and they are wrong. I realize that there are many
ways to attack software problems, and that just because I see a lot of value
in functional methods doesn't mean others will agree with me, no matter how
much I try to convince them. But I am interested in your viewpoints in this
newsgroup: how would you typically respond to such a statement in a
constructive, thoughtful way?
Thanks,
Dave
--
.:[ dave benjamin: ramen/[sp00] -:- spoomusic.com -:- ramenfest.com ]:.
"When the country is confused and in chaos, information scientists appear."
Librarian's Lao Tzu: http://www.geocities.com/onelibrarian.geo/lao_tzu.html
Glynn Clements
Dave Benjamin <ra...@lackingtalent.com> writes:
> Every so often, I get into an argument with another programmer about side
> effects and mutable state. I'm sure you've heard this argument before: "But
> the real world has mutable state!" (or "side effects!", etc.). My first
> instinct is to just laugh, thinking to myself, "obviously this person has
> never tried functional programming or they wouldn't be saying such a thing."
> But if I were to verbalize this opinion, I'd just come out sounding like a
> snob, so I usually just say something pragmatic, like "yeah, but the idea is
> to reduce state dependency as much as possible", or "if you can write
> something without side effects, you probably should."
>
> I'm not looking for better ammunition for pointless arguments, or supporting
> evidence that I am right and they are wrong. I realize that there are many
> ways to attack software problems, and that just because I see a lot of value
> in functional methods doesn't mean others will agree with me, no matter how
> much I try to convince them. But I am interested in your viewpoints in this
> newsgroup: how would you typically respond to such a statement in a
> constructive, thoughtful way?
Functional programming doesn't preclude mutable state; it just
requires that you make it explicit. Rather than every function having
the entire observable state of the universe as both an implicit input
and output, you have to explicitly declare it, e.g.:
foo :: x -> State -> (y, State)
or:
type StateTrans s a = s -> (a, s)
foo :: x -> StateTrans State y
By making the state an explicit value, you can:
+ Isolate specific components of the state, i.e. a function can depend
upon and/or change some parts of the state whilst guaranteeing that it
doesn't depend upon or change other parts.
+ Implement non-deterministic computations, e.g. backtracking, "what
if" calculations, atomic transactions.
+ Keep multiple states around (e.g. per-user, per-document,
per-whatever).
Consider the situation for a program which uses global variables; what
happens when the specification is subsequently expanded to require
multiple independent "contexts"?
Actually, even if you decide that you need multiple contexts at the
outset, trying to get this fact into the heads of die-hard static
variable addicts can be non-trivial. I've been involved in one project
where I ended up running a cron job which would build the project then
run "nm" on the object files in order to catch programmers using
static variables even though they were specifically told not to.
--
Glynn Clements <glynn.c...@virgin.net>
Hamilcar Barca
01:11:14 +0000), Dave Benjamin wrote:
> Every so often, I get into an argument with another programmer about
> side effects and mutable state. I'm sure you've heard this argument
> before: "But the real world has mutable state!" (or "side effects!",
> etc.).
Ask the other programmer if he or she is able to use the real world as a
programming language.
> "yeah, but the idea is to reduce state dependency as much as possible"
It's useful to reduce all dependencies, state or otherwise, to some
"optimum" level.
> I'm not looking for better ammunition for pointless arguments, or
> supporting evidence that I am right and they are wrong.
As you seemed to note, you aren't necessarily right. Some problems have a
more elegant, efficient, or whatever solution using functional methods;
some do not. The only reasonable avenue of attack is to show the benefits
(versus costs) of your way by demonstrating the solution of some problem
they find interesting.
> But I am interested in your viewpoints in this newsgroup: how would you
> typically respond to such a statement in a constructive, thoughtful way?
I realize I'm not responding directly to your request, but if the position
you're trying soften is supported by "the real world ...", how much can
you hope to accomplish? This is a religious argument not a technical
argument.
Dave Benjamin
>
> Functional programming doesn't preclude mutable state; it just
> requires that you make it explicit. Rather than every function having
> the entire observable state of the universe as both an implicit input
I think that this is an excellent point. A popular misconception is that
functional programming requires purity, but functional software doesn't have
to be purely functional any more than OO software has to be purely OO. But
one thing I notice in programmers who have not had experience in functional
programming is that they don't even think about side effects. They introduce
lots of tricky order dependencies into their code without even realizing it.
I like what Doug Bagley wrote in his Functional Programming Koans:
The Koan of Side Effects
A student of FP came to Daniel de Rauglaudre and asked how to achieve FP
Nature. Daniel replied, "to achieve FP Nature, you must learn to program
without side effects and other imperative features". So the student went
away to learn how to program in this style. He studied very hard so he could
rid his programs of references and for-loops. He struggled to only use let
bindings and let rec loops. One day, in order to find inspiration, he was
studying the code of the Masters, and in reading the source of Camlp4, he
saw a number of uses of references and for-loops! He rushed back to Daniel
de Rauglaudre and exclaimed, "How can you tell me not to use imperative
features when you use them yourself!" Daniel measured the student carefully
in his gaze and replied, "But I already know how to program without
side-effects." At that moment the student was enlightened.
(http://www.bagley.org/~doug/ocaml/Notes/okoans.shtml)
> By making the state an explicit value, you can:
>
> + Isolate specific components of the state, i.e. a function can depend
> upon and/or change some parts of the state whilst guaranteeing that it
> doesn't depend upon or change other parts.
I think this is a tremendous aid in debugging and understanding software. I
especially run into a need for isolation like this in web applications,
where the inputs to a page handler are often completely undocumented and
hard to determine. Rather than clearly specifying what inputs and outputs
you expect, you've often got this nebulous bundle of assorted data called
the "form", and the actual function of the page may be completely different
depending on what form variables were present, what cookies and/or session
variables exist, and so on...
> + Implement non-deterministic computations, e.g. backtracking, "what
> if" calculations, atomic transactions.
Interesting point. I have little experience with that sort of thing, but
you've got me thinking now.
> + Keep multiple states around (e.g. per-user, per-document,
> per-whatever).
This leads to an interesting twist on the "real world" issue: by keeping
previous states instead of overwriting them, not only can you (supposedly)
model the real world, but you can ask questions about *which* real world
you're interested in - the one right now, or the one five minutes ago?
> Consider the situation for a program which uses global variables; what
> happens when the specification is subsequently expanded to require
> multiple independent "contexts"?
Well, this is equally a problem with or without side effects, wouldn't you
say? I mean, objects give us mutable contexts, but sometimes this isn't what
we want either.
> Actually, even if you decide that you need multiple contexts at the
> outset, trying to get this fact into the heads of die-hard static
> variable addicts can be non-trivial. I've been involved in one project
> where I ended up running a cron job which would build the project then
> run "nm" on the object files in order to catch programmers using
> static variables even though they were specifically told not to.
Heh... unit testing the employees, huh? =)
Dave Benjamin
> In article <slrnch0erf...@lackingtalent.com> (Wed, 04 Aug 2004
> 01:11:14 +0000), Dave Benjamin wrote:
>
>> Every so often, I get into an argument with another programmer about
>> side effects and mutable state. I'm sure you've heard this argument
>> before: "But the real world has mutable state!" (or "side effects!",
>> etc.).
>
> Ask the other programmer if he or she is able to use the real world as a
> programming language.
Wow. I wasn't expecting a response like that. =) Maybe we should ask Noam
Chomsky whether mutable state is useful in controlling the public mind.
>> "yeah, but the idea is to reduce state dependency as much as possible"
>
> It's useful to reduce all dependencies, state or otherwise, to some
> "optimum" level.
That's a more pragmatic way of putting it. But I think it's important to
know when you're introducing state dependencies, especially when the
mainstream languages do little to create such an awareness.
>> I'm not looking for better ammunition for pointless arguments, or
>> supporting evidence that I am right and they are wrong.
>
> As you seemed to note, you aren't necessarily right. Some problems have a
> more elegant, efficient, or whatever solution using functional methods;
> some do not. The only reasonable avenue of attack is to show the benefits
> (versus costs) of your way by demonstrating the solution of some problem
> they find interesting.
Right. Ultimately, it depends on context, and usually, this discussion comes
up without any context. People I work with wonder why I'm so interested in
this stuff, and they like to take cheap shots. But there is a point to what
they are saying, too - the world does have mutation, and it's in fact a
pretty normal and typical thing. If you view software as an attempt of
simulating the world, then it seems mutation must be a part of that picture.
Is all software simulation? I'm not sure of the answer to that.
>> But I am interested in your viewpoints in this newsgroup: how would you
>> typically respond to such a statement in a constructive, thoughtful way?
>
> I realize I'm not responding directly to your request, but if the position
> you're trying soften is supported by "the real world ...", how much can
> you hope to accomplish? This is a religious argument not a technical
> argument.
Well, my ultimate goal here is to relate to people better. And I think you
made a very good suggestion when you said to "[demonstrate] the solution of
some problem they find interesting". So, if "modeling the real world" is a
problem they find interesting, I'd like to be able to relate in those terms,
regardless of whether or not I think "the real world" is the best way of
reasoning about software.
Albert Lai
> I'm sure you've heard this argument before: "But
> the real world has mutable state!" (or "side effects!", etc.).
> But I am interested in your viewpoints in this
> newsgroup: how would you typically respond to such a statement in a
> constructive, thoughtful way?
My view is thoughtful but not constructive. (I commend Glynn
Clements's.) First and foremost, what does Real World, Mother Nature,
Cosmos have to do with programming? Programs are artificial, and we
structure them the way we see fit, not to please fans of organic
natural-ingredient food.
Second, about Real World itself. My "state" includes the clock. On
August 3, 2004 at time 23:50 EST, I was wearing glasses. Can you
mutate that state? Can anyone change the world so that on August 3,
2004 at time 23:50 EST I didn't wear glasses? Perhaps you protest
that I am talking about the past and you have a grip on the future.
Alright, I don't know whether I will be wearing glasses or not on
August 3, 2005 at 23:50 EST, but I know it will be at most one of
them. Can anyone change some state so that I will wear glasses, and
then change it again so that I will not wear glasses, the same way you
think you can toggle a boolean variable back and forth? You have no
more control than a single-assignment statement.
Like I said, we structure our programs the way we see fit. Should it
prove convenient in certain tasks to forget the clock, we can pretend
to have mutable states --- a simplifying mind trick. But this is a
design decision, not a given. Furthermore, like Glynn Clement
explains, even when we do so, there are more than one way to express
states and changes.
Marshall Spight
>
> I'm not looking for better ammunition for pointless arguments, or supporting
> evidence that I am right and they are wrong. I realize that there are many
> ways to attack software problems, and that just because I see a lot of value
> in functional methods doesn't mean others will agree with me, no matter how
> much I try to convince them. But I am interested in your viewpoints in this
> newsgroup: how would you typically respond to such a statement in a
> constructive, thoughtful way?
"That is an illusion. Because you have spent so much time programming
in an imperative language, you have begun to view the world in part
through the lens of imperative programming. But this is not what the
world really is, this is an *analogy*. If you had spent as much time
doing functional programming, you would say that the world has
referential transparency. If you had spent as much time playing
baseball, you would say that the world is all about maximizing
runs and minimizing errors. All these are statements about our
minds, not statements about the world.
"Programming is about the universe of numbers, the universe
of mathematics; this is *not* the same thing as the physical
world. The physical world doesn't have state; it has atoms.
The physical world doesn't have loops, or variables, or sets,
or lists; these are citizens of the world of mathematics.
"If you think otherwise, please take me anywhere you like and
show me three."
(If they show you three oranges, for example, point out that
they have shown you oranges, and ask them to take the oranges
away but leave the three-ness behind.)
Marshall
(Note that I, myself, do not actually program in a functional language.)
Ketil Malde
> Every so often, I get into an argument with another programmer about side
> effects and mutable state. I'm sure you've heard this argument before: "But
> the real world has mutable state!"
I used to think so, too, but I am a different person now.
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
Hamilcar Barca
04:57:11 +0000), Dave Benjamin wrote:
> In article <20040803232500.577$U...@news.newsreader.com>, Hamilcar Barca
> wrote:
>> In article <slrnch0erf...@lackingtalent.com> (Wed, 04 Aug 2004
>> 01:11:14 +0000), Dave Benjamin wrote:
>>
>>> "But the real world has mutable state!" (or "side effects!", etc.).
>>
>> Ask the other programmer if he or she is able to use the real world as a
>> programming language.
>
> Wow. I wasn't expecting a response like that. =)
Your question reminded me of something I'd read in the distant past
(_Godel, Escher, and Bach_, perhaps). The model must be smaller than that
which is modeled.
> Maybe we should ask Noam Chomsky whether mutable state is useful in
> controlling the public mind.
No, I live with a Linguist, and I'm forbidden to speak his name and
probably to even think it.
> But I think it's important to know when you're introducing state
> dependencies,
And, so it is.
> especially when the mainstream languages do little to
> create such an awareness.
Although it is not original, I claim this is the real benefit of OO
programming: reduction in (state) dependencies. Most of the rest of the
claims seem to be marketing.
> But there is a point to what they are saying, too - the world does
> have mutation, and it's in fact a pretty normal and typical thing.
This is again a philosophical argument. Actually, the mutation apparent
in world is imaginary, a shared illusion. Each instant in time is frozen
and is mapped by the function of universal existence to a new state. Or
words to that effect.
> Well, my ultimate goal here is to relate to people better.
Then it's best not to listen to me. I get more and more cynical as each
day goes by and I tend to simply dismiss those with religious views -- if
I don't attack them.
Tim Haynes
[snip]
> "Programming is about the universe of numbers, the universe
> of mathematics; this is *not* the same thing as the physical
> world. The physical world doesn't have state; it has atoms.
I'm not sure about this last sentence. Could you expound for me how the
programmatic idea of `state' (something you set up and write code to
manipulate) doesn't appear (anywhere) in nature?
(I'm thinking of the "state" of a given piece of iron being magnetised or
not.)
~Tim
--
Now we walk in empty glens |pig...@stirfried.vegetable.org.uk
Rushes blowing in the wind |http://pig.sty.nu/
Ralph Becket
using plain mathematics to describe the relationship between input and
output. There has never been a more successful language for accurately
describing aspects of the real world than mathematics. It is very
difficult to say with confidence, at any useful abstract level, what
relationship a non-trivial imperative program describes.
(2) Declarative programming doesn't forbid stateful programming, it just
requires that you make the state explicit. This makes debugging and code
reuse much, much easier.
(3) Much higher level optimisations are regularly implemented for side-
effect-free programming languages than are feasible or even possible with
imperative languages.
(4) The really smart people eventually gravitate towards declarative
programming - one should therefore seek to emulate them :-)
-- Ralph
Marshall Spight
> "Marshall Spight" <msp...@dnai.com> writes:
>
> [snip]
> > "Programming is about the universe of numbers, the universe
> > of mathematics; this is *not* the same thing as the physical
> > world. The physical world doesn't have state; it has atoms.
>
> I'm not sure about this last sentence. Could you expound for me how the
> programmatic idea of `state' (something you set up and write code to
> manipulate) doesn't appear (anywhere) in nature?
>
> (I'm thinking of the "state" of a given piece of iron being magnetised or
> not.)
Is whether a given piece of iron magnetized or not something someone
set up and wrote code to manipulate?
Note that we could equally well say the piece of iron is subject to a
magnetization function that maps the old, non-magnetized piece at
time T into a new magnetized piece at time T'. That's just as good an
analogy.
Have you played with the idea of trying to locate a 3 in the real world?
How about the successor function? A circle? A free variable? Note
that none of these things exist in the Real World(tm); they are
mathematical constructs, as is all software.
Marshall
Daniel Yokomiso
"Dave Benjamin" <ra...@lackingtalent.com> escreveu na mensagem
news:slrnch0erf...@lackingtalent.com...
> Hi folks,
>
> Every so often, I get into an argument with another programmer about side
> effects and mutable state. I'm sure you've heard this argument before:
"But
> the real world has mutable state!" (or "side effects!", etc.). My first
> instinct is to just laugh, thinking to myself, "obviously this person has
> never tried functional programming or they wouldn't be saying such a
thing."
> But if I were to verbalize this opinion, I'd just come out sounding like a
> snob, so I usually just say something pragmatic, like "yeah, but the idea
is
> to reduce state dependency as much as possible", or "if you can write
> something without side effects, you probably should."
>
> I'm not looking for better ammunition for pointless arguments, or
supporting
> evidence that I am right and they are wrong. I realize that there are many
> ways to attack software problems, and that just because I see a lot of
value
> in functional methods doesn't mean others will agree with me, no matter
how
> much I try to convince them. But I am interested in your viewpoints in
this
> newsgroup: how would you typically respond to such a statement in a
> constructive, thoughtful way?
IME it's important to make them aware that they know the distinction between
pure functions and functions with side effects: that is why is (usually)
safe to reorder this statements
String name = person.getName();
int age = person.getAge();
But not these:
int length = list.size();
list.add(obj);
Once they agree with this it's interesting to point how much effort goes
into copy constructors, shallow/deep cloning, etc. issues to ensure that we
can make two values truly disjoint and how this issue is convoluted. Then
you can go on the mutable vs. immutable objects debate and how equality
isn't identity for two immutable objects even if conceptually they're the
same. An additional place to go is the const-correctness issue and how
tricky it can get. Once you make them see that in a language with implicit
side-effects and implicit immutability everywhere it's very hard to
guarantee immutable values and pure functions (because everything can
implicitly depend on the state of the world) you will be ready to show that
in referentially transparent languages the problem is reversed because we
need to explicitly annotate which functions can change the world.
The key point is showing that it's impossible to guarantee, in a language
that allow implicit side-effects, that a function is pure, while it's
possible (even if sometimes it's more verbose) to create functions with
side-effects in a pure language.
IME most programmers aren't aware of the complexity inherent of implicit
side-effects because they think it is inherent to programming.
> Thanks,
> Dave
>
> --
> .:[ dave benjamin: ramen/[sp00] -:- spoomusic.com -:- ramenfest.com ]:.
>
> "When the country is confused and in chaos, information scientists
appear."
> Librarian's Lao Tzu:
http://www.geocities.com/onelibrarian.geo/lao_tzu.html
Daniel Yokomizo.
"It's time to unmask the computing community as a Secret Society for the
Creation and Preservation of Artificial Complexity."
- Edsger W. Dijkstra
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.733 / Virus Database: 487 - Release Date: 2/8/2004
Tim Haynes
> "Tim Haynes" <usenet-...@stirfried.vegetable.org.uk> wrote in message news:86n01b9...@potato.vegetable.org.uk...
>> "Marshall Spight" <msp...@dnai.com> writes:
>>
>> [snip]
>> > "Programming is about the universe of numbers, the universe
>> > of mathematics; this is *not* the same thing as the physical
>> > world. The physical world doesn't have state; it has atoms.
>>
>> I'm not sure about this last sentence. Could you expound for me how the
>> programmatic idea of `state' (something you set up and write code to
>> manipulate) doesn't appear (anywhere) in nature?
>>
>> (I'm thinking of the "state" of a given piece of iron being magnetised or
>> not.)
>
> Is whether a given piece of iron magnetized or not something someone
> set up and wrote code to manipulate?
I wouldn't be surprised if someone had done that before now (thinking
CT-scanners, whatever sub-atomic physicists get up to). It certainly
shouldn't be too hard to write something that flipped bits on an i/o port
causing heating / whacking with a hammer / application of external magnetic
field, etc. More a work of hardware.
> Note that we could equally well say the piece of iron is subject to a
> magnetization function that maps the old, non-magnetized piece at time T
> into a new magnetized piece at time T'. That's just as good an analogy.
Hmmm. I suppose this is true, assuming one doesn't bring the whole "just
create a new one and gc the old" approach across as well, which would not
be the same.
> Have you played with the idea of trying to locate a 3 in the real world?
> How about the successor function? A circle? A free variable? Note that
> none of these things exist in the Real World(tm); they are mathematical
> constructs, as is all software.
Sure these things are, but that's not what I was questioning. I want to
know what meanings of "state" and "atoms" you had in mind in saying `the
world has no state'.
If "state" is the same, ie "the state of being (de)magnetised" in this
case, and I can choose to see the act of whacking a magnet with a hammer as
an imperative command to the computer to perform some action to change the
iron's state now, *or* I can choose to see it through your analogy above,
does your analogy necessarily not have state as well?
~Tim
--
With the spirits of the mighty |pig...@stirfried.vegetable.org.uk
A shadow rushes through the grasslands |http://pig.sty.nu/
To the dying sun |
Vincenzo aka Nick Name
> how would you typically respond to such a statement in a
> constructive, thoughtful way?
I answer "yes, you are right". Real world has mutable state, in fact even
haskell has to interact with it, hasn't it? It would be a pity to say that
updateable arrays aren't useful, in fact they are. The most important
things I see in functional programming (apart from strong typing, which is
not related to functional programming even if it's what makes me prefer
ocaml or haskell over other languages) is higher orderness and currying.
And if some could say that C# delegates resemble functional programming,
well, I /really/ need currying and always feel somewhat blocked when I
don't have it. I guess that these are all advantages of a structural type
system (you can actually implement in C# a curried version of your
functions using an ad-hoc class which handles the first argument, and this
contrived way is due to being nominative :)).
V.
Thant Tessman
> Every so often, I get into an argument with another programmer about side
> effects and mutable state. I'm sure you've heard this argument before: "But
> the real world has mutable state!" (or "side effects!", etc.). [...]
Counterclaim: The real world is a referentially-transparent function of
time.
-thant
Joe Knapka
> Dave Benjamin <ra...@lackingtalent.com> writes:
>
> > Every so often, I get into an argument with another programmer about side
> > effects and mutable state. I'm sure you've heard this argument before: "But
> > the real world has mutable state!"
>
> I used to think so, too, but I am a different person now.
...he declared.
--
"We sat and watched as this whole <-- (Died Pretty -- "Springenfall")
blue sky turned to black..."
... Re-defeat Bush in '04.
--
pub 1024D/BA496D2B 2004-05-14 Joseph A Knapka
Key fingerprint = 3BA2 FE72 3CBA D4C2 21E4 C9B4 3230 94D7 BA49 6D2B
If you really want to get my attention, send mail to
jknapka .at. kneuro .dot. net.
Dave Benjamin
> Ketil Malde <ke...@ii.uib.no> writes:
>
>> Dave Benjamin <ra...@lackingtalent.com> writes:
>>
>> > Every so often, I get into an argument with another programmer about side
>> > effects and mutable state. I'm sure you've heard this argument before: "But
>> > the real world has mutable state!"
>>
>> I used to think so, too, but I am a different person now.
>
> ...he declared.
Haha... I finally got the joke. Thanks. =)
-dave
Hamilcar Barca
-0600), Thant Tessman wrote:
Counter-counterclaim: La vida es sueno. [the 'n' needs a tilde]
Paul Johnson
> I'm sure you've heard this argument before: "But
> the real world has mutable state!" (or "side effects!", etc.).
I once had this argument when I was on the other side (I'm better now),
and the response was: "A program is a referentially transparent function
that transforms inputs into outputs. What does state have to do with it?
Paul.
--
-------------------------------+-------------------------------------------
Paul Johnson | You are trapped in a twisty maze of little
Home: pa...@cogito.org.uk | standards, all different.
Work: paul.j...@marconi.com |
R. Troedler
> run "nm" on the object files in order to catch programmers using
> static variables even though they were specifically told not to.
what's nm, btw.?
regards, troe
Marshall Spight
> "Marshall Spight" <msp...@dnai.com> writes:
>
> > Is whether a given piece of iron magnetized or not something someone
> > set up and wrote code to manipulate?
>
> I wouldn't be surprised if someone had done that before now (thinking
> CT-scanners, whatever sub-atomic physicists get up to).
No! You're confusing the levels.
> It certainly
> shouldn't be too hard to write something that flipped bits on an i/o port
> causing heating / whacking with a hammer / application of external magnetic
> field, etc. More a work of hardware.
Sure, you built some hardware using objects in the physical world and
ran some imperative software on it. If that is a proof that the real world
is imperative, then what does it say about the real world if someone builds
some hardware and runs some purely functional software on it?
> > Have you played with the idea of trying to locate a 3 in the real world?
> > How about the successor function? A circle? A free variable? Note that
> > none of these things exist in the Real World(tm); they are mathematical
> > constructs, as is all software.
>
> Sure these things are, but that's not what I was questioning. I want to
> know what meanings of "state" and "atoms" you had in mind in saying `the
> world has no state'.
>
> If "state" is the same, ie "the state of being (de)magnetised" in this
> case, and I can choose to see the act of whacking a magnet with a hammer as
> an imperative command to the computer to perform some action to change the
> iron's state now, *or* I can choose to see it through your analogy above,
> does your analogy necessarily not have state as well?
You can choose to see anything as being anything else. That's a statement
about you *mind* not a statement about the thing. You're confusing water
with the word "wet." You're confusing the row in the employees table
in the HR database with the person it represents. You're confusing the
finger pointing at the moon with the moon.
Marshall
Thant Tessman
It's a Unix/Linux utility for listing the symbols in object files,
libraries, and executables. Very handy sometimes. If you're on a
Unix/Linux system, type "man nm" into a terminal for more information.
I don't know if there's a Winblows equivalent, but would be grateful to
be informed if there is.
-thant
George Neuner
wrote:
Nothing included with the OS, but "dumpbin" is a command line tool for
object file information (including disassembly). It comes bundled
with VC++, I don't know whether you can get it separately.
Microsoft recently released the VS.NET 2003 command line developer
tools (no IDE) for free downloading. SInce VC++ is included, dumpbin
might also be in there.
http://msdn.microsoft.com/visualc/vctoolkit2003/
George
--
for email reply remove "/" from address
Panu Kalliokoski
> Every so often, I get into an argument with another programmer about side
> effects and mutable state. I'm sure you've heard this argument before: "But
> the real world has mutable state!" (or "side effects!", etc.). My first
[...]
> newsgroup: how would you typically respond to such a statement in a
> constructive, thoughtful way?
Well, this one is quite snobish, but: "A world with mutable state is
semantically equivalent and thus indistinguishable from a
sequence/list of states."
Panu
--
personal contact: ate...@iki.fi, +35841 5323835
work contact: pkal...@ling.helsinki.fi, +35850 3678003
kotisivu (henkkoht): http://www.iki.fi/atehwa/
homepage (technical): http://sange.fi/~atehwa/
Dave Benjamin
> Dave Benjamin <ra...@lackingtalent.com> writes:
>
>> Every so often, I get into an argument with another programmer about side
>> effects and mutable state. I'm sure you've heard this argument before: "But
>> the real world has mutable state!" (or "side effects!", etc.). My first
> [...]
>> newsgroup: how would you typically respond to such a statement in a
>> constructive, thoughtful way?
>
> Well, this one is quite snobish, but: "A world with mutable state is
> semantically equivalent and thus indistinguishable from a
> sequence/list of states."
It sounds like the strongest recurring theme in these responses has been
about the ways in which we perceive time dependency; imagine that there is a
function "f" that returns the state of the world. Is f:
fun f () -> <the state of the world>
or is it:
fun f t -> <the state of the world>
The latter allows you to describe the state of the world as some expression
involving (f (t - 1)); in other words the state of the world *now* is a
function of the state of the world a moment ago. This seems to fit the way I
perceive history and the chain of consequences that brought us to where we
are now. As long as we don't have to entertain the notion of backwards time
travel, this model seems to fit.
The former, "f" being a function of nothing at all, with different results
depending on when you call it, is mysterious and difficult to reason about.
How would you write it? It would have to depend on something, wouldn't it?
Yet it seems to be closer to *my* conceptual model of the universe; it
doesn't depend on anything, it just... is. Likewise, on a lower level, it's
difficult to think of ourselves as different people with each moment that
passes (as Ketil Malde humorously illustrated). The notion of identity seems
to be at odds with the functional view of the universe.
Does identity really exist? Is it worthwhile to model the notion in
software? Is it mathematically definable? Or is it fuzzy and nebulous, as
the following quote illustrates:
"Once, tripping in the metropolitan capital of Illinois, I came up with this
theory that everything outside my body was Chicago and all within was not. A
nice simple way to look at the world. I would point at, like, a chair and
say 'Is Chicago,' and then at my chest, and say, 'Is not Chicago.' This
entertained me for a good twelve hours or so." - Mike Doughty, on the Soul
Coughing song, "Is Chicago, Is Not Chicago".
Joe Knapka
[scissors of brevity]
> Does identity really exist? Is it worthwhile to model the notion in
> software? Is it mathematically definable? Or is it fuzzy and nebulous, as
> the following quote illustrates:
>
> "Once, tripping in the metropolitan capital of Illinois, I came up with this
> theory that everything outside my body was Chicago and all within was not. A
> nice simple way to look at the world. I would point at, like, a chair and
> say 'Is Chicago,' and then at my chest, and say, 'Is not Chicago.' This
> entertained me for a good twelve hours or so." - Mike Doughty, on the Soul
> Coughing song, "Is Chicago, Is Not Chicago".
When someone builds a machine that can really enjoy tripping, AI will
truly be solved. I guess we could call that the Turing Acid Test.
Glynn Clements
Dave Benjamin <ra...@lackingtalent.com> writes:
> >> Every so often, I get into an argument with another programmer about side
> >> effects and mutable state. I'm sure you've heard this argument before: "But
> >> the real world has mutable state!" (or "side effects!", etc.). My first
> > [...]
> >> newsgroup: how would you typically respond to such a statement in a
> >> constructive, thoughtful way?
> >
> > Well, this one is quite snobish, but: "A world with mutable state is
> > semantically equivalent and thus indistinguishable from a
> > sequence/list of states."
>
> It sounds like the strongest recurring theme in these responses has been
> about the ways in which we perceive time dependency; imagine that there is a
> function "f" that returns the state of the world. Is f:
>
> fun f () -> <the state of the world>
>
> or is it:
>
> fun f t -> <the state of the world>
The former is only a *function* if it always returns the same result.
The term "function" was in widespread use long before programmers
started (ab)using it to mean a procedure which returns a result in
addition to any side effects it may have.
Off the top of my head, the conventional definition is something like:
A function f is a set of ordered pairs such that, for any two pairs
(a,b) and (c,d) which are members of f, if a is equal to c then b is
equal to d.
The notation f(x) is a shorthand for "y such that (x,y) is a member of f".
The constraint listed above ensures that y will be unique.
For comparison, a relation is simply a set of ordered pairs, with no
such constraint. E.g. "square root" is a relation but not a function
(any positive real has two square roots; (4,2) and (4,-2) are both
members of the square root relation), while "positive square root" is
both a relation and a function.
--
Glynn Clements <glynn.c...@virgin.net>
Thant Tessman
> [...] Likewise, on a lower level, it's
> difficult to think of ourselves as different people with each moment that
> passes (as Ketil Malde humorously illustrated). The notion of identity seems
> to be at odds with the functional view of the universe. [...]
Just because the water that makes up an ocean wave is constantly
changing doesn't mean it isn't useful to think about waves.
-thant