Forum: Ruby Re: Very interesting paper about future programming models

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Michael N. (Guest)
on 2007-02-12 13:27
(Received via mailing list)
Benjohn B. wrote:

>
> Having not even read the piece...
>
> I was following up on Software Transactional Memory from an earlier
> Ruby T. posting, and that looks extremely promising.

Have you read this thread on Software Transactional Memory?

http://patricklogan.blogspot.com/2007/02/misguided...

It's about the downsides of STM.

Regards,

  Michael
unknown (Guest)
on 2007-02-14 16:29
(Received via mailing list)
>>
>
> It's about the downsides of STM.

Fantastic! :) I'd like something to temper my enthusiasm.
unknown (Guest)
on 2007-02-14 17:56
(Received via mailing list)
> Have you read this thread on Software Transactional Memory?
>
> http://patricklogan.blogspot.com/2007/02/misguided...

Well, I've had a browse, and it mostly seems to be a rant on the style
of, 'I don't like it, it sounds dangerous, ooooo, it's horrible, look at
it! These other people don't like it either!', without (that I've found
yet) a clear statement of why.

The main objection seems to be that software will end up being a mess of
shared state that many process are franstically writing too, but that
just seems like really bad design to me. Asynchronus message queues, it
suggests, are a better option.

I get the feel that there is a "holy war" between a functional approach,
and an imperitive approach here, somewhere. I'll need to read it more
closely, because that sounds interesting. I don't yet see why STM
shouldn't be highly functional though (I personally like functional a
lot).

Cheers,
  Benjohn
This topic is locked and can not be replied to.