- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
functional/immutable programming question
in pure functional programming, there are no side effects. this means, the only "effect" a method has is its returned value, right? it doesn't hold a mutable state.
if so, how do i implement something that HAS to hold a state? what if let's say 10 clients try to add elements to the same list instance? there has to be a managing class that holds the list, right?
Re: Re: functional/immutable programming question
Hello Kevin,
I recall a tutorial on category theory for software engineers that was
given by steve easterbrook at U of Toronto.
http://www.cs.toronto.edu/~sme/presentations/cat101.pdf
Not sure however or accessible this is.
He has also done some work further upstream (specification evolution) in
conjunction with category theory.
To what extent is category theory in your mind necessary to become a
professional Scala programmer? I.e. to create software that is
performant but also understandable, maintainable, changeable and
evolvable?
thanks,
Daniel
On Tue, 2010-11-16 at 09:46 +0000, Kevin Wright wrote:
> It's hard to get deep into FP *without* terms like monad, monoid,
> endofunctor, catamorphism, etc. being involved.
>
>
> Then again, it's even harder to find any reference to these terms that
> doesn't use Haskell as the language-de-jour for explaining them. I've
> long searched for a good *approachable* programmer-oriented
> introduction to category theory that also doesn't rapidly fall back on
> either Haskell (or on higher-mathematics, but those generally fail the
> "approachability" test). So far, this search has been in vain.
>
>
> If you're serious about this material, then the only advice in town is
> still, essentially, "first learn Haskell..." - and that's just plain
> frustrating. Not that I would ever discourage anyone from learning
> the language, it's one that every programmer really ought to know, but
> that's sometimes just not a realistic option when faced with
> commercial time pressure.
>
>
>
> On 16 November 2010 09:30, Det2 wrote:
>
> And here, guys, I get my personal Groundhog Day:
>
> After all talkings about the usability of Scala and its
> applicability in
> all-days developer business and typical programmer's projects,
> we once again
> came back to the original Scala-User thread pattern.
>
> An "ordinary" OO programmer (sorry HamsterOfDeath) heard all
> this rumours
> about this FP stuff and asks in the Scala-User list the
> unavoidable
> question:
>
> >in pure functional programming, there are no side effects.
> this means, the
> only "effect" a method has is
> >its returned value, right? it doesn't hold a mutable state.
> >
> >if so, how do i implement something that HAS to hold a state?
> what if let's
> say 10 clients try to add
> >elements to the same list instance? there has to be a
> managing class that
> holds the list, right?
>
>
> Some time later someone comes up with a "declaration" only
> involving type
> signatures, without any usage or implementation examples.
>
> And not after long the thread mutates to a discussion with
> phrases like
> this:
>
> > [...] that monads are just monoids in the category of
> endofunctors [...]
>
> enventually followed by someone coming up with an academic
> paper involving
> TheOtherFPLanguage: Haskell.
>
> Is this a variant of Godwin's law?
>
> Sorry boys, but we questioners try to learn Scala, not
> Haskell, and get
> these statements about this immutability and the blessings of
> FP unveiled,
> to gain something for our daily job.
>
> So the basic question is: How can we (no: you, as I'm part of
> the
> questioner side) transport the answers to these questions in
> an
> understandable way to the mass, for the benefit of the
> (future?) ordinary
> JVM business developer and for Scala as a language?
> One typical answer to this question would be "show'em a
> sample".
>
> I feel the need for an "Introduction into Functional
> Programming - FP
> concepts explained in Scala" book, that is close enough to
> practical
> problems of professional developers.
> (NB: The german book "Grundkurs Funktionale Programmierung mit
> Scala" is a
> nice start, but contains only a third of the necessary space
> to dive deep
> enough into this matter, so it is really a very basic course).
>
>
> @HamsterOfDeath: My current state is: I put the question
> about pure FP
> aside and focussed on what Scala is: A hybrid FP / OO
> language. To be
> productive with Scala, the best is to use it that way and
> apply the concepts
> that best fit to solve a particular problem, and that involves
> side effects
> in some dedicated parts of your program.
>
> KR
> Det
> --
> View this message in context:
> http://scala-programming-language.1934581.n4.nabble.com/functional-immut...
>
> Sent from the Scala - User mailing list archive at Nabble.com.
>
>
>
>
Re: Re: functional/immutable programming question
you do not have to be a die-hard fp programmer to learn about the
benefits of side effect free programming
there is nothing wrong with carefully writing libraries that, internally,
have side effects, but, externally, offer a side effect free contract
(for example: the collections library)
in Martin's "Scala By Example" paper he shows a type inferencer algorithm
that makes use of a var that is used for generating a new
type variable name
object typeInfer {
private var n: Int = 0
def newTyvar(): Type = { n += 1; Tyvar("a" + n) }
imo, this is a perfect example of a pragmatic choice
(he could have used the state monad instead)
(big) benefit: simplicity
(small) drawback: the side effect is not known to the type system,
but, hey, the variable n is private anyway, and the only thing one
can do is invoke newTyvar()
Luc
--
__~O
-\ <,
(*)/ (*)
reality goes far beyond imagination
Re: Re: functional/immutable programming question
Luc Duponcheel wrote:
> you do not have to be a die-hard fp programmer to learn about the
> benefits of side effect free programming
Absolutely. That even works in Java.
> there is nothing wrong with carefully writing libraries that,
> internally,
> have side effects, but, externally, offer a side effect free
> contract
> (for example: the collections library)
That depends a lot on the side-effect, I'd say. If you can completely
hide it, then it may work out. But doing so may be harder than it looks.
(snip)
> object typeInfer {
> private var n: Int = 0
> def newTyvar(): Type = { n += 1; Tyvar("a" + n) }
>
> imo, this is a perfect example of a pragmatic choice
> (he could have used the state monad instead)
>
> (big) benefit: simplicity
> (small) drawback: the side effect is not known to the type system,
> but, hey, the variable n is private anyway, and the only thing one
> can do is invoke newTyvar()
This example isn't thread-safe, is it? So the side effect escapes even
though the visibility modifier tries to hide it: the client needs to
synchronize externally or restrict itself to one thread. If I recall
correctly Stream cons (or was it List cons?) in the library had this
kind of hidden thread vulnerability.
Also, the method is not referentially transparent: it returns two
different values for two identical invocations. In other words, there is
an observable side effect.
All I wanted to say is: it may be much trickier than it seems at first
glance.
Thanks for sharing your opinion.
Kind regards
Andreas
Re: Re: functional/immutable programming question
> though the visibility modifier tries to hide it: the client needs to
> synchronize externally or restrict itself to one thread. If I recall
> correctly Stream cons (or was it List cons?) in the library had this
> kind of hidden thread vulnerability.
indeed, but, I guess that, in this case, writing a correct algorithm
for single threaded usage was already challenging enough :-)
> Also, the method is not referentially transparent: it returns two
> different values for two identical invocations. In other words, there is
> an observable side effect.
correct, but even that method could be encapsulated: after all
the only thing that the type inferencer has to expose is it's
infer method (which is referentially transparent)
> All I wanted to say is: it may be much trickier than it seems at first
> glance.
I agree
> Thanks for sharing your opinion
thx
--
__~O
-\ <,
(*)/ (*)
reality goes far beyond imagination
Re: Re: functional/immutable programming question
So my attempt at explaining how monads help encapsulate side-effects failed miserably... The part with "monoids in the category of endofunctors" was a joke as was fondling elephants. You should read James Iry's blog, might shed more kith into monads and why they're useful.
Cheers,
Razvan
On 2010-11-16, at 6:18 AM, Luc Duponcheel wrote:
> > This example isn't thread-safe, is it? So the side effect escapes even
> > though the visibility modifier tries to hide it: the client needs to
> > synchronize externally or restrict itself to one thread. If I recall
> > correctly Stream cons (or was it List cons?) in the library had this
> > kind of hidden thread vulnerability.
>
> indeed, but, I guess that, in this case, writing a correct algorithm
> for single threaded usage was already challenging enough :-)
>
> > Also, the method is not referentially transparent: it returns two
> > different values for two identical invocations. In other words, there is
> > an observable side effect.
>
> correct, but even that method could be encapsulated: after all
> the only thing that the type inferencer has to expose is it's
> infer method (which is referentially transparent)
>
> > All I wanted to say is: it may be much trickier than it seems at first
> > glance.
>
> I agree
>
> > Thanks for sharing your opinion
>
> thx
>
>
Re: Re: functional/immutable programming question
On 16/11/10 23:37, Razvan Cojocaru wrote:
> So my attempt at explaining how monads help encapsulate side-effects failed miserably... The part with "monoids in the category of endofunctors" was a joke as was fondling elephants.
>
Perhaps, but I have seen a beginner have monads successfully explained
to them as monoids in the category of endofunctors while on IRC (which
is profound in itself). There were no elephants.
RE: Re: functional/immutable programming question
Tony - Now you've done it! You pissed me off!
...and, feeling bad that a beginner on IRC picks it up faster than I, even
with Outlook, I've just spent a few hours bouncing between Wikipedia, some
PDF articles, pen and paper and I think I'm starting to get it, even
presented that way.
Thank you. I think I understood some other things stashed for a while
somewhere in my brain...
-----Original Message-----
From: Tony Morris [mailto:tonymorris [at] gmail [dot] com]
Sent: November-16-10 5:24 PM
To: scala-user [at] listes [dot] epfl [dot] ch
Subject: Re: [scala-user] Re: functional/immutable programming question
On 16/11/10 23:37, Razvan Cojocaru wrote:
> So my attempt at explaining how monads help encapsulate side-effects
failed miserably... The part with "monoids in the category of endofunctors"
was a joke as was fondling elephants.
>
Perhaps, but I have seen a beginner have monads successfully explained to
them as monoids in the category of endofunctors while on IRC (which is
profound in itself). There were no elephants.
--
Tony Morris
http://tmorris.net/
Re: Re: functional/immutable programming question
Without yet really knowing Scala much (i just started to learn about the
language), perhaps it's worth defining three classes of programs a) pure
functional that are guaranteed to have no side-effects and b) mixed
programs, where side-effects are possible. And b) could be further
classified into b.1) programs with well localized side effects and b.2)
hybrid programs.
Perhaps this would imply defining different subsets of Scala and
libraries use.
Any program of class a) would be guaranteed to run in a parallel
processing environment, while for b.1) a guarantee is contingent on
programmer properly dealing with the localized side effects. a program
of category b.2) has no guarantees and should be run in a non
parallelized environment.
does this make sense?
thanks,
Daniel
On Tue, 2010-11-16 at 12:18 +0100, Luc Duponcheel wrote:
> > This example isn't thread-safe, is it? So the side effect escapes
> even
> > though the visibility modifier tries to hide it: the client needs to
> > synchronize externally or restrict itself to one thread. If I recall
> > correctly Stream cons (or was it List cons?) in the library had this
> > kind of hidden thread vulnerability.
>
> indeed, but, I guess that, in this case, writing a correct algorithm
> for single threaded usage was already challenging enough :-)
>
> > Also, the method is not referentially transparent: it returns two
> > different values for two identical invocations. In other words,
> there is
> > an observable side effect.
>
> correct, but even that method could be encapsulated: after all
> the only thing that the type inferencer has to expose is it's
> infer method (which is referentially transparent)
>
> > All I wanted to say is: it may be much trickier than it seems at
> first
> > glance.
>
> I agree
>
> > Thanks for sharing your opinion
>
> thx
>
>
Re: Re: functional/immutable programming question
side effects aren't only a problem in multithreading environments. they (can) make code more complex and less easy to read.
-------- Original-Nachricht --------
> Datum: Tue, 16 Nov 2010 13:32:49 +0200
> Von: Daniel Gross
> An: Luc Duponcheel
> CC: Andreas Flierl , scala-user [at] listes [dot] epfl [dot] ch
> Betreff: Re: [scala-user] Re: functional/immutable programming question
> Without yet really knowing Scala much (i just started to learn about the
> language), perhaps it's worth defining three classes of programs a) pure
> functional that are guaranteed to have no side-effects and b) mixed
> programs, where side-effects are possible. And b) could be further
> classified into b.1) programs with well localized side effects and b.2)
> hybrid programs.
>
> Perhaps this would imply defining different subsets of Scala and
> libraries use.
>
> Any program of class a) would be guaranteed to run in a parallel
> processing environment, while for b.1) a guarantee is contingent on
> programmer properly dealing with the localized side effects. a program
> of category b.2) has no guarantees and should be run in a non
> parallelized environment.
>
> does this make sense?
>
> thanks,
>
> Daniel
>
> On Tue, 2010-11-16 at 12:18 +0100, Luc Duponcheel wrote:
> > > This example isn't thread-safe, is it? So the side effect escapes
> > even
> > > though the visibility modifier tries to hide it: the client needs to
> > > synchronize externally or restrict itself to one thread. If I recall
> > > correctly Stream cons (or was it List cons?) in the library had this
> > > kind of hidden thread vulnerability.
> >
> > indeed, but, I guess that, in this case, writing a correct algorithm
> > for single threaded usage was already challenging enough :-)
> >
> > > Also, the method is not referentially transparent: it returns two
> > > different values for two identical invocations. In other words,
> > there is
> > > an observable side effect.
> >
> > correct, but even that method could be encapsulated: after all
> > the only thing that the type inferencer has to expose is it's
> > infer method (which is referentially transparent)
> >
> > > All I wanted to say is: it may be much trickier than it seems at
> > first
> > > glance.
> >
> > I agree
> >
> > > Thanks for sharing your opinion
> >
> > thx
> >
> >
> > --
> > __~O
> > -\ <,
> > (*)/ (*)
> >
> > reality goes far beyond imagination
> >
>
>
Re: Re: functional/immutable programming question
Daniel Gross wrote:
> Without yet really knowing Scala much (i just started to learn about the
> language), perhaps it's worth defining three classes of programs a) pure
> functional that are guaranteed to have no side-effects and b) mixed
> programs, where side-effects are possible. And b) could be further
> classified into b.1) programs with well localized side effects and b.2)
> hybrid programs.
As far as I am concerned, all Scala programs fall under b as there is
(currently) no way
to guarantee purity in Scala (as far as I am aware).
The key point here (for me) is in the "guarantee". The absence of
unintended side effects (sounds like a bug to me) cannot be shown by
testing. Testing can only show the presence of bugs. So we need
something better. "Because the programmer says it is." does not qualify
either. So it comes down to the compiler guaranteeing purity.
> Perhaps this would imply defining different subsets of Scala and
> libraries use.
>
> Any program of class a) would be guaranteed to run in a parallel
> processing environment, while for b.1) a guarantee is contingent on
> programmer properly dealing with the localized side effects. a program
> of category b.2) has no guarantees and should be run in a non
> parallelized environment.
Side effects are not just about threads. Imagine a library that
internally logs stuff to the disk. Your application uses this library
while it writes its own data to the disk, knowing nothing about that
side effect. The log file fills the disk -> ouch
Of course this example may be rather constructed but you get the idea.
:)
Kind regards
Andreas
Re: Re: functional/immutable programming question
Hello Andreas,
I guess what you are writing is a bit surprising to me. I thought that
one of the key selling points for a functional language like Scala, is
the easy with which program execution can be distributed across
cores/processors.
It should be possible to clearly establish that a program, or at least,
a well designated portion of a program, can be parallelized without any
problems.
thanks,
Daniel
On Tue, 2010-11-16 at 12:47 +0100, Andreas Flierl wrote:
> Daniel Gross wrote:
> > Without yet really knowing Scala much (i just started to learn about the
> > language), perhaps it's worth defining three classes of programs a) pure
> > functional that are guaranteed to have no side-effects and b) mixed
> > programs, where side-effects are possible. And b) could be further
> > classified into b.1) programs with well localized side effects and b.2)
> > hybrid programs.
>
> As far as I am concerned, all Scala programs fall under b as there is
> (currently) no way
> to guarantee purity in Scala (as far as I am aware).
>
> The key point here (for me) is in the "guarantee". The absence of
> unintended side effects (sounds like a bug to me) cannot be shown by
> testing. Testing can only show the presence of bugs. So we need
> something better. "Because the programmer says it is." does not qualify
> either. So it comes down to the compiler guaranteeing purity.
>
> > Perhaps this would imply defining different subsets of Scala and
> > libraries use.
> >
> > Any program of class a) would be guaranteed to run in a parallel
> > processing environment, while for b.1) a guarantee is contingent on
> > programmer properly dealing with the localized side effects. a program
> > of category b.2) has no guarantees and should be run in a non
> > parallelized environment.
>
> Side effects are not just about threads. Imagine a library that
> internally logs stuff to the disk. Your application uses this library
> while it writes its own data to the disk, knowing nothing about that
> side effect. The log file fills the disk -> ouch
> Of course this example may be rather constructed but you get the idea.
> :)
>
> Kind regards
> Andreas
Re: Re: functional/immutable programming question
On 16/11/10 12:25, Daniel Gross wrote:
> I thought that one of the key selling points for a functional language like
> Scala, is the easy with which program execution can be distributed across
> cores/processors.
I'd like to mention an interesting point made by Clojure's author, Rich Hickey:
to paraphrase, (conventional) object orientation *encourages* mutable state,
which causes difficulties when used for parallel algorithms, because you have
lock and serialise access to all the shared state.
Does Scala have an answer to this point? Presumably it just aims to allow both
styles, without guaranteeing or mandating anything?
From: http://clojure.org/state
> OO is, among other things, an attempt to provide tools for modeling identity
> and state in programs (as well as associating behavior with state, and
> hierarchical classification, both ignored here). OO typically unifies
> identity and state, i.e. an object (identity) is a pointer to the memory that
> contains the value of its state. There is no way to obtain the state
> independent of the identity other than copying it. There is no way to observe
> a stable state (even to copy it) without blocking others from changing it.
> There is no way to associate the identity's state with a different value
> other than in-place memory mutation. In other words, typical OO has
> imperative programming baked into it! OO doesn't have to be this way, but,
> usually, it is (Java/C++/Python/Ruby etc).
>
> People accustomed to OO conceive of their programs as mutating the values of
> objects. They understand the true notion of a value, say, 42, as something
> that would never change, but usually don't extend that notion of value to
> their object's state. That is a failure of their programming language. These
> languages use the same constructs for modeling values as they do for
> identities, objects, and default to mutability, causing all but the most
> disciplined programmers to create many more identities than they should,
> creating identities out of things that should be values etc.
N
Re: Re: functional/immutable programming question
Nick wrote:
> Does Scala have an answer to this point?
As a side note, Akka provides agents[1] and STM[2] inspired by Clojure
and its view on state for Java and Scala.
[1] http://doc.akkasource.org/agents-scala
[2] http://doc.akkasource.org/stm-scala
Re: Re: functional/immutable programming question
vals, case classes, the default collection types, etc.
On 16 November 2010 15:09, Nick <oinksocket [at] letterboxes [dot] org> wrote:
--
Kevin Wright
mail / gtalk / msn : kev [dot] lee [dot] wright [at] gmail [dot] com
pulse / skype: kev.lee.wright
twitter: @thecoda
Re: Re: functional/immutable programming question
Now that I am reading it again, I also noticed one more thing.
Daniel Gross wrote:
> I guess what you are writing is a bit surprising to me. I thought that
> one of the key selling points for a functional language like Scala, is
> the easy with which program execution can be distributed across
> cores/processors.
Please let me question the phrase "a functional language like Scala".
It raises three questions in my head:
1) Just what exactly IS functional? I have read diverging definitions.
2) How functional is Scala? They don't call it object-functional or
postfunctional for no reason, I'd guess.
3) How many other languages are "like Scala"? The functional languages
I know are so different that I personally would have a hard time
reasoning about all of them at once (how functional are they all? what's
their type system like? are they pure?). Then again, I am no functional
programming expert.
Kind regards
Andreas
Re: Re: functional/immutable programming question
Thanks,Razvan
On 2010-11-16, at 8:32 AM, Andreas Flierl <andreas [at] flierl [dot] eu> wrote:
Re: Re: functional/immutable programming question
Razvan Cojocaru :
> Gents, again wikipedia to the rescue
(snip)
Thanks. :)
Already knowing wikipedia's definition, I mentioned the issue because
I've read these blog entries, which some of you may find interesting:
[1] http://www.drmaciver.com/2009/05/a-problem-of-language/
[2] http://www.codecommit.com/blog/scala/is-scala-not-functional-enough
[3] http://james-iry.blogspot.com/2009/05/erlang-is-not-functional.html
[4]
http://james-iry.blogspot.com/2010/03/robert-fischer-finally-admits-that...
Best regards
Andreas
Re: Re: functional/immutable programming question
Sorry - not that I want to be called names like "language lawyer" :) but I
was trying to underline the choice of words: it's first about functions and
then "avoids state"... rather than "forbids state"...
So, the way I see it, no doubt "purity" allows some mathematical funk around
functions and figuring out correctness whatnot, but that's not what defines
"functional"...it just defines "purity"... which is obviously subject to
extremist thinking, factions and blog picketing bigots :)) I enjoyed that
part.
For me, "cross my heart and hope to die" combined with testing is good
enough to bless a library as "reasonably side effect free". Afterall, you
can hide readLn and printLn in a closet, library or monad, but they're still
there...
The real world has state and any program trying to model the real world will
have to stash some state somewhere... So, if you can pass functions around
and curry the suckers, then it's functional enough in my book. I even think
closures come extra...
Anyways, this is the view of the world coming from a very much imperative OO
background...and I think we again leave the specifics behind and go into
mythology here, thus have to stop.
cheers,
Razvan
-----Original Message-----
From: Andreas Flierl
Sent: Tuesday, November 16, 2010 9:03 AM
To: Razvan Cojocaru
Cc: scala-user [at] listes [dot] epfl [dot] ch
Subject: Re: [scala-user] Re: functional/immutable programming question
Razvan Cojocaru :
> Gents, again wikipedia to the rescue
(snip)
Thanks. :)
Already knowing wikipedia's definition, I mentioned the issue because
I've read these blog entries, which some of you may find interesting:
[1] http://www.drmaciver.com/2009/05/a-problem-of-language/
[2] http://www.codecommit.com/blog/scala/is-scala-not-functional-enough
[3] http://james-iry.blogspot.com/2009/05/erlang-is-not-functional.html
[4]
http://james-iry.blogspot.com/2010/03/robert-fischer-finally-admits-that...
Best regards
Andreas
Re: Re: functional/immutable programming question
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Razvan Cojocaru schrieb:
> The real world has state and any program trying to model the real world
> will have to stash some state somewhere...
The real world has cats, too. Does that mean, that every program that
models the real world has to stash some cats somewhere?
- --
Tschööö--->...Stefan
- ---------------------------
Don't visit my homepage at:
http://home.arcor-online.net/hirnstrom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkzkAYwACgkQQeATqGpDnRq16ACfTL22KqWQvuPCovGB5anTIRO5
9IwAoIf744aj/XorW2lN3FzdatnBKYz4
=AwvS
-----END PGP SIGNATURE-----
RE: Re: functional/immutable programming question
Now that would be cruel, wouldn’t it?
-----Original Message-----
From: Stefan Wagner [mailto:wagner [dot] stefan [at] berlin [dot] de]
Sent: November-17-10 11:24 AM
To: scala-user [at] listes [dot] epfl [dot] ch
Subject: Re: [scala-user] Re: functional/immutable programming question
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Razvan Cojocaru schrieb:
> The real world has state and any program trying to model the real
> world will have to stash some state somewhere...
The real world has cats, too. Does that mean, that every program that models the real world has to stash some cats somewhere?
- --
Tschööö--->...Stefan
- ---------------------------
Don't visit my homepage at:
http://home.arcor-online.net/hirnstrom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkzkAYwACgkQQeATqGpDnRq16ACfTL22KqWQvuPCovGB5anTIRO5
9IwAoIf744aj/XorW2lN3FzdatnBKYz4
=AwvS
-----END PGP SIGNATURE-----
Re: Re: functional/immutable programming question
graham
On Nov 17, 2010, at 8:23 AM, Stefan Wagner wrote:
Re: Re: functional/immutable programming question
On Wed, Nov 17, 2010 at 11:35 AM, Graham Matthews
wrote:
> Functional programming is not about stateless programming, it is about
> passing state *explicitly* (this is commonly referred to as "stateless", but
> that is a misnomer). Imperative programming passes state *implicitly* which
> is commonly referred to as "stateful", again a misnomer.
+1
tho
1) well, functional programing is perhaps really only about making
functions be "first-class". everything beyond that is maybe personal
choice, religion, favourite flavour.
2) well, to be furtherly pedantic: imperative programming can do
either whereas pure functional doesn't, so in some sense imperative is
the superset of functional. so imperative doesn't *always* pass state
implicitly. (and in reality most so-called functional programming
languages end up supporting mutation, and people end up using it, so
it is kinda rare to be purely functional.)
??
sincerely.
Re: Re: functional/immutable programming question
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 18/11/10 05:45, Raoul Duke wrote:
> On Wed, Nov 17, 2010 at 11:35 AM, Graham Matthews
> wrote:
>> Functional programming is not about stateless programming, it is
>> about passing state *explicitly* (this is commonly referred to as
>> "stateless", but that is a misnomer). Imperative programming
>> passes state *implicitly* which is commonly referred to as
>> "stateful", again a misnomer.
>
> +1
>
> tho
>
> 1) well, functional programing is perhaps really only about making
> functions be "first-class". everything beyond that is maybe
> personal choice, religion, favourite flavour.
Functional programming is programming with functions. This has nothing
to do with anything being "first-class."
>
> 2) well, to be furtherly pedantic: imperative programming can do
> either whereas pure functional doesn't, so in some sense imperative
> is the superset of functional. so imperative doesn't *always* pass
> state implicitly. (and in reality most so-called functional
> programming languages end up supporting mutation, and people end up
> using it, so it is kinda rare to be purely functional.)
This is very untrue, misleading, common and (I have found) difficult
to "unteach".
There is no superset. A pure functional language like Haskell does
imperative programming *a whole lot better than most imperative
languages*. In other words, there is an embedded "DSL" (if you'll
allow the degenerate jargon) in Haskell that is an imperative
language. Let me repeat that -- Haskell, a pure functional language,
has an imperative language embedded within it.
This imperative programming language just happens to *kick serious
arse over most other imperative languages*. It allows first-class IO
action values. It has type inference and a clean unintrusive syntax
for imperative programming. Try doing that Java with your redundant
types, parentheses and semi-colons. -- no actually don't (I've seen
first-hand what happens when JSR teams try something useful).
By this argument, you could successfully argue that pure functional
programming is a superset of imperative programming. This is also
untrue (and obviously, both cannot be true). I'll leave the flawed
logic as a somewhat perverted exercise and expel no more breath on it.
The important question is not "which dogma" you decide to associate
with, but understanding the practical implications of the assessment.
You don't "decide to use or not to use imperative programming." Which
solution, regardless of our projections, is most practical in the
scenario? Are you using Java? Python? Then good luck getting any
compositionality out of your programs -- concede the point as you
accept those implications (or don't to some extent -> Functional
Java). It's not a dichotomy; it's a continuum and there are
implications to be accepted all the way along it. The question is
complex to answer and too often I see a misidentification of the
essential attributes that should contribute to making that decision.
In this fallacious case, it's easy -- any conclusions are at best,
coincidentally true.
Let's not harp on.
I'm quite sure I have posted the State data structure and the
associated monad several times now. I'm not sure why it's not sinking
in (perhaps it was ignored). Did you see the S type variable? Imagine
now that S=Universe. There you have it -- a pure functional
programming construct embedded in an imperative language such as Scala.
For example, if we suppose:
* A wrapper on State[Universe, _]:
type IO[A] = State[Universe, A]
* a function readFile which takes a FileName and normally returns a
type FileContents instead is denoted:
readFile: FileName => IO[FileContents]
* a function writeFile which takes a FileName, FileContents and
returns Unit:
writeFile: FileName => FileContents => IO[Unit]
then look at this program:
val x: IO[Unit] =
for(apples <- readFile("apples.txt")
bananas <- readFile("bananas.txt"))
yield writeFile("applesandbananas.txt")(apples ++ bananas)
An imperative-looking program without any side-effects!
Hope this helps.
PS: I note an earlier statement that "the real world has state." This
fallacy is of a similar ilk and ironically, departs from anything
resembling the real world. A meta-fallacy about the real world is
something I encounter all too often in programming to such an extent
that I now find it quite boring.
>
> ??
>
> sincerely.
Re: Re: functional/immutable programming question
On Wed, Nov 17, 2010 at 4:14 PM, Tony Morris <tonymorris [at] gmail [dot] com> wrote:
There you have it -- exactly what Raoul was trying to say! It's possible for an imperative language to have functional constructs used in it!
Perhaps the wording was not mathematically precise, how sad.
Re: Re: functional/immutable programming question
On Wed, Nov 17, 2010 at 4:14 PM, Tony Morris <tonymorris [at] gmail [dot] com> wrote:
What is your definition of state, Tony? I'm not so confident it's the same as that of the one who made the above statement.
Also, you've made statements several times about what the essence of the "real world" is. Tell me, how is it possible for a human being to know what the essence of the real world is?
Re: Re: functional/immutable programming question
Hi Tony,
Response below:
On 18/11/2010, at 8:14 AM, Tony Morris wrote:
> I'm quite sure I have posted the State data structure and the
> associated monad several times now. I'm not sure why it's not sinking
> in (perhaps it was ignored).
It isn't sinking in because I suspect most people can't understand your answers. They see a short snippet of code, and don't get its relevance.
I've been floating here for a little while. I understand some parts of functional programming quite well I think, but I haven't internalised category theory (and have other priorities).
I'm not going to go back and find examples in email, but I'll use a recent post from your blog: . In that post you list "15 (probably fun) exercises", but I can't easily read the questions. i.e. I don't think I'd have too much trouble doing the questions, if I knew what the question was. I don't think I'm the only person with this problem - I noticed on one of your blog posts that someone was asking if they'd answered a question correctly and you said that if it compiled the answer must be correct. That may be true, but a) it is weird for most people, and b) that means they need to REALLY understand scala types and most people don't.
Your emails are similar to your blog posts - they are very compact and I'm sure make perfect sense to someone who understands this stuff, but I simply can't understand them at normal reading pace. I might be able to decode them if I spent a fair while thinking about it, but I'm not willing to spend that time (I'm just lurking after all), and I suspect that many readers wouldn't even if they had more than a passing interest in the subject.
Now, this email is not meant to be critical of anyone. It could be read as critical of either you (for not explaining better) or others on the list (for being lazy readers), but it isn't meant to be either.
It isn't your job to educate people. But, if you do want to educate people then your current short responses could be improved.
In summary, it isn't sinking in because I suspect most people can't understand your answers. They see a short snippet of code, and don't get its relevance.
Cheers,
Will :-}
Re: Re: functional/immutable programming question
Hello William,
Take the following code and try to do the exercise.
http://paste.pocoo.org/show/292912/
If it compiles, you probably have it right, though this just happens to
be less true for State operations than other simple data structures. If
it compiles and you are wrong, I will tell you. I will even give you the
tools to verify it, however, if I gave them to you right now, you'd feel
even more overwhelmed by the exercises.
Where do you get stuck?
I take teaching seriously (and it is my job in fact). Programming is
hard and I'm not fond of pretending otherwise.
On 18/11/10 13:36, William Uther wrote:
> Hi Tony,
> Response below:
>
> On 18/11/2010, at 8:14 AM, Tony Morris wrote:
>
>
>> I'm quite sure I have posted the State data structure and the
>> associated monad several times now. I'm not sure why it's not sinking
>> in (perhaps it was ignored).
>>
> It isn't sinking in because I suspect most people can't understand your answers. They see a short snippet of code, and don't get its relevance.
>
> I've been floating here for a little while. I understand some parts of functional programming quite well I think, but I haven't internalised category theory (and have other priorities).
>
> I'm not going to go back and find examples in email, but I'll use a recent post from your blog: . In that post you list "15 (probably fun) exercises", but I can't easily read the questions. i.e. I don't think I'd have too much trouble doing the questions, if I knew what the question was. I don't think I'm the only person with this problem - I noticed on one of your blog posts that someone was asking if they'd answered a question correctly and you said that if it compiled the answer must be correct. That may be true, but a) it is weird for most people, and b) that means they need to REALLY understand scala types and most people don't.
>
> Your emails are similar to your blog posts - they are very compact and I'm sure make perfect sense to someone who understands this stuff, but I simply can't understand them at normal reading pace. I might be able to decode them if I spent a fair while thinking about it, but I'm not willing to spend that time (I'm just lurking after all), and I suspect that many readers wouldn't even if they had more than a passing interest in the subject.
>
> Now, this email is not meant to be critical of anyone. It could be read as critical of either you (for not explaining better) or others on the list (for being lazy readers), but it isn't meant to be either.
>
> It isn't your job to educate people. But, if you do want to educate people then your current short responses could be improved.
>
> In summary, it isn't sinking in because I suspect most people can't understand your answers. They see a short snippet of code, and don't get its relevance.
>
> Cheers,
>
> Will :-}
>
>
Re: Re: functional/immutable programming question
I really shouldn't be wasting my time on this claim, but I am curious about what it could possibly mean.
The statement that "the real world has state" is a "fallacy"? Why? (I'll assume you don't mean that the statement is grammatically incorrect, because that is not the same as being false.)
Does the "real world" exist? Does "state" exist? If both "state" and "the real world" exist, then does "state" exist in "the real world"? If not, then where does it exist?
In my field, the "state" of a flight means its position, velocity, and possibly other attributes of the motion of the aircraft, such as attitude, turn rate, etc. In a given volume of airspace, the "state" of the traffic means the collection of the states of each individual flight. In "state estimation and control theory," a "state vector" is a list of coordinates or components that represent a "state" in terms of a particular coordinate system and set of physical units. In other fields of engineering, "state" can include other aspects of a "system," such as the temperature or pressure of a chemical process. Those states certainly exist in the real world, so I think we can safely conclude that "the real world has state."
What are we to make of someone who claims otherwise? That he doesn't live in the real world?
Russ P.
--
http://RussP.us
Re: Re: functional/immutable programming question
A statement can't be a fallacy. Only an argument can be fallacious.
At best you could say that the "common sense" chain of reasoning which
leads people to conclude that the real world has state is fallacious.
I agree that it is not clear when you think about it whether "The real
world has state" is true or indeed what exactly it means. There is a
body of philosophical literature which deals with the question as to
what metaphysical status should be given to events and actions. See
http://plato.stanford.edu/entries/events/: the bit about events and
objects is probably most relevant here -- Tony, I assume you would
agree with Quine. It's also not clear whether 'state' and 'events'
refer to similar concepts.
Of course, once you get philosophical most general statements we might
make about the world have a tendency to dissolve. "The real world has
objects" is also not uncontroversial -- Kant for one would not agree.
Maybe the fallacy lies just in trying to take some commonplace about
the 'real world' and use it in an argument about programming.
Well that woke me up.
-Rob
On Thu, Nov 18, 2010 at 2:10 AM, Russ Paielli wrote:
> On Wed, Nov 17, 2010 at 1:14 PM, Tony Morris wrote:
>>
>> PS: I note an earlier statement that "the real world has state." This
>> fallacy is of a similar ilk and ironically, departs from anything
>> resembling the real world. A meta-fallacy about the real world is
>> something I encounter all too often in programming to such an extent
>> that I now find it quite boring.
>>
>
> I really shouldn't be wasting my time on this claim, but I am curious about
> what it could possibly mean.
>
> The statement that "the real world has state" is a "fallacy"? Why? (I'll
> assume you don't mean that the statement is grammatically incorrect, because
> that is not the same as being false.)
>
> Does the "real world" exist? Does "state" exist? If both "state" and "the
> real world" exist, then does "state" exist in "the real world"? If not, then
> where does it exist?
>
> In my field, the "state" of a flight means its position, velocity, and
> possibly other attributes of the motion of the aircraft, such as attitude,
> turn rate, etc. In a given volume of airspace, the "state" of the traffic
> means the collection of the states of each individual flight. In "state
> estimation and control theory," a "state vector" is a list of coordinates or
> components that represent a "state" in terms of a particular coordinate
> system and set of physical units. In other fields of engineering, "state"
> can include other aspects of a "system," such as the temperature or pressure
> of a chemical process. Those states certainly exist in the real world, so I
> think we can safely conclude that "the real world has state."
>
> What are we to make of someone who claims otherwise? That he doesn't live in
> the real world?
>
> Russ P.
>
> --
> http://RussP.us
>
Re: Re: functional/immutable programming question
On 18/11/10 16:25, Robert Wills wrote:
> A statement can't be a fallacy.
>
A statement can be a fallacy. The word fallacy derives from the word
"false." The statement under discussion is false, therefore, it is a
fallacy.
Re: Re: functional/immutable programming question
Sorry this is getting off topic I know...
'Fallacy' and 'false' share a common origin but 'fallacy' does not
derive from 'false':
http://www.etymonline.com/index.php?term=fallacy
http://www.etymonline.com/index.php?term=false
They both derive from 'fallere' but 'false' derives from the past
participle of 'fallere': ie of having been deceived.
Even if the one did derive from the other I wouldn't accept your
argument: 'cretin' derives from 'Christian' but this does not imply
that if someone is a Christian, then that person is a cretin-- though
one might believe the conclusion for other reasons.
http://www.etymonline.com/index.php?search=cretin
Sorry for being so tedious -- I studied philosophy at university so I
have trouble letting these sorts of things drop. Anyway, Tony, I
think I generally agree with you about state and the world.
-Rob
On Thu, Nov 18, 2010 at 7:46 AM, Tony Morris wrote:
> On 18/11/10 16:25, Robert Wills wrote:
>> A statement can't be a fallacy.
>>
> A statement can be a fallacy. The word fallacy derives from the word
> "false." The statement under discussion is false, therefore, it is a
> fallacy.
>
Re: Re: functional/immutable programming question
On Thursday November 18 2010, Robert Wills wrote:
> Sorry this is getting off topic I know...
But it is nice to have a philosopher / logician around.
The ontological schools of thought in question here are perdurantism and
endurantism. Tony's position corresponds most closely to endurantism.
Special relativity (along with general relativity is an astonishingly
well-confirmed physical theory) is problematic for endurantism [1]
Randall Schulz
[1]
> 'Fallacy' and 'false' share a common origin but 'fallacy' does not
> derive from 'false': ...
>
> Sorry for being so tedious -- I studied philosophy at university so I
> have trouble letting these sorts of things drop. Anyway, Tony, I
> think I generally agree with you about state and the world.
>
> -Rob
>
> On Thu, Nov 18, 2010 at 7:46 AM, Tony Morris wrote:
> > On 18/11/10 16:25, Robert Wills wrote:
> >> A statement can't be a fallacy.
> >
> > A statement can be a fallacy. The word fallacy derives from the
> > word "false." The statement under discussion is false, therefore,
> > it is a fallacy.
Re: Re: functional/immutable programming question
Control engineering can be broken down into two basic categories: linear and nonlinear. In linear control theory, the dynamics of the system to be controlled are linear (or at least modeled as linear), and the basic equations are
dx/dt = A x + B u
y = C x + w
where x is the state vector, A is the state transition matrix, u is the control vector (the control inputs), B is the input distribution matrix, y is the output vector (the measurements from the sensors), C is the observation matrix, and w is the random measurement noise. The vectors x, u, y, and w are all functions of time, but matrices A, B, and C are constant (or slowly varying and approximated as constant). These two equations in one form or another have appeared in literally thousands of papers on control theory. The objective of the control theorist or engineer is to determine the feedback control settings u as a function of the output y to make x do what we want it to do. A related field is estimation theory, which is the art of getting the best estimate possible of the state x in the presence of the random measurement noise w.
For a nonlinear dynamic system, the equations are generalized to
dx/dt = f(x, u)
y = h(x, w)
where f and h are nonlinear functions in general. Linear control theory is complex enough, but nonlinear control theory is much more complex yet.
The "state" of a dynamic system is basically just a snapshot in time of its dynamic state. To label as "fallacious" the statement that "the real world has state" is at best semantic pedantry and at worse nonsense. It is to claim essentially that points in time do not exist. Do they exist? I'm going to go out on a limb and say they do. If they don't, then they are a very useful approximation anyway.
We could get into a deep discussion about relativity, but for practical mechanical (e.g., automotive or aeronautical) control engineering, Newtonian mechanics is more than adequate. If some engineer suggested accounting for relativistic effects in flight control, he would quickly be relieved of his job.
--Russ P.
On Thu, Nov 18, 2010 at 6:06 AM, Randall R Schulz <rschulz [at] sonic [dot] net> wrote:
--
http://RussP.us
Re: Re: functional/immutable programming question
Unless, of course, the plane used GPS for navigation, in which case
they would indeed be using relativistic effects!
...but I digress.
On Thu, Nov 18, 2010 at 3:05 PM, Russ Paielli wrote:
> At one time in my life I was interested in becoming a philosopher, but
> fortunately I took a different path. Instead, I studied control engineering.
> For those who are not aware, control theory/engineering is a huge field,
> with many journals and conferences every year devoted to it and its many
> branches. It is now a fairly mature field, having had its major growth
> period over the past few decades.
>
> Control engineering can be broken down into two basic categories: linear and
> nonlinear. In linear control theory, the dynamics of the system to be
> controlled are linear (or at least modeled as linear), and the basic
> equations are
>
> dx/dt = A x + B u
> y = C x + w
>
> where x is the state vector, A is the state transition matrix, u is the
> control vector (the control inputs), B is the input distribution matrix, y
> is the output vector (the measurements from the sensors), C is the
> observation matrix, and w is the random measurement noise. The vectors x, u,
> y, and w are all functions of time, but matrices A, B, and C are constant
> (or slowly varying and approximated as constant). These two equations in one
> form or another have appeared in literally thousands of papers on control
> theory. The objective of the control theorist or engineer is to determine
> the feedback control settings u as a function of the output y to make x do
> what we want it to do. A related field is estimation theory, which is the
> art of getting the best estimate possible of the state x in the presence of
> the random measurement noise w.
>
> For a nonlinear dynamic system, the equations are generalized to
>
> dx/dt = f(x, u)
> y = h(x, w)
>
> where f and h are nonlinear functions in general. Linear control theory is
> complex enough, but nonlinear control theory is much more complex yet.
>
> The "state" of a dynamic system is basically just a snapshot in time of its
> dynamic state. To label as "fallacious" the statement that "the real world
> has state" is at best semantic pedantry and at worse nonsense. It is to
> claim essentially that points in time do not exist. Do they exist? I'm going
> to go out on a limb and say they do. If they don't, then they are a very
> useful approximation anyway.
>
> We could get into a deep discussion about relativity, but for practical
> mechanical (e.g., automotive or aeronautical) control engineering, Newtonian
> mechanics is more than adequate. If some engineer suggested accounting for
> relativistic effects in flight control, he would quickly be relieved of his
> job.
>
> --Russ P.
>
> On Thu, Nov 18, 2010 at 6:06 AM, Randall R Schulz wrote:
>>
>> On Thursday November 18 2010, Robert Wills wrote:
>> > Sorry this is getting off topic I know...
>>
>> But it is nice to have a philosopher / logician around.
>>
>> The ontological schools of thought in question here are perdurantism and
>> endurantism. Tony's position corresponds most closely to endurantism.
>> Special relativity (along with general relativity is an astonishingly
>> well-confirmed physical theory) is problematic for endurantism [1]
>>
>>
>> Randall Schulz
>>
>>
>
> --
> http://RussP.us
>
Re: Re: functional/immutable programming question
I thought about mentioning that, but I figured I'd rambled long enough and had better get back to work before I am relieved of my job!
--Russ P.
--
http://RussP.us
Re: Re: functional/immutable programming question
It is amusing to see philosophical arguments based on solid scientific
foundations go wrong at the last turn, especially when the author
displays a rather high degree of knowledge about their usual
interpretations.
In a nutshell, as this is probably off-topic even for scala-debate:
Because of the finite speed of light, what you see at one time has
actually happened at (different) times in the past. More precisely, what
you see is radiation emitted by some particle which was on the light
cone around the negative time axis in your rest frame (assuming the
"eye" is at the origin). That this radiation constitutes a "proper part"
of that particle has not been argued and there is a priori no reason to
assume so [1]. Hence, whether you may be able to simultaneously see
different parts of an object as they existed at different times is
completely immaterial to the question at hand.
Dr. Roland Kuhn (specializing in high-energy quantum physics)
[1] If you go down this route by relying on quantum entanglement, the
whole universe (at least within our event horizon) must be viewed as one
single object.
Am 18.11.2010 15:06, schrieb Randall R Schulz:
> On Thursday November 18 2010, Robert Wills wrote:
>> Sorry this is getting off topic I know...
> But it is nice to have a philosopher / logician around.
>
> The ontological schools of thought in question here are perdurantism and
> endurantism. Tony's position corresponds most closely to endurantism.
> Special relativity (along with general relativity is an astonishingly
> well-confirmed physical theory) is problematic for endurantism [1]
>
>
> Randall Schulz
>
>
> [1]
>
>
>> 'Fallacy' and 'false' share a common origin but 'fallacy' does not
>> derive from 'false': ...
>>
>> Sorry for being so tedious -- I studied philosophy at university so I
>> have trouble letting these sorts of things drop. Anyway, Tony, I
>> think I generally agree with you about state and the world.
>>
>> -Rob
>>
>> On Thu, Nov 18, 2010 at 7:46 AM, Tony Morris wrote:
>>> On 18/11/10 16:25, Robert Wills wrote:
>>>> A statement can't be a fallacy.
>>> A statement can be a fallacy. The word fallacy derives from the
>>> word "false." The statement under discussion is false, therefore,
>>> it is a fallacy.
>
RE: Re: Re: functional/immutable programming question
So... singleton or not... this universe... does it or does it not have
state?
----------
Well, of course my sentence itself is true, syntactically speaking, since
the world (*now* at least) includes my sentence which includes the word
"state"...
What is a fallacy (either as false or rather wrong) is what I tried to mean
(or rather do) by using that sentence in that context... i.e. the semantics
behind the words... an attempt and psychological bullying, to reach a wanted
conclusion, using an obviously true and undisputable statement (undisputable
at least at first reading)...and *this* is what he must've reacted to, as
evidenced by the other half of the respective paragraph... I would've
thought that was obvious...
I'm not arguing that everything Tony says is obvious (rather the contrary,
since without the effort, there can be no learning, eh?), but this one
seemed so...
------------
What really pissed me off is the sudden realization that I had to put my
bikes away for the next 5 months of winter, while some can probably go at it
throughout the year... but this was even more off-topic than the currently
off-topic topic...
-----Original Message-----
From: Roland Kuhn [mailto:rk [at] rkuhn [dot] info]
Sent: November-18-10 12:01 PM
To: Randall R Schulz
Cc: scala-debate [at] listes [dot] epfl [dot] ch
Subject: [scala-debate] Re: [scala-user] Re: functional/immutable
programming question
It is amusing to see philosophical arguments based on solid scientific
foundations go wrong at the last turn, especially when the author displays a
rather high degree of knowledge about their usual interpretations.
In a nutshell, as this is probably off-topic even for scala-debate:
Because of the finite speed of light, what you see at one time has actually
happened at (different) times in the past. More precisely, what you see is
radiation emitted by some particle which was on the light cone around the
negative time axis in your rest frame (assuming the "eye" is at the origin).
That this radiation constitutes a "proper part"
of that particle has not been argued and there is a priori no reason to
assume so [1]. Hence, whether you may be able to simultaneously see
different parts of an object as they existed at different times is
completely immaterial to the question at hand.
Dr. Roland Kuhn (specializing in high-energy quantum physics)
[1] If you go down this route by relying on quantum entanglement, the whole
universe (at least within our event horizon) must be viewed as one single
object.
Am 18.11.2010 15:06, schrieb Randall R Schulz:
> On Thursday November 18 2010, Robert Wills wrote:
>> Sorry this is getting off topic I know...
> But it is nice to have a philosopher / logician around.
>
> The ontological schools of thought in question here are perdurantism
> and endurantism. Tony's position corresponds most closely to endurantism.
> Special relativity (along with general relativity is an astonishingly
> well-confirmed physical theory) is problematic for endurantism [1]
>
>
> Randall Schulz
>
>
> [1] lepdf/endurantism.pdf>
>
>
>> 'Fallacy' and 'false' share a common origin but 'fallacy' does not
>> derive from 'false': ...
>>
>> Sorry for being so tedious -- I studied philosophy at university so I
>> have trouble letting these sorts of things drop. Anyway, Tony, I
>> think I generally agree with you about state and the world.
>>
>> -Rob
>>
>> On Thu, Nov 18, 2010 at 7:46 AM, Tony Morris wrote:
>>> On 18/11/10 16:25, Robert Wills wrote:
>>>> A statement can't be a fallacy.
>>> A statement can be a fallacy. The word fallacy derives from the word
>>> "false." The statement under discussion is false, therefore, it is a
>>> fallacy.
>
Re: Re: functional/immutable programming question
Could you move this to scala-debate as it is really getting OT
2010/11/18 Randall R Schulz :
> On Thursday November 18 2010, Robert Wills wrote:
>> Sorry this is getting off topic I know...
>
> But it is nice to have a philosopher / logician around.
>
> The ontological schools of thought in question here are perdurantism and
> endurantism. Tony's position corresponds most closely to endurantism.
> Special relativity (along with general relativity is an astonishingly
> well-confirmed physical theory) is problematic for endurantism [1]
>
>
> Randall Schulz
>
>
> [1]
>
>
>> 'Fallacy' and 'false' share a common origin but 'fallacy' does not
>> derive from 'false': ...
>>
>> Sorry for being so tedious -- I studied philosophy at university so I
>> have trouble letting these sorts of things drop. Anyway, Tony, I
>> think I generally agree with you about state and the world.
>>
>> -Rob
>>
>> On Thu, Nov 18, 2010 at 7:46 AM, Tony Morris wrote:
>> > On 18/11/10 16:25, Robert Wills wrote:
>> >> A statement can't be a fallacy.
>> >
>> > A statement can be a fallacy. The word fallacy derives from the
>> > word "false." The statement under discussion is false, therefore,
>> > it is a fallacy.
>
>
>
Re: Re: functional/immutable programming question
On Nov 17, 2010, at 10:25 PM, Robert Wills wrote:
To me this is the only fallacy worth talking about in this chain of discussion.
I am interested in writing reliable, high performance programs. As an engineer I use the techniques, theory, etc that allow me to do this, irrespective of what is "in the real world".
This is one of the reasons I like Scala, and O'Caml -- they allow me to chose among various programming/engineering choices depending on the situation. I can mix and match as need be.
graham
Re: Re: functional/immutable programming question
let me first say that, deep in my heart, I am a pure functional programmer
we can, of course, have endless discussions about vaguely defined vocabulary
and sentences produced with it, and, I have to confess, I'm also not fully defining
my vocabulary and the sentences that I produce with it
> Functional programming is programming with functions. This has nothing
> to do with anything being "first-class."
maybe, in the sense that functions are values, the are "first class" in, afaik,
all mainstream languages that, by most programmers, are called functional
languages
as far as Haskell is all about programming with functions, it certainly benefits
from 'this functions being "first class" aspect' [ higher order functions, ... ]
> A pure functional language like Haskell does
> imperative programming *a whole lot better than most imperative
> languages*. In other words, there is an embedded "DSL" in Haskell
> that is an imperative language.
by the way, now you suddenly talk about pure functional languages, but,
aside of that, what exactly do you mean by imperative,
I think you refer to Haskell's monad based do syntax (similar
to Scala's for loop syntax), but, if you write something like
this code may look imperative (especially because of the do keyword),
but, behind the scenes it does not do the same imperative thing as as, say,
an assignment in Java (in Haskell everything is final)
... and this discussion can go on and on ...
Luc
Re: functional/immutable programming question
Luc Duponcheel skrev 2010-11-17 22:49:
> by the way, now you suddenly talk about /pure/ functional languages, but,
> aside of that, what exactly do you mean by /imperative/,
Wouldn't it be reasonable to think of "imperative" as a sequence of
steps performed to produce a result? The difference is that in Haskell
this sequencing is made explicit in the type system through the use of
monads, but in most commonly used programming languages it's not
reflected in the types, but instead built into the language as statements.
/Jesper Nordenberg
Re: functional/immutable programming question
On 18/11/10 09:19, Jesper Nordenberg wrote:
>
>
> Luc Duponcheel skrev 2010-11-17 22:49:
>> by the way, now you suddenly talk about /pure/ functional languages,
>> but,
>> aside of that, what exactly do you mean by /imperative/,
>
> Wouldn't it be reasonable to think of "imperative" as a sequence of
> steps performed to produce a result? The difference is that in Haskell
> this sequencing is made explicit in the type system through the use of
> monads, but in most commonly used programming languages it's not
> reflected in the types, but instead built into the language as
> statements.
>
> /Jesper Nordenberg
>
s/monads/types
Re: Re: functional/immutable programming question
Hi Luc,
I believe you are restating my point, but a little differently and perhaps even more succinctly for some. Specifically, it raises the question, "just what is imperative programming?" While important to some, I personally find it an uninteresting question and prefer to restate the question to provoke an examination of the practical benefits. I'm hoping to appease the audience for which this is an important question, while alluding to the practical implications as you have done in your "imperative looking" example.
I wish to emphasise that "imperative programming is a superset of functional programming" is not only a fallacy, but a very destructive one in that it can impair potential for understanding.
Re: Re: functional/immutable programming question
Also, do you agree or disagree that "pure" implies a subset of something?
On Wed, Nov 17, 2010 at 5:39 PM, Tony Morris <tonymorris [at] gmail [dot] com> wrote:
Re: Re: functional/immutable programming question
Ok so I would turn it around.
A functional program language is one in which *all* functions are *guaranteed* to be referentially transparent (RT) -- so
for *all* functions, f, if x = y then f(x) = f(y)
Some people call this programming with "mathematical" functions.
An imperative programming language is one which doesn't make such a guarantee.
If you wondering how I/O can possibly be referentially transparent, there are two standard approaches.
First the Clean (the programming language) approach :-
a) I/O functions take a "World" as an argument, and return a new "World" as a result. b) the "World" type is a uniqueness type, guaranteeing the world gets single threaded, and that functions cannot access intermediate "world" results (hence the condition part of RT is trivially satisfied since two worlds are never equal).
Second the Haskell approach :-
a) Haskell functions don't do I/O, they return actions that when run, do do I/O.b) the Haskell I/O monad type is abstract -- functions taking I/O types cannot access any of the intermediate I/O states (again RT is trivially satisfied).
graham
Re: Re: functional/immutable programming question
Re: functional/immutable programming question
Graham Matthews skrev 2010-11-17 23:58:
> A functional program language is one in which *all* functions are
> *guaranteed* to be referentially transparent (RT) -- so
Uhm, this definition would exclude a lot of programming languages
normally considered functional, for example ML, OCaml, F#, Lisp etc.
/Jesper Nordenberg
Re: functional/immutable programming question
maybe a reason to partition them in pure functional resp. not pure functional ?
Luc
On Thu, Nov 18, 2010 at 12:09 AM, Jesper Nordenberg <megagurka [at] yahoo [dot] com> wrote:
--
__~O
-\ <,
(*)/ (*)
reality goes far beyond imagination
Re: Re: functional/immutable programming question
On Wed, Nov 17, 2010 at 2:39 PM, Tony Morris wrote:
> even more succinctly for some. Specifically, it raises the question, "just
> what is imperative programming?" While important to some, I personally find
> it an uninteresting question and prefer to restate the question to provoke
> an examination of the practical benefits. I'm hoping to appease the audience
it sounds to me like you advocate denotations of functional, but use
connotations of imperative.
> I wish to emphasise that "imperative programming is a superset of functional
> programming" is not only a fallacy, but a very destructive one in that
> it can impair potential for understanding.
http://lambda-the-ultimate.org/node/3465
sincerely.
Re: Re: functional/immutable programming question
On 18/11/10 08:56, Raoul Duke wrote:
> On Wed, Nov 17, 2010 at 2:39 PM, Tony Morris wrote:
>
>> even more succinctly for some. Specifically, it raises the question, "just
>> what is imperative programming?" While important to some, I personally find
>> it an uninteresting question and prefer to restate the question to provoke
>> an examination of the practical benefits. I'm hoping to appease the audience
>>
> it sounds to me like you advocate denotations of functional, but use
> connotations of imperative.
>
I simply advocate exploring interesting questions and I prefer not to
labour boring questions. I'm not sure how to make this clearer.