<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>/var/log/tumbles &#187; scala</title>
	<atom:link href="http://tumblelog.dhananjaynene.com/tag/scala/feed/" rel="self" type="application/rss+xml" />
	<link>http://tumblelog.dhananjaynene.com</link>
	<description>Interesting gatherings from the web</description>
	<lastBuildDate>Mon, 13 Apr 2009 09:15:26 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.4</generator>
		<item>
		<title>Objects as Actors : Should distribution transparency be embedded into a language design ?</title>
		<link>http://tumblelog.dhananjaynene.com/2009/04/objects-as-actors-should-distribution-transparency-be-embedded-into-a-language-design/</link>
		<comments>http://tumblelog.dhananjaynene.com/2009/04/objects-as-actors-should-distribution-transparency-be-embedded-into-a-language-design/#comments</comments>
		<pubDate>Mon, 13 Apr 2009 09:15:26 +0000</pubDate>
		<dc:creator>Dhananjay Nene</dc:creator>
				<category><![CDATA[Interesting]]></category>
		<category><![CDATA[clojure]]></category>
		<category><![CDATA[erlang]]></category>
		<category><![CDATA[langauge design]]></category>
		<category><![CDATA[scala]]></category>

		<guid isPermaLink="false">http://tumblelog.dhananjaynene.com/?p=166</guid>
		<description><![CDATA[Debasish Ghosh has written an interesting post : Objects as Actors. A very nice post touching upon the frequent debate of what abstraction should be included a piece of software and how should it be modeled. Even though readers and users often express their own views and experiences, it often boils down to the intent [...]]]></description>
			<content:encoded><![CDATA[<p>Debasish Ghosh has written an interesting post : <a href="http://debasishg.blogspot.com/2009/04/objects-as-actors.html">Objects as Actors</a>. A very nice post touching upon the frequent debate of what abstraction should be included a piece of software and how should it be modeled. Even though readers and users often express their own views and experiences, it often boils down to the intent of the author and the specific problems he chose to address.</p>
<p>Debasish refers to the point that in Scala Actors are implemented as a library even as Objects continue to be one of the building blocks of the language.</p>
<blockquote><p>The way I look at it, this is mostly a decision of the philosophy of the language design. Scala is targetted to be a general purpose programming language, where concurrency and distribution are not the central concerns to address as part of the core language design.</p></blockquote>
<p>&#8230;</p>
<blockquote><p>The entire actor model has hence been implemented as a library that integrates seamlessly with the rest of Scala&#8217;s core object/functional engineering. This is a design decision which the language designers did take upfront &#8211; hence objects in Scala, by default, bind to local invocation semantics, that enable it to take advantage of all the optimizations and efficiencies of being collocated in the same process.</p></blockquote>
<p>Within the context of erlang he goes on to add</p>
<blockquote><p>Hence languages like Erlang, which address the concerns of concurrency and distribution as part of the core, have decided to implement actors as their basic building block of abstractions. This was done with the vision that the Erlang programming style will be based on simple primitives of process spawning and message passing, both of which implemented as low overhead primitives in the virtual machine.</p></blockquote>
<p>&#8230;</p>
<blockquote><p>Erlang allows you to write programs that will run without any change in a regular non-distributed Erlang session, on two different Erlang nodes running on the same computer and as well on Erlang nodes running on two physically separated computers either in the same LAN or over the internet. It can do this, because the language designers decided to map the concurrency model naturally to distributed deployments extending the actor model beyond VM boundaries.</p></blockquote>
<p>The general conclusion is that its a matter of the intent of the author and the problems he chose to address.</p>
]]></content:encoded>
			<wfw:commentRss>http://tumblelog.dhananjaynene.com/2009/04/objects-as-actors-should-distribution-transparency-be-embedded-into-a-language-design/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

