<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Tanenbaum on Shared Data Structures</title>
	<atom:link href="http://digital-sushi.org/entry/tanenbaum-on-shared-data-structures/feed/" rel="self" type="application/rss+xml" />
	<link>http://digital-sushi.org/entry/tanenbaum-on-shared-data-structures/</link>
	<description>Thoughts on language design, API design, compilers, Smalltalk, and Java technology</description>
	<pubDate>Sun, 05 Feb 2012 10:56:57 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.5</generator>
		<item>
		<title>By: Simon Kissane</title>
		<link>http://digital-sushi.org/entry/tanenbaum-on-shared-data-structures/#comment-1156</link>
		<dc:creator>Simon Kissane</dc:creator>
		<pubDate>Sat, 02 Feb 2008 05:49:01 +0000</pubDate>
		<guid isPermaLink="false">http://digital-sushi.org/entry/tanenbaum-on-shared-data-structures/#comment-1156</guid>
		<description>I think today we have a major problem with shared data structures -- we have many mechanisms to manage concurrency, but they are all too hard for the poor human brain which has to use them. But a lot of research is being done on transactional memory (whether that be software transactional memory, or hardware-assisted transactional memory, or some hybrid variety). And I think, once transactional memory becomes mainstream, we'll see a return to popularity for shared data structures, because once you have the concurrency issues solved they really are easier to program to than message-passing interfaces.

I also think that, even when forced to use a message-passing based interface, it should be made to look like a shared data structure (ala properties in .Net), rather than having the programmer explicitly use a method-oriented approach. I think this is good, both because its easier to think in terms of direct manipulation of data structures than message passing or method calls, and it encapsulates away the issue of whether message passing or method calls are actually used as the implementation mechanism, meaning that once transactional memory becomes mainstream we can all switch from a message passing based implementation to a shared data structures one.

A final point -- the other argument for non-shared data structures is that encapsulation is useful for access control. I agree, but there are better ways to do access control than using method calls -- the problem is that most current programming languages have only a very limited set of access levels (public v. private v. restricted), and lack declarative constraints on data structures. If they resolved those issues, I don't think encapsulation would ever really be necessary.</description>
		<content:encoded><![CDATA[<p>I think today we have a major problem with shared data structures &#8212; we have many mechanisms to manage concurrency, but they are all too hard for the poor human brain which has to use them. But a lot of research is being done on transactional memory (whether that be software transactional memory, or hardware-assisted transactional memory, or some hybrid variety). And I think, once transactional memory becomes mainstream, we&#8217;ll see a return to popularity for shared data structures, because once you have the concurrency issues solved they really are easier to program to than message-passing interfaces.</p>
<p>I also think that, even when forced to use a message-passing based interface, it should be made to look like a shared data structure (ala properties in .Net), rather than having the programmer explicitly use a method-oriented approach. I think this is good, both because its easier to think in terms of direct manipulation of data structures than message passing or method calls, and it encapsulates away the issue of whether message passing or method calls are actually used as the implementation mechanism, meaning that once transactional memory becomes mainstream we can all switch from a message passing based implementation to a shared data structures one.</p>
<p>A final point &#8212; the other argument for non-shared data structures is that encapsulation is useful for access control. I agree, but there are better ways to do access control than using method calls &#8212; the problem is that most current programming languages have only a very limited set of access levels (public v. private v. restricted), and lack declarative constraints on data structures. If they resolved those issues, I don&#8217;t think encapsulation would ever really be necessary.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Damon Hart-Davis</title>
		<link>http://digital-sushi.org/entry/tanenbaum-on-shared-data-structures/#comment-1147</link>
		<dc:creator>Damon Hart-Davis</dc:creator>
		<pubDate>Thu, 31 Jan 2008 21:55:07 +0000</pubDate>
		<guid isPermaLink="false">http://digital-sushi.org/entry/tanenbaum-on-shared-data-structures/#comment-1147</guid>
		<description>Yes, agreed with that point.  Better decoupling enhances safety, potential concurrency, etc, etc.

Rgds

Damon</description>
		<content:encoded><![CDATA[<p>Yes, agreed with that point.  Better decoupling enhances safety, potential concurrency, etc, etc.</p>
<p>Rgds</p>
<p>Damon</p>
]]></content:encoded>
	</item>
</channel>
</rss>

