Comments on: Responses to The Problem with STM http://enfranchisedmind.com/blog/posts/responses-to-the-problem-with-stm/ programming, politics, & other religious issues Wed, 08 Feb 2012 14:16:00 +0000 hourly 1 By: Rick Minerich's Development Wonderland : Discoveries This Week 01/16/2009 http://enfranchisedmind.com/blog/posts/responses-to-the-problem-with-stm/#comment-34066 Rick Minerich's Development Wonderland : Discoveries This Week 01/16/2009 Fri, 16 Jan 2009 16:28:53 +0000 http://enfranchisedmind.com/blog/?p=933#comment-34066 [...] the high cost of STM is much less of an issue.  Brian then further flushes out his ideas in a follow up blog in which he responds to responses to his [...] [...] the high cost of STM is much less of an issue.  Brian then further flushes out his ideas in a follow up blog in which he responds to responses to his [...]

]]> By: Stephan http://enfranchisedmind.com/blog/posts/responses-to-the-problem-with-stm/#comment-34027 Stephan Tue, 13 Jan 2009 03:08:42 +0000 http://enfranchisedmind.com/blog/?p=933#comment-34027 Nice article. Especially since I already loved the first one. Just a quick note, in the haskell code for locks makeLock should have type STM Lock or should be wrapped in atomically. Same with putLock. I also believe concrete types have to start with uppercase letters so it should be 'type Lock = TVar Bool'. Of course this only adds noise and is totally besides the point of the blog post, so feel free to ignore me. @ Raoul: Would you mind giving a pointer at where to find a message passing implementation for haskell? Note that I really don't have clue about message passing so if it's just the stuff in Control.Parallel then I'm happy to go back and do my homework so I can recognize it as such. Nice article. Especially since I already loved the first one.
Just a quick note, in the haskell code for locks makeLock should have type STM Lock
or should be wrapped in atomically. Same with putLock. I also believe concrete types have to start with uppercase letters so it should be ‘type Lock = TVar Bool’.
Of course this only adds noise and is totally besides the point of the blog post, so feel
free to ignore me.
@ Raoul: Would you mind giving a pointer at where to find a message passing
implementation for haskell? Note that I really don’t have clue about message passing so
if it’s just the stuff in Control.Parallel then I’m happy to go back and do my homework
so I can recognize it as such.

]]> By: Raoul Duke http://enfranchisedmind.com/blog/posts/responses-to-the-problem-with-stm/#comment-34026 Raoul Duke Mon, 12 Jan 2009 23:40:49 +0000 http://enfranchisedmind.com/blog/?p=933#comment-34026 thanks for your continuing thoughts on these issues, since they are obviously important, and i wanna learn more. i'd like to note that haskell not only has stm, it also has lightweight processes with message passing. it surprised me when i found that out, since i figured erlang was really the only thing with really good lwp + messaging features. man, haskell seems cool. of course, i haven't myself gotten fully into the grok of monads yet, so i'm still just a haskell wannabe l00zer. grn. thanks for your continuing thoughts on these issues, since they are obviously important, and i wanna learn more.

i’d like to note that haskell not only has stm, it also has lightweight processes with message passing. it surprised me when i found that out, since i figured erlang was really the only thing with really good lwp + messaging features. man, haskell seems cool.

of course, i haven’t myself gotten fully into the grok of monads yet, so i’m still just a haskell wannabe l00zer. grn.

]]> By: Peter http://enfranchisedmind.com/blog/posts/responses-to-the-problem-with-stm/#comment-34024 Peter Mon, 12 Jan 2009 04:59:38 +0000 http://enfranchisedmind.com/blog/?p=933#comment-34024 I would like to hear your thoughts on Objective-C 2.0 with regards to this article. In particular I see three things worth commenting on: (1) The immutable objects in Objective-C are much more robust in terms of accidental mutation. This is because you operate on them with messages and the collections are class clusters which restricts the safe assumptions you can make about their internal design. Do you feel this makes any significant progress away from C\C++ and towards Haskell? (2) Objective-C uses messaging and so hypothetically could work with your scenario of a program using message passing and STM at the same time. You say "share-nothing message passing" and while afaik Objective-C cannot enforce this you could certainly write a program that did not share much data between threads. (3) Objective-C 2.0 introduces @properties which go a long way towards simplifying programmer usage of locks. I am not very interested in commentary on the new Cocoa classes for parallel programming or OpenCL, but I will certainly read your thoughts on those topics if you choose to share them. I am more curious how you would evaluate Objective-C for future parallel programming work. You have made your thoughts on C\C++ and Haskell very clear, but I see Objective-C as something of a grey area. My suspicion is that you will find it an inadequate language, but I am unsure enough that I want to ask. I would like to hear your thoughts on Objective-C 2.0 with regards to this article.

In particular I see three things worth commenting on:

(1) The immutable objects in Objective-C are much more robust in terms of accidental mutation. This is because you operate on them with messages and the collections are class clusters which restricts the safe assumptions you can make about their internal design. Do you feel this makes any significant progress away from C\C++ and towards Haskell?

(2) Objective-C uses messaging and so hypothetically could work with your scenario of a program using message passing and STM at the same time. You say “share-nothing message passing” and while afaik Objective-C cannot enforce this you could certainly write a program that did not share much data between threads.

(3) Objective-C 2.0 introduces @properties which go a long way towards simplifying programmer usage of locks.

I am not very interested in commentary on the new Cocoa classes for parallel programming or OpenCL, but I will certainly read your thoughts on those topics if you choose to share them. I am more curious how you would evaluate Objective-C for future parallel programming work. You have made your thoughts on C\C++ and Haskell very clear, but I see Objective-C as something of a grey area. My suspicion is that you will find it an inadequate language, but I am unsure enough that I want to ask.

]]> By: Brian http://enfranchisedmind.com/blog/posts/responses-to-the-problem-with-stm/#comment-34021 Brian Sun, 11 Jan 2009 16:27:52 +0000 http://enfranchisedmind.com/blog/?p=933#comment-34021 Fixed. Thanks. Fixed. Thanks.

]]>