The Artima Developer Community
Sponsored Link

Java Community News
Threads Considered Harmful

42 replies on 3 pages. Most recent reply: Feb 1, 2007 6:00 AM by James Watson

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 42 replies on 3 pages [ « | 1 2 3 | » ]
Gregor Zeitlinger

Posts: 108
Nickname: gregor
Registered: Aug, 2005

Re: Idempotent operations Posted: Jan 25, 2007 4:48 PM
Reply to this message Reply
Advertisement
> Const would seem to be fairly simple to check but
> idempotence would seem a little more difficult to verify.
Isn't an idempotent method the same as a const method where all parameters are const? That would be easy to verify.
Or is there an additional requirement that the method doesn't perform IO?

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Idempotent operations Posted: Jan 25, 2007 5:47 PM
Reply to this message Reply
> > Const would seem to be fairly simple to check but
> > idempotence would seem a little more difficult to
> verify.
> Isn't an idempotent method the same as a const method
> where all parameters are const? That would be easy to
> verify.
> Or is there an additional requirement that the method
> doesn't perform IO?

Does checking system clock count as IO? In any event, IO is the thing that I was thinking makes idempotence hard to verify. If you rule that out, your statement seems right, intuitively. But then again, I could get a Singleton instance in and use something from using const methods that depend on state that is not constant. We could add "only uses const methods".

I just had a thought. A const method can't do any lazy-loading, right? That would mean a const method couldn't call anything that used lazy-loading. Not that this has anything to do with the discussion.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Threads Considered Harmful Posted: Jan 25, 2007 8:19 PM
Reply to this message Reply
Frank Silbermann wrote Just imagine the horrors of trying to build a CRUD database program with a GUI interface in a language that had no concept of mutable state!

I'm imagining but I don't seem to see the horrors :-)

Maybe it depends on what you imagine about the programming languages or what you mean about having no concept of mutable state (what language would provide an exemplar of having no concept of mutable state?)


"Mnesia is a multiuser Distributed DBMS specially made for industrial telecommunications applications written in the symbolic programming language Erlang..."

http://www.erlang.org/doc/doc-5.0.1/lib/mnesia-3.9.2/doc/html/part_frame.html

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Another approach is events. Posted: Jan 26, 2007 2:57 AM
Reply to this message Reply
Another approach to multithreading is an event-driven architecture: each computation creates another computation which is passed to a multiplexer routine which executes pending computations in parallel depending on their 'color':

http://pdos.csail.mit.edu/6.824-2001/projects/paper-7.ps

Although such an architecture can be easily embedded in Java, a better approach would be a new programming language so as that computations become transparent.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Threads Considered Harmful Posted: Jan 26, 2007 7:01 AM
Reply to this message Reply
> Frank Silbermann wrote Just imagine the horrors of
> trying to build a CRUD database program with a GUI
> interface in a language that had no concept of mutable
> state!

>
> I'm imagining but I don't seem to see the horrors :-)
>
> Maybe it depends on what you imagine about the
> programming languages or what you mean about having no
> concept of mutable state (what language would provide an
> exemplar of having no concept of mutable state?)

I'm not sure why you would represent this as being some sort of crazy idea:

"Functional programming is a programming paradigm that conceives computation as the evaluation of mathematical functions and avoids state and mutable data."

http://en.wikipedia.org/wiki/Functional_programming

It's clearly one of the commonly held tenets of the concept of functional programming. From what I understand, this is unworkable in a wide array of programs, so the monads or other ways to have a mutable state are introduced.

It seems to me that if you introduce state, the idea that functional programming can be used to seamlessly distribute work across threads becomes pretty questionable. If I'm looping over a set of items and write them to a file in order, forking this action would cause incorrect behavior and if it were somehow made to write in order, it would require that threads work in tandem making multi-threading pointless.

To me, this idea that state is some sort of inconvenience that can be cornered and bludgeoned to death represents wishful thinking. State is what makes most business applications interesting and useful.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Threads Considered Harmful Posted: Jan 26, 2007 10:13 AM
Reply to this message Reply
James Watson wrote I'm not sure why you would represent this as being some sort of crazy idea.
I'm not sure why you would represent what I wrote as though I was saying Frank Silbermann's comments were a crazy idea.

James Watson wrote It's clearly one of the commonly held tenets ...
James, I provided an example of "a multiuser Distributed DBMS" written in what is generally regarded as a functional programming language.

Please provide some example programming language that corresponds to your notion of a functional programming language.

I think it's possible that your notion of functional programming and Frank Silbermann's notion of functional programmming don't correspond to any language used by the functional programming community.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Threads Considered Harmful Posted: Jan 26, 2007 11:07 AM
Reply to this message Reply
> James Watson wrote I'm not sure why you would represent
> this as being some sort of crazy idea.

> I'm not sure why you would represent what I wrote as
> though I was saying Frank Silbermann's comments were a
> crazy idea.

You suggested it was his imagination. I don't know if you intention is to quibble over words or not but it was clear to me that you were dismissing his statement as unfounded.

> James Watson wrote It's clearly one of the commonly
> held tenets ...

> James, I provided an example of "a multiuser Distributed
> DBMS" written in what is generally regarded as a
> functional programming language.

I don't have any idea how this is supposed to respond to what I wrote. It's just one of your drive-by arguments by proxy. Do you disagree with the quote I posted or not? It's just a wikipedia page. Maybe the authors don't know what they are talking about. I don't know. You are presenting yourself as an expert on this, so tell us something useful.

You've made the point that this DBMS exists. That says nothing about the relative difficulty in developing it which is what the original point was about.

> Please provide some example programming language that
> corresponds to your notion of a functional programming
> language.

Haskell.

> I think it's possible that your notion of functional
> programming and Frank Silbermann's notion of functional
> programmming don't correspond to any language used by the
> functional programming community.

So are you saying that the functional programming thinks there is no problem with mutable state and that mutable state is irrelevant in the kinds of multi-threading optimizations that are relevant to this discussion?

In short, this (decidedly pro-functional programming) webpage( http://www.prairienet.org/~dsb/monads.htm ) is representative of my understanding of how state affects functional programming specifically:

"Output functions, on the other hand, have an effect on the outside world, which is independent of the function's return value. These "impure" actions make it much harder for a compiler to optimize the program."

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: Idempotent operations Posted: Jan 26, 2007 11:55 AM
Reply to this message Reply
> > Const would seem to be fairly simple to check but
> > idempotence would seem a little more difficult to
> verify.
> Isn't an idempotent method the same as a const method
> where all parameters are const? That would be easy to
> verify.
> Or is there an additional requirement that the method
> doesn't perform IO?

In a strict interpretation of idempotence a function should always return the same result for the same parameters, and it should have no side effects. So, IMHO, a idempotent function cannot perform any I/O.

It's a little fuzzy when it comes to methods of mutable objects. Does a method always have to return the same value when invoked on the same object, or does it always have to return the same value when invoked on an object is the same state. Furthermore, is the object's state just the object, or the entire object graph reachable from the object? I would argue it has to be the entire graph.

So C++ const does not enforce idempotence. But that doesn't mean it isn't useful. I'd like to see it in Java.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Idempotent operations Posted: Jan 26, 2007 2:04 PM
Reply to this message Reply
> > > Const would seem to be fairly simple to check but
> > > idempotence would seem a little more difficult to
> > verify.
> > Isn't an idempotent method the same as a const method
> > where all parameters are const? That would be easy to
> > verify.
> > Or is there an additional requirement that the method
> > doesn't perform IO?
>
> In a strict interpretation of idempotence a function
> should always return the same result for the same
> parameters, and it should have no side effects. So, IMHO,
> a idempotent function cannot perform any I/O.

It seems that you are saying idempotence implies const? Is that a fair assessment?

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: Idempotent operations Posted: Jan 26, 2007 2:06 PM
Reply to this message Reply
> It seems that you are saying idempotence implies const?
> Is that a fair assessment?

Yes. The restrictions implied by const are a subset of the one for idempotence.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Threads Considered Harmful Posted: Jan 26, 2007 6:20 PM
Reply to this message Reply
James Watson wrote: You suggested it was his imagination.

Frank Silbermann wrote Just imagine the horrors ...
I echoed the phrase he used.


James Watson wrote: it was clear to me that you were dismissing his statement as unfounded

That's a good point - let's look back at Frank Silbermann's comment
Just imagine the horrors of trying to build a CRUD database program with a GUI interface in a language that had no concept of mutable state!

I think we're simply being asked to imagine and speculate. I don't think any evidence or data was presented as foundation for those imaginings. Do you?


James Watson wrote: You've made the point that this DBMS exists. That says nothing about the relative difficulty in developing it which is what the original point was about.

Given such over-wrought imaginings, we might have imagined the task beyond possibility.


James Watson wrote: this... webpage ... is representative of my understanding of how state affects functional programming

And in the next paragraph, directly following 'These "impure" actions make it much harder for a compiler to optimize the program.' we read '... This allows all pure, non-monadic code to be optimized fully.'

And in the summary we read 'A monad function processes the data inside one or more monads, passing the bare data to pure functions as needed. This keeps pure and impure processes cleanly separated.'


It doesn't seem to mention any horrors at all?!

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Threads Considered Harmful Posted: Jan 26, 2007 7:32 PM
Reply to this message Reply
> It doesn't seem to mention any horrors at all?!

I never said there were any horrors. It seems like you have to run around the block to get next door to deal with state in functional languages but I don't think it's horrible.

Ramzi BEN YAHIA

Posts: 5
Nickname: rby
Registered: Apr, 2004

Re: Threads Considered Harmful Posted: Jan 27, 2007 10:37 AM
Reply to this message Reply
> > It doesn't seem to mention any horrors at all?!
>
> I never said there were any horrors. It seems like you
> have to run around the block to get next door to deal with
> state in functional languages but I don't think it's
> horrible.

I agree, however I think it's only the "unlearning process" that makes someone run around the block. Actually, I've seen some examples in "The Haskell School of Expression" where Monads really make sense and where writing successive statements like in imperative programming isn't appropriate(overloading the (>>) function in Monads is like overloding the meaning of a semicolon in java).

IMO, the main benefice of the FP way of handling state is the limitation it puts around(you can surely have a state but you have to go this way), unlike other programming styles, state is not spread everywhere so it's not really a nightmare when you want to verify thread safety.

In erlang for example, state is just the argument you give to a loop run by some process.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Threads Considered Harmful Posted: Jan 27, 2007 11:11 AM
Reply to this message Reply
James Watson wrote I never said there were any horrors. It seems like you have to run around the block to get next door to deal with state in functional languages but I don't think it's horrible.

LOL!

So why have you been making a fuss about my objection to Frank Silbermann's throwaway "Just imagine the horrors..." comment?

Roland Pibinger

Posts: 93
Nickname: rp123
Registered: Jan, 2006

Re: Threads Considered Harmful Posted: Jan 28, 2007 3:12 AM
Reply to this message Reply
The code above seems to be syntactically wrong, e.g. you probably mean something like:
class ForEach<T> implements Function<T> 

This approach greatly obfuscates the for-loop by implementing a variant of the command pattern but isn't more 'functional' than the original for-loop.

Flat View: This topic has 42 replies on 3 pages [ « | 1  2  3 | » ]
Topic: Firebug Creator Joe Hewitt's Yahoo YUI Video Previous Topic   Next Topic Topic: Neal Gafter on a Definition of Closures

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use