- 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: functional/immutable programming question
fp and immutable data structures are celebrated as solving all problems, but as you see, they don't, in particular they have no clear concept of dynamicity, so things that change over time. they don't solve your problem of concurrent access here, so you will need to linearize your clients in some way. for example, you could manage them with an Actor or use an STM... immutable structures and STM play nicely together, as when a transaction is aborted you haven't crippled your data structure, just the newly created copy (old list plus new head element, for instance) isn't stored in the ref, no damage is done.
best, -sciss-
Am 11.11.2010 um 09:45 schrieb Dennis Haupt:
> 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: functional/immutable programming question
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 11/11/10 22:30, Sciss wrote:
> fp and immutable data structures are celebrated as solving all
> problems, but as you see, they don't, in particular they have no
> clear concept of dynamicity, so things that change over time. they
> don't solve your problem of concurrent access here, so you will
> need to linearize your clients in some way. for example, you could
> manage them with an Actor or use an STM... immutable structures and
> STM play nicely together, as when a transaction is aborted you
> haven't crippled your data structure, just the newly created copy
> (old list plus new head element, for instance) isn't stored in the
> ref, no damage is done.
>
> best, -sciss-
Beware, nonsense lurks there.
Re: functional/immutable programming question
beware, your comments are a waste of time. if you want to help in this thread, break down your superior knowledge in a way that it is shared with others, and explain why something is nonsense in your opinion.
Am 11.11.2010 um 20:29 schrieb Tony Morris:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 11/11/10 22:30, Sciss wrote:
>> fp and immutable data structures are celebrated as solving all
>> problems, but as you see, they don't, in particular they have no
>> clear concept of dynamicity, so things that change over time. they
>> don't solve your problem of concurrent access here, so you will
>> need to linearize your clients in some way. for example, you could
>> manage them with an Actor or use an STM... immutable structures and
>> STM play nicely together, as when a transaction is aborted you
>> haven't crippled your data structure, just the newly created copy
>> (old list plus new head element, for instance) isn't stored in the
>> ref, no damage is done.
>>
>> best, -sciss-
> Beware, nonsense lurks there.
>
> - --
> Tony Morris
> http://tmorris.net/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkzcUkAACgkQmnpgrYe6r616mwCgr4kl31vSxo36XwH70Jt71d1z
> 9tcAnii11F1SLyI/XOiFNLNUOUelyzZu
> =3FTH
> -----END PGP SIGNATURE-----
>
Re: functional/immutable programming question
Hash: SHA1
Alas, if I were to respond to every bit of nonsense on the internet,
I'd be very busy indeed! Further, your particular misunderstanding is:
a) Extremely common
b) Extremely difficult (for me anyway) to demonstrate for a general
audience. I have done so successfully many times, but only with full
attention being given to the topic one-on-one.
Instead of addressing nonsense of this particular magnitude, I
request, in the most polite manner possible, the following: Stop
talking shit. In response, I will go to extraordinary efforts to do
same, nevertheless acknowledging both of our fallibility.
Sound fair? If not, where do I begin unravelling your fallacious
comments? It's an honest question -- despite your unawareness of
falsehood, I simply don't know where to begin.
Do you honestly believe that first sentence? Do you care to put a bit
more thought into it? I'm don't intend to be a dick, just prevent the
misguidance of others. Be nice to noobs -- you don't yet know how hard
it is to help them out after they've been misguided by nonsense like this.
On 12/11/10 07:09, Sciss wrote:
> beware, your comments are a waste of time. if you want to help in
> this thread, break down your superior knowledge in a way that it is
> shared with others, and explain why something is nonsense in your
> opinion.
>
> Am 11.11.2010 um 20:29 schrieb Tony Morris:
>
> On 11/11/10 22:30, Sciss wrote:
>>>> fp and immutable data structures are celebrated as solving
>>>> all problems, but as you see, they don't, in particular they
>>>> have no clear concept of dynamicity, so things that change
>>>> over time. they don't solve your problem of concurrent access
>>>> here, so you will need to linearize your clients in some way.
>>>> for example, you could manage them with an Actor or use an
>>>> STM... immutable structures and STM play nicely together, as
>>>> when a transaction is aborted you haven't crippled your data
>>>> structure, just the newly created copy (old list plus new
>>>> head element, for instance) isn't stored in the ref, no
>>>> damage is done.
>>>>
>>>> best, -sciss-
> Beware, nonsense lurks there.
>
>>
Re: functional/immutable programming question
hello tony,
i think we disagree here about the function and usage of a mailing list.
- if you do not have time because you are too busy, you can avoid the kind of reply you sent
- if you think the mistake(?) is very common, it is even more important to clarify it
- if you have done it many times, why don't you just send a link to an older mailing list
entry? apart from that, redundancy is a good thing.
- in particular i think it is healthy to believe that different people do not occupy a different degree
of truth, because truth ist not linear and absolute, but have different backgrounds
and different viewpoints. a mailing list is a communication means to establish some
kind of common sense (ideally) or consensus through discussion. so to terminate in saying
that something is nonsense or that someone should stop writing "shit" is completely useless.
- my point was that to view a process as a function comes with problems, in particular when
the main concept, temporality, is implicit. there may be better ways to explicate temporality,
although purely functional datastructures can be helpful here by simplifying reasoning
at another instance. and as has been written, you need "impurity" to express the intrusion
of the real world in terms of time-variant elements. the emphatic usage of the terms
"purity" and "state" seems to reveal a transcendental aesthetic that is found in
FP. i find it telling that terms such as "stateless" or "stateful" are used, where the state
is exactly the frozen time, the moment inbetween change, where if you speak in
terms of process, you would typically use the term "change" and "transition" and
inversely the "states" become the holes between transitions.
- as has been written in another reply, the actual problem was really one
of concurrency, and i gave my opinion == experience regarding this point, and i
don't see where your comments add to this.
you know i am generally a modest person, i don't believe i am god or on top of other people, and i thus have no problem in being incorrect in points or being corrected. but i am still not convinced that my text was not making sense.
best, -sciss-
Am 11.11.2010 um 21:19 schrieb Tony Morris:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Alas, if I were to respond to every bit of nonsense on the internet,
> I'd be very busy indeed! Further, your particular misunderstanding is:
>
> a) Extremely common
> b) Extremely difficult (for me anyway) to demonstrate for a general
> audience. I have done so successfully many times, but only with full
> attention being given to the topic one-on-one.
>
> Instead of addressing nonsense of this particular magnitude, I
> request, in the most polite manner possible, the following: Stop
> talking shit. In response, I will go to extraordinary efforts to do
> same, nevertheless acknowledging both of our fallibility.
>
> Sound fair? If not, where do I begin unravelling your fallacious
> comments? It's an honest question -- despite your unawareness of
> falsehood, I simply don't know where to begin.
>
> Do you honestly believe that first sentence? Do you care to put a bit
> more thought into it? I'm don't intend to be a dick, just prevent the
> misguidance of others. Be nice to noobs -- you don't yet know how hard
> it is to help them out after they've been misguided by nonsense like this.
>
>
> On 12/11/10 07:09, Sciss wrote:
> > beware, your comments are a
> waste of time. if you want to help in
>
>
> > this thread, break down your superior knowledge in a way that it
> is
>
>
> > shared with others, and explain why something is nonsense in your
>
>
> > opinion.
>
>
> >
>
>
> > Am 11.11.2010 um 20:29 schrieb Tony Morris:
>
>
> >
>
>
> > On 11/11/10 22:30, Sciss wrote:
>
>
> >>>> fp and immutable data structures are celebrated as
> solving
>
>
> >>>> all problems, but as you see, they don't, in
> particular they
>
>
> >>>> have no clear concept of dynamicity, so things that
> change
>
>
> >>>> over time. they don't solve your problem of
> concurrent access
>
>
> >>>> here, so you will need to linearize your clients in
> some way.
>
>
> >>>> for example, you could manage them with an Actor or
> use an
>
>
> >>>> STM... immutable structures and STM play nicely
> together, as
>
>
> >>>> when a transaction is aborted you haven't crippled
> your data
>
>
> >>>> structure, just the newly created copy (old list
> plus new
>
>
> >>>> head element, for instance) isn't stored in the ref,
> no
>
>
> >>>> damage is done.
>
>
> >>>>
>
>
> >>>> best, -sciss-
>
>
> > Beware, nonsense lurks there.
>
>
> >
>
>
> >>
>
>
> - --
> Tony Morris
> http://tmorris.net/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkzcXd8ACgkQmnpgrYe6r63KyACeMQlOlu3Sr4WJwJni044MVRSP
> 6NkAn2nGR458qzMUA9pmehIKk44u7/Zj
> =qlH5
> -----END PGP SIGNATURE-----
>
Re: functional/immutable programming question
On Thu, Nov 11, 2010 at 4:53 PM, Sciss <contact [at] sciss [dot] de> wrote:
I think this perspective is a nice way of looking at it. The functional paradigm and the stateful paradigm are two halves of a whole; the question is which is implicit and which is explicit. In functional programming, you describe the transformations: how to get from point A to point B. That's what a function is. A way to get from the input values to the return type. You make these explicit, and then you run your program. What happens? The computer, a state simulator (byte mover), steps through your logic and applies it to the current state (RAM, video memory, IO...) In imperative, mutable-state programming, you deal with "what's the state right now" directly, and although you organize this code inside functions, your focus is on the "stateful" half of the equation, and the transitioning is more taken for granted. Does that make any sense?
Re: functional/immutable programming question
I have long held the belief that a workflow/activity diagram and a state diagram are two sides of same coin...
Thanks,Razvan
On 2010-11-16, at 6:42 PM, Naftoli Gugenheim <naftoligug [at] gmail [dot] com> wrote:
Re: functional/immutable programming question
However, due to the fact that there is no 'functional purity' (in the closest sense you can, lets be honest, not even haskell(io/STM) or clojure(stm) are 'pure'), you can't reason about how safe concurrent operations are. The Actor model, while establishing a nice clear boundary between data in threads (or microthreads, implementation doesn't really matter) operating concurrently, doesn't prevent you from deadlocks or race conditions.
Now I'll venture into somewhat controversial territory. I'll make the claim that immutability and immutable data structures alone don't give any benefit to concurrent operations. You still need a way to rectify multiple threads operating on what once was the same structure. How do you merge the multiple heads of a linked list back into one? This is handled in Clojure and Haskell with a form of STM.
Unfortunately, that doesn't buy you much either. To steal from Cliff Click's argument, STM fails in the same way locks do: the challenge with both is at which granularity do you wrap your atomic (or lock) keyword? You can enforce just as much safety with locks as STM by wrapping everything in a synchronized block (or having a global mutex), locking only gets hard when you need performance. If you aren’t fine grained enough, you have contention issues, too fine grained and you have race conditions. Same with STM in the sense that you wrap too much with your Atomic blocks, and suddenly you have live-locks/infinite retries…
All in all, I think it does a disservice to the community to spread the myth that immutability and/or functional purity is a concurrency silver bullet. They are both fantastic features for building robust and readable software, but for other reasons. We (as an entire community of software engineers) *still* have the concurrency dragon to slay.
--Vincent
.
On Tue, Nov 16, 2010 at 4:58 PM, Razvan Cojocaru <pub [at] razie [dot] com> wrote:
Re: functional/immutable programming question
2010/11/17 Vincent Marquez :
> [...] The Actor model, while establishing a nice clear boundary
> between data in threads (or microthreads, implementation doesn't really
> matter) operating concurrently, doesn't prevent you from deadlocks or race
> conditions.[...]
Actually I do not believe this to be true. The problem with deadlocks
and race conditions only occurs if you are sharing data between
threads. If you are having two distinct actors / processes and they
receive immutable data then you do not have a lock in anyway which
again means you cannot have a racing or deadlock situation.
Now the implementation in Scala makes this fuzzy as the actor
implementation allowes you to shares data under the hood. There is no
true isolation between data. Although you can implement it in forms of
immutable messages and asynchronouse message delivery.
Taking Erlang as an example the vm makes it quite hard (almost
impossible) to share data and you have to serialize messages between
processes. In this condition it is impossible to produce deadlock or
race conditions. (Except maybe if you pass a message and wait for a
return message but the receiver doesn't send you one. This is also a
deadlock situation but on a much higher abstraction layer and
indicates a semantical error in your program in my eyes. This is not
what I'm talking about when I refer to deadlocks in this thread)
The only thing that can occur is process starvation meaning you are
giving the system so much to do that it is not capable of creating
more processes. But this is a general problem and applies to non
concurrent programs as well (e.g. CPU Time, Memory, etc...).
My 2cts.
-Stefan
Re: functional/immutable programming question
Hi Stefan,
it is good that you acknowledge that not all problems are solved by the
actor pattern. However I disagree with your distinction: deadlocks and
race conditions may be shifted to a higher level of abstraction, but
they are real problems nevertheless. Limiting your definition of these
words in order to be able to say that some aspect of the problem is
solved only distracts from the fact that other aspects of the very same
problem remain valid. Even Erlang does not remove the necessity for
careful design and implementation.
(sorry for the rant, it's just that I think it very rarely is a good
idea to tell people that they're safe)
Regards,
Roland
Am 17.11.2010 15:06, schrieb Stefan Langer:
> 2010/11/17 Vincent Marquez:
>> [...] The Actor model, while establishing a nice clear boundary
>> between data in threads (or microthreads, implementation doesn't really
>> matter) operating concurrently, doesn't prevent you from deadlocks or race
>> conditions.[...]
> Actually I do not believe this to be true. The problem with deadlocks
> and race conditions only occurs if you are sharing data between
> threads. If you are having two distinct actors / processes and they
> receive immutable data then you do not have a lock in anyway which
> again means you cannot have a racing or deadlock situation.
> Now the implementation in Scala makes this fuzzy as the actor
> implementation allowes you to shares data under the hood. There is no
> true isolation between data. Although you can implement it in forms of
> immutable messages and asynchronouse message delivery.
>
> Taking Erlang as an example the vm makes it quite hard (almost
> impossible) to share data and you have to serialize messages between
> processes. In this condition it is impossible to produce deadlock or
> race conditions. (Except maybe if you pass a message and wait for a
> return message but the receiver doesn't send you one. This is also a
> deadlock situation but on a much higher abstraction layer and
> indicates a semantical error in your program in my eyes. This is not
> what I'm talking about when I refer to deadlocks in this thread)
> The only thing that can occur is process starvation meaning you are
> giving the system so much to do that it is not capable of creating
> more processes. But this is a general problem and applies to non
> concurrent programs as well (e.g. CPU Time, Memory, etc...).
>
> My 2cts.
> -Stefan
Re: functional/immutable programming question
I'm actually not saying people are safe. But the Actor model does
solve the shared data and thread synchronisation problem.
It does not safe you from a communication error. The same could occur
if you do not have a concurrent problem and you are doing a loop
waiting for a condition to be true which never happens due to an erro,
this will leave you in an endless loop.
So waiting on a message and never receiving it is something totally
different from waiting on a lock to gain access to a resource which is
there but you can't get it cause somebody else is holding on to it.
-Stefan
2010/11/17 Roland Kuhn :
> Hi Stefan,
>
> it is good that you acknowledge that not all problems are solved by the
> actor pattern. However I disagree with your distinction: deadlocks and race
> conditions may be shifted to a higher level of abstraction, but they are
> real problems nevertheless. Limiting your definition of these words in order
> to be able to say that some aspect of the problem is solved only distracts
> from the fact that other aspects of the very same problem remain valid. Even
> Erlang does not remove the necessity for careful design and implementation.
>
> (sorry for the rant, it's just that I think it very rarely is a good idea to
> tell people that they're safe)
>
> Regards,
>
> Roland
>
> Am 17.11.2010 15:06, schrieb Stefan Langer:
>>
>> 2010/11/17 Vincent Marquez:
>>>
>>> [...] The Actor model, while establishing a nice clear boundary
>>> between data in threads (or microthreads, implementation doesn't really
>>> matter) operating concurrently, doesn't prevent you from deadlocks or
>>> race
>>> conditions.[...]
>>
>> Actually I do not believe this to be true. The problem with deadlocks
>> and race conditions only occurs if you are sharing data between
>> threads. If you are having two distinct actors / processes and they
>> receive immutable data then you do not have a lock in anyway which
>> again means you cannot have a racing or deadlock situation.
>> Now the implementation in Scala makes this fuzzy as the actor
>> implementation allowes you to shares data under the hood. There is no
>> true isolation between data. Although you can implement it in forms of
>> immutable messages and asynchronouse message delivery.
>>
>> Taking Erlang as an example the vm makes it quite hard (almost
>> impossible) to share data and you have to serialize messages between
>> processes. In this condition it is impossible to produce deadlock or
>> race conditions. (Except maybe if you pass a message and wait for a
>> return message but the receiver doesn't send you one. This is also a
>> deadlock situation but on a much higher abstraction layer and
>> indicates a semantical error in your program in my eyes. This is not
>> what I'm talking about when I refer to deadlocks in this thread)
>> The only thing that can occur is process starvation meaning you are
>> giving the system so much to do that it is not capable of creating
>> more processes. But this is a general problem and applies to non
>> concurrent programs as well (e.g. CPU Time, Memory, etc...).
>>
>> My 2cts.
>> -Stefan
>
>
Re: functional/immutable programming question
Am Mittwoch, den 17.11.2010, 16:51 +0100 schrieb Stefan Langer
:
> So waiting on a message and never receiving it is something totally
> different from waiting on a lock to gain access to a resource which is
> there but you can't get it cause somebody else is holding on to it.
Please forgive me if I am being ignorant here, but I'd call both a
deadlock, just on different levels of abstraction.
Kind regards
Andreas
Re: functional/immutable programming question
On Wed, Nov 17, 2010 at 10:56 AM, Andreas Flierl <andreas [at] flierl [dot] eu> wrote:
--
http://erikengbrecht.blogspot.com/
Funtional programming reading
Hello,
Can somebody guide me to an accessible introduction in functional
programming ? Something a Scala newbie should have read at least ! :-)
Thanks !
Jan
Re: Funtional programming reading
On 17 Nov 2010, at 17:43, Jan Goyvaerts wrote:
I've found http://learnyouahaskell.com/ to be useful.
The concepts introduced there apply to scala.
In fact, perhaps it would be useful to have a Learn you a Scala for even greater good ;)
Re: Funtional programming reading
A while back I watched quite a few lectures on the introduction to
functional programming, by Biran Harvey at U of Berkley, that i though
was very good.
http://www.youtube.com/watch?v=zmYqShvVDh4
perhaps thats useful.
Daniel
On Wed, 2010-11-17 at 18:43 +0100, Jan Goyvaerts wrote:
> Hello,
>
> Can somebody guide me to an accessible introduction in functional
> programming ? Something a Scala newbie should have read at least ! :-)
>
> Thanks !
>
> Jan
Re: Funtional programming reading
I recommend Eric Meijer's series on functional programming, on Channel 9.
http://channel9.msdn.com/Shows/Going+Deep/Lecture-Series-Erik-Meijer-Fun...
-jason
On Wed, Nov 17, 2010 at 6:47 PM, Daniel Gross wrote:
> A while back I watched quite a few lectures on the introduction to
> functional programming, by Biran Harvey at U of Berkley, that i though
> was very good.
>
> http://www.youtube.com/watch?v=zmYqShvVDh4
>
> perhaps thats useful.
>
> Daniel
>
> On Wed, 2010-11-17 at 18:43 +0100, Jan Goyvaerts wrote:
>> Hello,
>>
>> Can somebody guide me to an accessible introduction in functional
>> programming ? Something a Scala newbie should have read at least ! :-)
>>
>> Thanks !
>>
>> Jan
>
>
>
Re: Funtional programming reading
+1
I've also recently finished reading Bird & Wadler's Introduction to Functional Programming (1988!) and I found that helpful.
Re: Funtional programming reading
The value of the resources depend on your aim vis-a-vie functional programming. For example, i might recommend the Structure and Interpretation of Computer Programs, as a classic that every programmer should read, but especially those interested in DSL-based design and how that relates to functional programming. On the other hand, if your interest is in the how various features and capabilities relate to each other, such as pattern-matching and types or comprehensions and polymorphism, then you could do worse than Graham Hutton's book -- from which Erik's C9 lectures come. Erik's friend, and mine, Brian Beckman (also a C9 star), highly recommends Hudak's book. None of these are targeted to the Scala language, however.
Best wishes,
--greg
On Thu, Nov 18, 2010 at 6:21 AM, Richard Dallaway <dallaway [at] gmail [dot] com> wrote:
--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SWSeattle, WA 98136
+1 206.650.3740
http://biosimilarity.blogspot.com
Re: functional/immutable programming question
Granted it is not solved but it is definetly made more explicit.
2010/11/17 Erik Engbrecht :
> Agreed. Pushing a problem up a level of abstraction doesn't mean you can
> declare it solved.
>
>
> On Wed, Nov 17, 2010 at 10:56 AM, Andreas Flierl wrote:
>>
>> Am Mittwoch, den 17.11.2010, 16:51 +0100 schrieb Stefan Langer
>> :
>> > So waiting on a message and never receiving it is something totally
>> > different from waiting on a lock to gain access to a resource which is
>> > there but you can't get it cause somebody else is holding on to it.
>>
>> Please forgive me if I am being ignorant here, but I'd call both a
>> deadlock, just on different levels of abstraction.
>>
>> Kind regards
>> Andreas
>
>
>
> --
> http://erikengbrecht.blogspot.com/
>
Re: functional/immutable programming question
Especially if the problem is "too much abstraction" :)
--
Kevin Wright
mail / gtalk / msn : kev [dot] lee [dot] wright [at] gmail [dot] com
pulse / skype: kev.lee.wright
twitter: @thecoda
Re: functional/immutable programming question
Why do you think that Actors are too much abstraction?. The isolation
they provide gives you a much cleaner boundary then actually having
direct interaction between data in my opinion. This is actually
something STM does as well. It gives you a clear boundary between your
data and their data.
I'm not saying that it makes it less complex but it makes it more
explicit at which points your data changes.
2010/11/17 Kevin Wright :
>
>> Agreed. Pushing a problem up a level of abstraction doesn't mean you can
>> declare it solved.
>
>
> Especially if the problem is "too much abstraction" :)
>
> --
> Kevin Wright
>
> mail / gtalk / msn : kev [dot] lee [dot] wright [at] gmail [dot] com
> pulse / skype: kev.lee.wright
> twitter: @thecoda
>
>
Re: functional/immutable programming question
I don't. It was a reference to the semi-famous saying that:
Wish I knew who first came up with that one, it sounds like something that Knuth would say.
--
Kevin Wright
mail / gtalk / msn : kev [dot] lee [dot] wright [at] gmail [dot] com
pulse / skype: kev.lee.wright
twitter: @thecoda
Re: functional/immutable programming question
Hi Vincent,
Vincent Marquez wrote:
> I really don't believe it does Scala any to promote its'
> 'functional/immutable' aspects as a concurrent/parallel silver bullet.
(snip)
> All in all, I think it does a disservice to the community to spread
> the myth that immutability and/or functional purity is a concurrency
> silver bullet.
to be honest, I've read that claim nowhere. Noone ever spoke of the
silver bullet, as far as I am aware. I agree that it is no silver
bullet. What they say is that immutability (and functional purity) make
concurrency a lot easier. That coincides perfectly with my own
experience. I've written a couple of things over the years in imperative
style and years later in a functional style (whatever exactly that is).
My first attempts were rather impossible to transform into something
that used multiple processors and still had good throughput. With the
newer things it was e.g. enough to map tasks via
scala.actor.Futures.future and awaitAll (quasi map-reduce or fork-join)
because the tasks themselves had no side effects. That is, I could make
the parallel version by changing 2 lines of code...
> However, due to the fact that there is no 'functional purity' (in the
> closest sense you can, lets be honest, not even haskell(io/STM) or
> clojure(stm) are 'pure'), you can't reason about how safe concurrent
> operations are.
Exactly my point of view. For now, we'll have to live with "good enough
is OK".
> The Actor model, while establishing a nice clear
> boundary between data in threads (or
> microthreads, implementation doesn't really matter) operating
> concurrently, doesn't prevent you from deadlocks or race conditions.
Exactly my thoughts. What I really like is akka's dataflow
concurrency[1]. It brings determinism to concurrency. When you run the
same code, it either always deadlocks or never. It is no silver bullet
either, but it helps me a lot to reason about things.
> and readable software, but for other reasons. We (as an entire
> community of software engineers) *still* have the concurrency dragon
> to slay.
Absolutely. But I find it incredibly easier to tackle with functional
tools and immutable/persistent data structures at my disposal.
Thanks for sharing your opinion.
Kind regards
Andreas
[1]
http://www.scalablesolutions.se/akka/api/0.10/akka-core/se/scalablesolutions/akka/dataflow/DataFlow$.html
P.S.
Sadly akka's dataflow feature is not really documented at the moment.
Best thing I found is the somewhat outdated summary at
https://github.com/jboner/scala-dataflow
P.P.S
There are probably papers about dataflow concurrency (I think the
concept is quite old), but I don't know them. :)
Re: functional/immutable programming question
this is what i'd do in the stm:
def registerClient( c: Client )( implicit tx: Txn ) { clients.transform( _ + c )}
world.topology.registerClient( clnt )
versus
val world2 = world1.copy( topology = world1.topology.copy( clients = world1.territory.clients + clnt ))
which in my reading is bottom-up versus top-down, the former being way easier to oversee in this kind of scenario... basically any kind of scenario which is modules dynamically interconnected and no god object needing to have total knowledge of sub-parts. for instance, i still find MVC a great approach of OOP and this doesn't seem very suited for purely functional programming. but maybe i'm just not familiar with how i would do this other than path-copying which is prohibitive after you cross two or three layers.
best, -sciss-
Am 16.11.2010 um 23:42 schrieb Naftoli Gugenheim:
>
>
> On Thu, Nov 11, 2010 at 4:53 PM, Sciss wrote:
> i find it telling that terms such as "stateless" or "stateful" are used, where the state
> is exactly the frozen time, the moment inbetween change, where if you speak in
> terms of process, you would typically use the term "change" and "transition" and
> inversely the "states" become the holes between transitions.
>
>
> I think this perspective is a nice way of looking at it. The functional paradigm and the stateful paradigm are two halves of a whole; the question is which is implicit and which is explicit.
> In functional programming, you describe the transformations: how to get from point A to point B. That's what a function is. A way to get from the input values to the return type. You make these explicit, and then you run your program. What happens? The computer, a state simulator (byte mover), steps through your logic and applies it to the current state (RAM, video memory, IO...)
> In imperative, mutable-state programming, you deal with "what's the state right now" directly, and although you organize this code inside functions, your focus is on the "stateful" half of the equation, and the transitioning is more taken for granted.
> Does that make any sense?
>
Re: functional/immutable programming question
On Tue, Nov 16, 2010 at 4:02 PM, Sciss wrote:
> versus
> val world2 = world1.copy( topology = world1.topology.copy( clients = world1.territory.clients + clnt ))
would haskellian monad-related-do-notation help here?
Re: functional/immutable programming question
On 17/11/10 10:15, Raoul Duke wrote:
> On Tue, Nov 16, 2010 at 4:02 PM, Sciss wrote:
>
>> versus
>> val world2 = world1.copy( topology = world1.topology.copy( clients = world1.territory.clients + clnt ))
>>
> would haskellian monad-related-do-notation help here?
>
I refer back to, and propose as an exercise, the following. The
haskell-monad-do-notation corresponds to Scala's for-comprehensions,
which you can certainly use on this structure (try it!):
case class State[S, A](f: S => (S, A)) {
// Exercise 1
def map[B](k: A => B): State[S, B] = error("todo")
// Exercise 2
def flatMap[B](k: A => State[S, B]): State[S, B] = error("todo")
def run(s: S) = f(s)._2
def exec(s: S) = f(s)._1
// more useful stuff
}
object State {
def unit[S, A](a: => A): State[S, A] = error("todo")
}
Re: functional/immutable programming question
All we need now is a follow-up email with the answers in place, and *an explanation as to why they're the correct answers*.
It's the explanation, one that doesn't presume Haskell exposure, that's so hard to find online... --
Kevin Wright
mail / gtalk / msn : kev [dot] lee [dot] wright [at] gmail [dot] com
pulse / skype: kev.lee.wright
twitter: @thecoda
Re: functional/immutable programming question
Hash: SHA1
On 17/11/10 19:35, Kevin Wright wrote:
>
>
> I refer back to, and propose as an exercise, the following. The
> haskell-monad-do-notation corresponds to Scala's
> for-comprehensions, which you can certainly use on this structure
> (try it!):
>
> case class State[S, A](f: S => (S, A)) { // Exercise 1 def
> map[B](k: A => B): State[S, B] = error("todo")
>
> // Exercise 2 def flatMap[B](k: A => State[S, B]): State[S, B] =
> error("todo")
>
> def run(s: S) = f(s)._2
>
> def exec(s: S) = f(s)._1
>
> // more useful stuff }
>
> object State { def unit[S, A](a: => A): State[S, A] = error("todo")
> }
>
>
> All we need now is a follow-up email with the answers in place, and
> *an explanation as to why they're the correct answers*.
>
> It's the explanation, one that doesn't presume Haskell exposure,
> that's so hard to find online...
>
> -- Kevin Wright
>
> mail / gtalk / msn : kev [dot] lee [dot] wright [at] gmail [dot] com
> kev [dot] lee [dot] wright [at] gmail [dot] com (<mailto:kev [dot] lee [dot] wright [at] gmail [dot] com>) pulse / skype: kev.lee.wright
> twitter: @thecoda
>
If you can write the answers, such that the code compile0s
(type-checks) and satisfies the following four properties, then you
have the correct answers.
1) forall f a. unit(a) flatMap f === f(a)
2) forall s. s flatMap (unit(_)) === s
3) forall s f g. (s flatMap f) flatMap g === s flatMap (x => f(x)
flatMap g)
4) forall s f. s flatMap (x => unit(f(x)) === s map f
Haskell exposure is not going to help you either way.
Re: functional/immutable programming question
how would that look like? this kind of line would typically be executed by some interactive event coming e.g. from a GUI, a sensor, or a network client. so this world2 = is not your top-level main() but somewhere encoded in the reactions of your system.
Am 17.11.2010 um 00:15 schrieb Raoul Duke:
> On Tue, Nov 16, 2010 at 4:02 PM, Sciss wrote:
>> versus
>> val world2 = world1.copy( topology = world1.topology.copy( clients = world1.territory.clients + clnt ))
>
> would haskellian monad-related-do-notation help here?
Re: functional/immutable programming question
Hash: SHA1
I'm happy to help you learn why you are wrong, but I don't think the
list would be. We can just keep it offline.
On the other hand, I have to step in when there are people who have
expressed an interest in learning only to receive a misguided answer.
The list is for learning -- and registering objection to nonsense is
very important for beginners' learning who don't yet have a
comfortable understanding.
On 12/11/10 07:53, Sciss wrote:
> hello tony,
>
> i think we disagree here about the function and usage of a mailing
> list.
>
> - if you do not have time because you are too busy, you can avoid
> the kind of reply you sent - if you think the mistake(?) is very
> common, it is even more important to clarify it - if you have done
> it many times, why don't you just send a link to an older mailing
> list entry? apart from that, redundancy is a good thing. - in
> particular i think it is healthy to believe that different people
> do not occupy a different degree of truth, because truth ist not
> linear and absolute, but have different backgrounds and different
> viewpoints. a mailing list is a communication means to establish
> some kind of common sense (ideally) or consensus through
> discussion. so to terminate in saying that something is nonsense or
> that someone should stop writing "shit" is completely useless. - my
> point was that to view a process as a function comes with problems,
> in particular when the main concept, temporality, is implicit.
> there may be better ways to explicate temporality, although purely
> functional datastructures can be helpful here by simplifying
> reasoning at another instance. and as has been written, you need
> "impurity" to express the intrusion of the real world in terms of
> time-variant elements. the emphatic usage of the terms "purity" and
> "state" seems to reveal a transcendental aesthetic that is found
> in FP. i find it telling that terms such as "stateless" or
> "stateful" are used, where the state is exactly the frozen time,
> the moment inbetween change, where if you speak in terms of
> process, you would typically use the term "change" and
> "transition" and inversely the "states" become the holes between
> transitions. - as has been written in another reply, the actual
> problem was really one of concurrency, and i gave my opinion ==
> experience regarding this point, and i don't see where your
> comments add to this.
>
> you know i am generally a modest person, i don't believe i am god
> or on top of other people, and i thus have no problem in being
> incorrect in points or being corrected. but i am still not
> convinced that my text was not making sense.
>
> best, -sciss-
>
>
>
> Am 11.11.2010 um 21:19 schrieb Tony Morris:
>
> Alas, if I were to respond to every bit of nonsense on the
> internet, I'd be very busy indeed! Further, your particular
> misunderstanding is:
>
> a) Extremely common b) Extremely difficult (for me anyway) to
> demonstrate for a general audience. I have done so successfully
> many times, but only with full attention being given to the topic
> one-on-one.
>
> Instead of addressing nonsense of this particular magnitude, I
> request, in the most polite manner possible, the following: Stop
> talking shit. In response, I will go to extraordinary efforts to
> do same, nevertheless acknowledging both of our fallibility.
>
> Sound fair? If not, where do I begin unravelling your fallacious
> comments? It's an honest question -- despite your unawareness of
> falsehood, I simply don't know where to begin.
>
> Do you honestly believe that first sentence? Do you care to put a
> bit more thought into it? I'm don't intend to be a dick, just
> prevent the misguidance of others. Be nice to noobs -- you don't
> yet know how hard it is to help them out after they've been
> misguided by nonsense like this.
>
>
> On 12/11/10 07:09, Sciss wrote:
>>>> beware, your comments are a
> waste of time. if you want to help in
>
>
>>>> this thread, break down your superior knowledge in a way that
>>>> it
> is
>
>
>>>> shared with others, and explain why something is nonsense in
>>>> your
>
>
>>>> opinion.
>
>
>>>>
>
>
>>>> Am 11.11.2010 um 20:29 schrieb Tony Morris:
>
>
>>>>
>
>
>>>> On 11/11/10 22:30, Sciss wrote:
>
>
>>>>>>> fp and immutable data structures are celebrated as
> solving
>
>
>>>>>>> all problems, but as you see, they don't, in
> particular they
>
>
>>>>>>> have no clear concept of dynamicity, so things that
> change
>
>
>>>>>>> over time. they don't solve your problem of
> concurrent access
>
>
>>>>>>> here, so you will need to linearize your clients in
> some way.
>
>
>>>>>>> for example, you could manage them with an Actor or
> use an
>
>
>>>>>>> STM... immutable structures and STM play nicely
> together, as
>
>
>>>>>>> when a transaction is aborted you haven't crippled
> your data
>
>
>>>>>>> structure, just the newly created copy (old list
> plus new
>
>
>>>>>>> head element, for instance) isn't stored in the ref,
> no
>
>
>>>>>>> damage is done.
>
>
>>>>>>>
>
>
>>>>>>> best, -sciss-
>
>
>>>> Beware, nonsense lurks there.
>
>
>>>>
>
>
>>>>>
>
>
>>
Re: functional/immutable programming question
to quote altair from assassin's creed: "speak sense, or not at all".
what sciss said made sense to me. if he is wrong, please tell us why. just telling *that* he is won't make any of us smarter.
-------- Original-Nachricht --------
> Datum: Fri, 12 Nov 2010 07:56:53 +1000
> Von: Tony Morris
> An: Sciss
> CC: tmorris [at] tmorris [dot] net, scala-user [at] listes [dot] epfl [dot] ch
> Betreff: Re: [scala-user] functional/immutable programming question
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I'm happy to help you learn why you are wrong, but I don't think the
> list would be. We can just keep it offline.
>
> On the other hand, I have to step in when there are people who have
> expressed an interest in learning only to receive a misguided answer.
> The list is for learning -- and registering objection to nonsense is
> very important for beginners' learning who don't yet have a
> comfortable understanding.
>
>
> On 12/11/10 07:53, Sciss wrote:
> > hello tony,
> >
> > i think we disagree here about the function and usage of a mailing
> > list.
> >
> > - if you do not have time because you are too busy, you can avoid
> > the kind of reply you sent - if you think the mistake(?) is very
> > common, it is even more important to clarify it - if you have done
> > it many times, why don't you just send a link to an older mailing
> > list entry? apart from that, redundancy is a good thing. - in
> > particular i think it is healthy to believe that different people
> > do not occupy a different degree of truth, because truth ist not
> > linear and absolute, but have different backgrounds and different
> > viewpoints. a mailing list is a communication means to establish
> > some kind of common sense (ideally) or consensus through
> > discussion. so to terminate in saying that something is nonsense or
> > that someone should stop writing "shit" is completely useless. - my
> > point was that to view a process as a function comes with problems,
> > in particular when the main concept, temporality, is implicit.
> > there may be better ways to explicate temporality, although purely
> > functional datastructures can be helpful here by simplifying
> > reasoning at another instance. and as has been written, you need
> > "impurity" to express the intrusion of the real world in terms of
> > time-variant elements. the emphatic usage of the terms "purity" and
> > "state" seems to reveal a transcendental aesthetic that is found
> > in FP. i find it telling that terms such as "stateless" or
> > "stateful" are used, where the state is exactly the frozen time,
> > the moment inbetween change, where if you speak in terms of
> > process, you would typically use the term "change" and
> > "transition" and inversely the "states" become the holes between
> > transitions. - as has been written in another reply, the actual
> > problem was really one of concurrency, and i gave my opinion ==
> > experience regarding this point, and i don't see where your
> > comments add to this.
> >
> > you know i am generally a modest person, i don't believe i am god
> > or on top of other people, and i thus have no problem in being
> > incorrect in points or being corrected. but i am still not
> > convinced that my text was not making sense.
> >
> > best, -sciss-
> >
> >
> >
> > Am 11.11.2010 um 21:19 schrieb Tony Morris:
> >
> > Alas, if I were to respond to every bit of nonsense on the
> > internet, I'd be very busy indeed! Further, your particular
> > misunderstanding is:
> >
> > a) Extremely common b) Extremely difficult (for me anyway) to
> > demonstrate for a general audience. I have done so successfully
> > many times, but only with full attention being given to the topic
> > one-on-one.
> >
> > Instead of addressing nonsense of this particular magnitude, I
> > request, in the most polite manner possible, the following: Stop
> > talking shit. In response, I will go to extraordinary efforts to
> > do same, nevertheless acknowledging both of our fallibility.
> >
> > Sound fair? If not, where do I begin unravelling your fallacious
> > comments? It's an honest question -- despite your unawareness of
> > falsehood, I simply don't know where to begin.
> >
> > Do you honestly believe that first sentence? Do you care to put a
> > bit more thought into it? I'm don't intend to be a dick, just
> > prevent the misguidance of others. Be nice to noobs -- you don't
> > yet know how hard it is to help them out after they've been
> > misguided by nonsense like this.
> >
> >
> > On 12/11/10 07:09, Sciss wrote:
> >>>> beware, your comments are a
> > waste of time. if you want to help in
> >
> >
> >>>> this thread, break down your superior knowledge in a way that
> >>>> it
> > is
> >
> >
> >>>> shared with others, and explain why something is nonsense in
> >>>> your
> >
> >
> >>>> opinion.
> >
> >
> >>>>
> >
> >
> >>>> Am 11.11.2010 um 20:29 schrieb Tony Morris:
> >
> >
> >>>>
> >
> >
> >>>> On 11/11/10 22:30, Sciss wrote:
> >
> >
> >>>>>>> fp and immutable data structures are celebrated as
> > solving
> >
> >
> >>>>>>> all problems, but as you see, they don't, in
> > particular they
> >
> >
> >>>>>>> have no clear concept of dynamicity, so things that
> > change
> >
> >
> >>>>>>> over time. they don't solve your problem of
> > concurrent access
> >
> >
> >>>>>>> here, so you will need to linearize your clients in
> > some way.
> >
> >
> >>>>>>> for example, you could manage them with an Actor or
> > use an
> >
> >
> >>>>>>> STM... immutable structures and STM play nicely
> > together, as
> >
> >
> >>>>>>> when a transaction is aborted you haven't crippled
> > your data
> >
> >
> >>>>>>> structure, just the newly created copy (old list
> > plus new
> >
> >
> >>>>>>> head element, for instance) isn't stored in the ref,
> > no
> >
> >
> >>>>>>> damage is done.
> >
> >
> >>>>>>>
> >
> >
> >>>>>>> best, -sciss-
> >
> >
> >>>> Beware, nonsense lurks there.
> >
> >
> >>>>
> >
> >
> >>>>>
> >
> >
> >>
>
> - --
> Tony Morris
> http://tmorris.net/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkzcZqUACgkQmnpgrYe6r61r+wCfad2C19ipm5wHtoNz14Wr1pQD
> jNgAnAmBQJqxZMNnXG6538LlTohmBiNl
> =GPzV
> -----END PGP SIGNATURE-----
>
Re: functional/immutable programming question
On 11/11/10 21:19, Tony Morris wrote:
> I request, in the most polite manner possible, the following: Stop
> talking shit. In response, I will go to extraordinary efforts to do
> same, nevertheless acknowledging both of our fallibility.
On 11/11/10 21:56, Tony Morris wrote:
> I'm happy to help you learn why you are wrong, but I don't think the
> list would be. We can just keep it offline.
Speaking personally, this thread has been one of the potentially more
interesting ones, and I would be very interested to read your analysis of
Sciss's comments about FP. If you're going to be brash enough to say someone is
"talking shit" on a public list, rightly *or* wrongly, it only seems fair to
back it up with some pretty solid justifications, and/or apologise. On the
other hand, if you can't do either of those, for whatever reason, it is
unavoidably going to reflect badly on yourself.
N
Re: functional/immutable programming question
Thanks,Christoph
Am 11.11.2010 um 22:56 schrieb Tony Morris:
Re: functional/immutable programming question
On Fri, Nov 12, 2010 at 5:03 AM, Christoph Drießen wrote:
> As I really want to get a better understanding of FP and it's concepts I'm
> constantly searching for good resources to learn. I already worked through
> loads of articles, blog posts etc on various topics and although some of
> them are a really good reading it leaves me in the uncomfortable state of
> feeling unstructured. What I want is a good and decently organized book (or
> books). So my question to the list is if you have any recommendations
> regarding good literature about FP.
> Thanks,
> Christoph
By far the best book I've ever seen on structured design from an FP
point of view is How To Design Programs:
http://www.htdp.org/
Re: functional/immutable programming question
I find both former posts interesting.
Tony Morris wrote:
>
> I'm happy to help you learn why you are wrong, but I don't think the
> list would be. We can just keep it offline.
>
The question here is: Who is "the list"?
We have here some smart guys, who since a long time contribute to this list.
And OTOH we have newcomers with many questions.
And we have people to be positioned somewhere between this extremes,
e.g. some loyal people who follow the list since a long time
and know you, your position and your comments, and have already learned
some things but aren't already "there".
For these people the previous posts could possibly make some sense and
sound OK, but as you object to them, your reasons may be of worth for them
too,
not only the targeted poster.
Keeping your dialogue offline will presumably result in reincarnating this
thread as
a deja vu at some time in the future, without being able to link back to
this
discussion, as it ended in "nonsense" and more valuable stuff was kept
offline.
(Aren't we already in this position?)
Would be a pity.
Tony Morris wrote:
>
> On the other hand, I have to step in when there are people who have
> expressed an interest in learning only to receive a misguided answer.
> The list is for learning --
>
Absolutely right!
But as I presume that no one here intents to "talk shit", so a request like
"don't talk shit"
is educational nonsense (compare this to the good and bad way to tell
children
what they are doing wrong).
Tony Morris wrote:
>
> and registering objection to nonsense is
> very important for beginners' learning who don't yet have a
> comfortable understanding.
Absolutely right again!
But, see, if it burns it is in no way helpful to put up a sign saying
"Fire!" .
One has to extinguish (well, or run away).
KR
Det
Re: Re: functional/immutable programming question
+1
At risk of getting flak from both directions...
I think Sciss exaggerated when stating that fp solves "all" problems. Also when saying that functions have no clear concept of dynamicity, when all ballistics etc equations are just that: functions...of time... Which we know now to be discrete... and non-determinism can easily be added... With more functions
STM necessarily implies share memory... Etc
Immutables can "change" by growing into other immutables...and all Denis needs to solve his recurring problem is a "tick tack" ie a stream generating an infinite sequence of ticks, one per second say, and you map over that the next moves on the board...no fancy monadic beasts needed.
Tony is rightfuly pissed at our imprecision. I know that monads are just monoids in the category of endofunctors, but i am necessarily imprecise because I really do feel like an old man fondling elephants and I cant quite find the time to learn the beast in it's totality so I only perceive a few aspects of it...
Well, it was fun writing more imprecise opinions about what others wrote...time for flak!
Thanks,
Razvan
On 2010-11-12, at 5:53 AM, Det2 wrote:
>
> I find both former posts interesting.
>
>
> Tony Morris wrote:
>>
>> I'm happy to help you learn why you are wrong, but I don't think the
>> list would be. We can just keep it offline.
>>
>
> The question here is: Who is "the list"?
>
> We have here some smart guys, who since a long time contribute to this list.
> And OTOH we have newcomers with many questions.
> And we have people to be positioned somewhere between this extremes,
> e.g. some loyal people who follow the list since a long time
> and know you, your position and your comments, and have already learned
> some things but aren't already "there".
>
> For these people the previous posts could possibly make some sense and
> sound OK, but as you object to them, your reasons may be of worth for them
> too,
> not only the targeted poster.
>
> Keeping your dialogue offline will presumably result in reincarnating this
> thread as
> a deja vu at some time in the future, without being able to link back to
> this
> discussion, as it ended in "nonsense" and more valuable stuff was kept
> offline.
> (Aren't we already in this position?)
> Would be a pity.
>
>
> Tony Morris wrote:
>>
>> On the other hand, I have to step in when there are people who have
>> expressed an interest in learning only to receive a misguided answer.
>> The list is for learning --
>>
>
> Absolutely right!
> But as I presume that no one here intents to "talk shit", so a request like
> "don't talk shit"
> is educational nonsense (compare this to the good and bad way to tell
> children
> what they are doing wrong).
>
>
> Tony Morris wrote:
>>
>> and registering objection to nonsense is
>> very important for beginners' learning who don't yet have a
>> comfortable understanding.
>
> Absolutely right again!
> But, see, if it burns it is in no way helpful to put up a sign saying
> "Fire!" .
> One has to extinguish (well, or run away).
>
> KR
> Det
Re: Re: functional/immutable programming question
Immutables can "change" by growing into other immutables...and all Denis needs to solve his recurring problem is a "tick tack" ie a stream generating an infinite sequence of ticks, one per second say, and you map over that the next moves on the board...no fancy monadic beasts needed.
-> so simple and elegant. i am happy now.
-------- Original-Nachricht --------
> Datum: Fri, 12 Nov 2010 10:09:25 -0500
> Von: Razvan Cojocaru
> An: Det2
> CC: "scala-user [at] listes [dot] epfl [dot] ch"
> Betreff: Re: [scala-user] Re: functional/immutable programming question
> +1
>
> At risk of getting flak from both directions...
>
> I think Sciss exaggerated when stating that fp solves "all" problems. Also
> when saying that functions have no clear concept of dynamicity, when all
> ballistics etc equations are just that: functions...of time... Which we know
> now to be discrete... and non-determinism can easily be added... With more
> functions
>
> STM necessarily implies share memory... Etc
>
> Immutables can "change" by growing into other immutables...and all Denis
> needs to solve his recurring problem is a "tick tack" ie a stream generating
> an infinite sequence of ticks, one per second say, and you map over that
> the next moves on the board...no fancy monadic beasts needed.
>
> Tony is rightfuly pissed at our imprecision. I know that monads are just
> monoids in the category of endofunctors, but i am necessarily imprecise
> because I really do feel like an old man fondling elephants and I cant quite
> find the time to learn the beast in it's totality so I only perceive a few
> aspects of it...
>
> Well, it was fun writing more imprecise opinions about what others
> wrote...time for flak!
>
> Thanks,
> Razvan
>
> On 2010-11-12, at 5:53 AM, Det2 wrote:
>
> >
> > I find both former posts interesting.
> >
> >
> > Tony Morris wrote:
> >>
> >> I'm happy to help you learn why you are wrong, but I don't think the
> >> list would be. We can just keep it offline.
> >>
> >
> > The question here is: Who is "the list"?
> >
> > We have here some smart guys, who since a long time contribute to this
> list.
> > And OTOH we have newcomers with many questions.
> > And we have people to be positioned somewhere between this extremes,
> > e.g. some loyal people who follow the list since a long time
> > and know you, your position and your comments, and have already learned
> > some things but aren't already "there".
> >
> > For these people the previous posts could possibly make some sense and
> > sound OK, but as you object to them, your reasons may be of worth for
> them
> > too,
> > not only the targeted poster.
> >
> > Keeping your dialogue offline will presumably result in reincarnating
> this
> > thread as
> > a deja vu at some time in the future, without being able to link back to
> > this
> > discussion, as it ended in "nonsense" and more valuable stuff was kept
> > offline.
> > (Aren't we already in this position?)
> > Would be a pity.
> >
> >
> > Tony Morris wrote:
> >>
> >> On the other hand, I have to step in when there are people who have
> >> expressed an interest in learning only to receive a misguided answer.
> >> The list is for learning --
> >>
> >
> > Absolutely right!
> > But as I presume that no one here intents to "talk shit", so a request
> like
> > "don't talk shit"
> > is educational nonsense (compare this to the good and bad way to tell
> > children
> > what they are doing wrong).
> >
> >
> > Tony Morris wrote:
> >>
> >> and registering objection to nonsense is
> >> very important for beginners' learning who don't yet have a
> >> comfortable understanding.
> >
> > Absolutely right again!
> > But, see, if it burns it is in no way helpful to put up a sign saying
> > "Fire!" .
> > One has to extinguish (well, or run away).
> >
> > 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
> and all Denis needs to solve his recurring problem is a "tick tack" ie a stream generating an infinite sequence of ticks
at the risk of also being accused of not really contributing to this discussion :-)
in 2005 John Hughes wrote a paper on how to use arrows to deal with
situations like this (and also to deal with feedback (hardware circuits design))
http://www.cse.chalmers.se/~rjmh/afp-arrows.pdf
so, yes, imho finding the right abstraction to attack problems does matter
[ monads are not abstract enough (not every arrow is a function A => M[B]) where M is a monad ]
Luc
On Fri, Nov 12, 2010 at 4:18 PM, Dennis Haupt <h-star [at] gmx [dot] de> wrote:
--
__~O
-\ <,
(*)/ (*)
reality goes far beyond imagination
Re: functional/immutable programming question
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
Re: Re: functional/immutable programming question
I guess what got some of us off track is that the original post asked
about "pure functional programming"...
Re: Re: functional/immutable programming question
So asking about immutability isn't necessarily a question about FP. FP theory goes a *long* way beyond that starting point...
On 16 November 2010 11:07, Robert Wills <wrwills [at] gmail [dot] com> 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
Det2 wrote:
> enventually followed by someone coming up with an academic paper involving
> TheOtherFPLanguage: Haskell.
I guess Haskell is brought up not because it is "the other FP language"
(there are (OCA)ML / F#, Lisp / Scheme, Erlang, too, mind you..) but
because it is the probably best known pure[1] language and the
discussion at that point was about purity.
If you want to avoid side-effects in Scala, in my understanding (I am
just a learner, too), one has to do it by convention (which seems
meaningless when you use Java libraries). There is no way to guarantee
it (in Scala), although as far as I am aware, there is research on this
topic going on currently. So what I am in fact doing is learning the
pure FP way by learning Haskell[2][3] (and some category theory [4])
thoroughly and then see how much of that I can apply to Scala and the
JVM. This seems like a lot of work lies in front of me.
If anybody knows a shortcut, I'd be delighted to hear about it. I'd
also be delighted about any book recommendations.
Kind regards
Andreas
[1]
http://haskell.org/haskellwiki/Comparison_of_functional_programming_lang...
[2] Real world Haskell (ISBN 978-0596514983)
[3] Pearls of functional algorithm design (ISBN 978-0521513388)
[4] Conceptual Mathematics: A First Introduction to Categories (ISBN
978-0521719162)
P.S.
I'd prefer if the discussion about these topics were less heated and
more open-minded and with more actual references than bold claims.
Re: Re: functional/immutable programming question
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 <Dirk [dot] Detering [at] bitmarck [dot] de> 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
On 16/11/10 19:46, 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.
Bollocks! I've written every single of those in Scala at least once.
Re: functional/immutable programming question
Tony Morris wrote:
>
> Bollocks! [...]
>
Impressing. For me as a non-native english speaker you even act as a living
synonym dictionary, teaching me always new words for the concept of
"nonsense" :-) .
Re: Re: functional/immutable programming question
Look no further:http://james-iry.blogspot.com/2009/05/brief-incomplete-and-mostly-wrong.html
http://james-iry.blogspot.com/2007/09/monads-are-elephants-part-1.htmlhttp://james-iry.blogspot.com/2007/10/monads-are-elephants-part-2.html http://james-iry.blogspot.com/2007/10/monads-are-elephants-part-3.html http://james-iry.blogspot.com/2007/11/monads-are-elephants-part-4.html
Thanks again James!
On 17 November 2010 09:26, Det2 <Dirk [dot] Detering [at] bitmarck [dot] de> 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
> "a monad is a monoid in the category of endofunctors"
I have seen this statement several times already in emails to this group
(often as a kind of joke (to make programmers afraid of monads(?)))
I also looked at the origin in James blog posts:
Wadler tries to appease critics by explaining that
"a monad is a monoid in the category of endofunctors, what's the problem?"
clearly also also a joke
I just wanted to say that this statement is not true.
The composition of monads is not necessarily a monad.
Philip Wadler wrote a paper "Combining Monads" in 1992 (with David King)
One year later, 1993, I wrote a paper (with Mark P. Jones)
http://web.cecs.pdx.edu/~mpj/pubs/composing.html
showing a counter example
see section 6.4.2. for the following (somewhat contrived counter) example
where I show that (as far as monad laws are concerned)
composing with the List monad is problematic
? (prod . map (join . map prod)) [[[[[1],[3]]]],[[[[4]]],[[[2]]]]]
[[1, 4], [1, 2], [3, 4], [3, 2]]
? (join . map prod . prod) [[[[[1],[3]]]],[[[[4]]],[[[2]]]]]
[[1, 4], [3, 4], [1, 2], [3, 2]]
see http://www.cwru.edu/artsci/math/wells/pub/ttt.html (1983)
for the monad composition laws above
not that it all matters to much :-)
--
__~O
-\ <,
(*)/ (*)
reality goes far beyond imagination
Re: Re: functional/immutable programming question
I never denied that you can use 'em in Scala, just stated that it's hard to find good tutorials for someone with absolutely no prior experience...
On 16 Nov 2010 22:20, "Tony Morris" <tonymorris [at] gmail [dot] com> wrote:> On 16/11/10 19:46, 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.
> Bollocks! I've written every single of those in Scala at least once.
>
>
> --
> Tony Morris
> http://tmorris.net/
>
>
RE: Re: functional/immutable programming question
> Date: Wed, 17 Nov 2010 08:20:20 +1000
> From: tonymorris [at] gmail [dot] com
>
> > 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.
>> Bollocks! I've written every single of those in Scala at least once.
>
> --
> Tony Morris