<?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"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Is Scala Really the Next C++?</title>
	<atom:link href="http://www.codecommit.com/blog/scala/is-scala-really-the-next-c/feed" rel="self" type="application/rss+xml" />
	<link>http://www.codecommit.com/blog/scala/is-scala-really-the-next-c</link>
	<description>(permanently in beta)</description>
	<lastBuildDate>Mon, 09 Jan 2012 20:21:24 -0800</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Skym</title>
		<link>http://www.codecommit.com/blog/scala/is-scala-really-the-next-c/comment-page-1#comment-5198</link>
		<dc:creator>Skym</dc:creator>
		<pubDate>Tue, 28 Dec 2010 02:53:40 +0000</pubDate>
		<guid isPermaLink="false">http://www.codecommit.com/blog/scala/is-scala-really-the-next-c#comment-5198</guid>
		<description>In response, esp to Samuel Williams, firstly, it&#039;s hard to conclude how you could expect somebody Not to take negatively your remark that what they just said is bs.

Anyway I support the suggestion that C++ has a bad reputation. It depends on where you&#039;re coming from and if you&#039;re experience began with C-like languages it figures that you will have just accepted that C and it&#039;s relatives are just the way to do things. Just like your own first language makes more sense to you than others.

However, if you&#039;re coming to C++ from languages like Assembler, Lisp and Smalltalk then C++ is a dreadfully painful experience of a fairly disgraceful grammar and not the best logic.</description>
		<content:encoded><![CDATA[<p>In response, esp to Samuel Williams, firstly, it&#8217;s hard to conclude how you could expect somebody Not to take negatively your remark that what they just said is bs.</p>
<p>Anyway I support the suggestion that C++ has a bad reputation. It depends on where you&#8217;re coming from and if you&#8217;re experience began with C-like languages it figures that you will have just accepted that C and it&#8217;s relatives are just the way to do things. Just like your own first language makes more sense to you than others.</p>
<p>However, if you&#8217;re coming to C++ from languages like Assembler, Lisp and Smalltalk then C++ is a dreadfully painful experience of a fairly disgraceful grammar and not the best logic.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Coder</title>
		<link>http://www.codecommit.com/blog/scala/is-scala-really-the-next-c/comment-page-1#comment-5178</link>
		<dc:creator>Coder</dc:creator>
		<pubDate>Mon, 22 Nov 2010 19:06:02 +0000</pubDate>
		<guid isPermaLink="false">http://www.codecommit.com/blog/scala/is-scala-really-the-next-c#comment-5178</guid>
		<description>Very interesting, C++ still seems to be very flexible. Thanks for posting this information. Is this still the case for Scala?</description>
		<content:encoded><![CDATA[<p>Very interesting, C++ still seems to be very flexible. Thanks for posting this information. Is this still the case for Scala?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: trombel</title>
		<link>http://www.codecommit.com/blog/scala/is-scala-really-the-next-c/comment-page-1#comment-5172</link>
		<dc:creator>trombel</dc:creator>
		<pubDate>Fri, 05 Nov 2010 18:47:49 +0000</pubDate>
		<guid isPermaLink="false">http://www.codecommit.com/blog/scala/is-scala-really-the-next-c#comment-5172</guid>
		<description>I have the same impression that Scala is the next C++, although for slightly different reasons. And even though I enjoy programming in Scala, I have serious concerns that it will end up the same mess that C++ is. 

The biggest problems I have with scala are: very long compilation times (compared to Java) and very poor tool support. You could add other things such as poor error messages etc., but I don&#039;t think they are as important, and anyway I do believe they are all due to the same underlying problem, which is that the language tries to accommodate too many features, and the grammar became way too complicated. The whole DSL thing by the way I find utterly pointless and I think it is dead end route. Actually, I can&#039;t help comparing it to dreadful C++ &quot;clever&quot; (or were they called &quot;smart&quot;?) classes that took advantage of all sorts of dubious C++ features like operator overloading, implicit type conversions etc., in order to behave like proper high level types from proper high level programming languages. And they almost always worked the way you&#039;d expect them to, except when they didn&#039;t. 

And the symptoms are almost identical as with C++: extremely long build times, painful recompilations after  adding a whitespace to an unrelated file, people trying some elaborate workarounds (fsc? precompiled headers? distributed builds?), cryptic error messages, standard IDE features that you take for granted not working with scala source. 

In the end I don&#039;t really care if I can use named params or not, or if I can omit the dot in order to make the language feel somehow more &quot;natural&quot; to non-technical users (until the first error message shows up, I suppose). What I do care about is that Eclipse doesn&#039;t hang in the middle of code editing, and that it recompiles stuff when it needs to be recompiled, and doesn&#039;t recompile when it doesn&#039;t need to. None of these things works in Eclipse scala plugin at the moment, and the intellij one isn&#039;t any better.</description>
		<content:encoded><![CDATA[<p>I have the same impression that Scala is the next C++, although for slightly different reasons. And even though I enjoy programming in Scala, I have serious concerns that it will end up the same mess that C++ is. </p>
<p>The biggest problems I have with scala are: very long compilation times (compared to Java) and very poor tool support. You could add other things such as poor error messages etc., but I don&#8217;t think they are as important, and anyway I do believe they are all due to the same underlying problem, which is that the language tries to accommodate too many features, and the grammar became way too complicated. The whole DSL thing by the way I find utterly pointless and I think it is dead end route. Actually, I can&#8217;t help comparing it to dreadful C++ &#8220;clever&#8221; (or were they called &#8220;smart&#8221;?) classes that took advantage of all sorts of dubious C++ features like operator overloading, implicit type conversions etc., in order to behave like proper high level types from proper high level programming languages. And they almost always worked the way you&#8217;d expect them to, except when they didn&#8217;t. </p>
<p>And the symptoms are almost identical as with C++: extremely long build times, painful recompilations after  adding a whitespace to an unrelated file, people trying some elaborate workarounds (fsc? precompiled headers? distributed builds?), cryptic error messages, standard IDE features that you take for granted not working with scala source. </p>
<p>In the end I don&#8217;t really care if I can use named params or not, or if I can omit the dot in order to make the language feel somehow more &#8220;natural&#8221; to non-technical users (until the first error message shows up, I suppose). What I do care about is that Eclipse doesn&#8217;t hang in the middle of code editing, and that it recompiles stuff when it needs to be recompiled, and doesn&#8217;t recompile when it doesn&#8217;t need to. None of these things works in Eclipse scala plugin at the moment, and the intellij one isn&#8217;t any better.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Saifi Khan</title>
		<link>http://www.codecommit.com/blog/scala/is-scala-really-the-next-c/comment-page-1#comment-4931</link>
		<dc:creator>Saifi Khan</dc:creator>
		<pubDate>Thu, 04 Feb 2010 07:59:23 +0000</pubDate>
		<guid isPermaLink="false">http://www.codecommit.com/blog/scala/is-scala-really-the-next-c#comment-4931</guid>
		<description>Hi Dan:

How do you feel about Scala now ? Features, Libraries and Performance ?
It&#039;s almost getting close to 2 yrs since you wrote this blog.

thanks
Saifi Khan.</description>
		<content:encoded><![CDATA[<p>Hi Dan:</p>
<p>How do you feel about Scala now ? Features, Libraries and Performance ?<br />
It&#8217;s almost getting close to 2 yrs since you wrote this blog.</p>
<p>thanks<br />
Saifi Khan.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Arioch</title>
		<link>http://www.codecommit.com/blog/scala/is-scala-really-the-next-c/comment-page-1#comment-4903</link>
		<dc:creator>Arioch</dc:creator>
		<pubDate>Wed, 14 Oct 2009 23:40:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.codecommit.com/blog/scala/is-scala-really-the-next-c#comment-4903</guid>
		<description>Perhaps, Scala getter would better be denoted like name_? similar to setters&#039; name_=
Or just &quot;if compiler cannot tell getter from property - assume property&quot; rule of thumb ?
Or maybe Scala 2.8 arrays reworking will add for it.

where same term might be both value and function call, that is aways prone to ambiguity.
i like C approach there, that made parenthesis mandatory and eliminated ambiguity. 

in contrast, in TurboPascal (pointers were untyped), function XXX():pointer lead to ambiguity on assignment : var x: function:pointer; x := XXX; - is it address of function or its result?
even such strict andd anti-ambiguious language as Pascal fallen to ambiguity there</description>
		<content:encoded><![CDATA[<p>Perhaps, Scala getter would better be denoted like name_? similar to setters&#8217; name_=<br />
Or just &#8220;if compiler cannot tell getter from property &#8211; assume property&#8221; rule of thumb ?<br />
Or maybe Scala 2.8 arrays reworking will add for it.</p>
<p>where same term might be both value and function call, that is aways prone to ambiguity.<br />
i like C approach there, that made parenthesis mandatory and eliminated ambiguity. </p>
<p>in contrast, in TurboPascal (pointers were untyped), function XXX():pointer lead to ambiguity on assignment : var x: function:pointer; x := XXX; &#8211; is it address of function or its result?<br />
even such strict andd anti-ambiguious language as Pascal fallen to ambiguity there</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nicholas Tung</title>
		<link>http://www.codecommit.com/blog/scala/is-scala-really-the-next-c/comment-page-1#comment-4870</link>
		<dc:creator>Nicholas Tung</dc:creator>
		<pubDate>Thu, 30 Jul 2009 19:53:34 +0000</pubDate>
		<guid isPermaLink="false">http://www.codecommit.com/blog/scala/is-scala-really-the-next-c#comment-4870</guid>
		<description>in the second paragraph I think I was wrong; I think there might be a workaround for this -- declaring a variable of a certain type, setting it to null, and importing classes bound to it.

with regards to UAP, there&#039;s more confusion though. For example, let&#039;s say I get an array using a function:

classOf[scala.collection.mutable.HashSet[_]].getDeclaredMethods

Then I want to index into the array. The logical way to do it is

classOf[scala.collection.mutable.HashSet[_]].getDeclaredMethods(0)

but, since it was actually a function, this produces an error; the correct code is

classOf[scala.collection.mutable.HashSet[_]].getDeclaredMethods()(0)

This is an inconsistency iirc. c# properties do not have.</description>
		<content:encoded><![CDATA[<p>in the second paragraph I think I was wrong; I think there might be a workaround for this &#8212; declaring a variable of a certain type, setting it to null, and importing classes bound to it.</p>
<p>with regards to UAP, there&#8217;s more confusion though. For example, let&#8217;s say I get an array using a function:</p>
<p>classOf[scala.collection.mutable.HashSet[_]].getDeclaredMethods</p>
<p>Then I want to index into the array. The logical way to do it is</p>
<p>classOf[scala.collection.mutable.HashSet[_]].getDeclaredMethods(0)</p>
<p>but, since it was actually a function, this produces an error; the correct code is</p>
<p>classOf[scala.collection.mutable.HashSet[_]].getDeclaredMethods()(0)</p>
<p>This is an inconsistency iirc. c# properties do not have.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nicholas Tung</title>
		<link>http://www.codecommit.com/blog/scala/is-scala-really-the-next-c/comment-page-1#comment-4868</link>
		<dc:creator>Nicholas Tung</dc:creator>
		<pubDate>Tue, 28 Jul 2009 04:25:27 +0000</pubDate>
		<guid isPermaLink="false">http://www.codecommit.com/blog/scala/is-scala-really-the-next-c#comment-4868</guid>
		<description>&quot;So the moral of this long and rambling post is that you shouldn’t be wary of the Scala language.  It’s not going to become the next evil emperor of the language world.  Far from it, Scala may just represent the next step forward into true programmatic enlightenment.&quot;

I disagree. Scala has consistency, purity in some things (operators being named function calls), but an overwhelming number of language constructs on the other hand. The type system is difficult and unintuitive. For example, in the compiler phases, one actually imports various classes (i.e. types) by referencing bound variables, essentially forcing long classes with many bound inner classes -- even if these inner classes have pretty unrelated functionality.

One point where Scala does worse than C++ is by hiding potentially expensive processing. The -optimise setting breaks certain files, and the regular settings seem to be even too sugared for Java IcedTea to properly optimize.

The other unfortunate thing is class file compatibility. Things may be pretty on the surface, but having classes &quot;Function0&quot; through &quot;Function22&quot;, and type-erased function signatures clearly demonstrates how they&#039;re trying to hook into the class file format.

Regarding the concise syntax, I do very much like the match statement, but I think Python demonstrated how to achieve a lot of elegance with a very simple language, and some of these thoughts ($self$ as a parameter, being able to have classes deriving from str) were lost. Of course, some things are not feasible in a statically typed language.

Finally, I think they really messed up trying to support UAP. **The meaning of an expression can change based on what type it&#039;s assigned to**, which they needed to do in order to support actually grabbing function objects, when the function had no parameters. C# did it better, and came out earlier.

However, as I don&#039;t completely hate C++, I see Scala as a potentially useful / practical language. It fills a niche where one needs expressive statically-typed languages, and I hope it can evolve further.</description>
		<content:encoded><![CDATA[<p>&#8220;So the moral of this long and rambling post is that you shouldn’t be wary of the Scala language.  It’s not going to become the next evil emperor of the language world.  Far from it, Scala may just represent the next step forward into true programmatic enlightenment.&#8221;</p>
<p>I disagree. Scala has consistency, purity in some things (operators being named function calls), but an overwhelming number of language constructs on the other hand. The type system is difficult and unintuitive. For example, in the compiler phases, one actually imports various classes (i.e. types) by referencing bound variables, essentially forcing long classes with many bound inner classes &#8212; even if these inner classes have pretty unrelated functionality.</p>
<p>One point where Scala does worse than C++ is by hiding potentially expensive processing. The -optimise setting breaks certain files, and the regular settings seem to be even too sugared for Java IcedTea to properly optimize.</p>
<p>The other unfortunate thing is class file compatibility. Things may be pretty on the surface, but having classes &#8220;Function0&#8243; through &#8220;Function22&#8243;, and type-erased function signatures clearly demonstrates how they&#8217;re trying to hook into the class file format.</p>
<p>Regarding the concise syntax, I do very much like the match statement, but I think Python demonstrated how to achieve a lot of elegance with a very simple language, and some of these thoughts ($self$ as a parameter, being able to have classes deriving from str) were lost. Of course, some things are not feasible in a statically typed language.</p>
<p>Finally, I think they really messed up trying to support UAP. **The meaning of an expression can change based on what type it&#8217;s assigned to**, which they needed to do in order to support actually grabbing function objects, when the function had no parameters. C# did it better, and came out earlier.</p>
<p>However, as I don&#8217;t completely hate C++, I see Scala as a potentially useful / practical language. It fills a niche where one needs expressive statically-typed languages, and I hope it can evolve further.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: anonymouse</title>
		<link>http://www.codecommit.com/blog/scala/is-scala-really-the-next-c/comment-page-1#comment-3561</link>
		<dc:creator>anonymouse</dc:creator>
		<pubDate>Fri, 09 May 2008 16:45:45 +0000</pubDate>
		<guid isPermaLink="false">http://www.codecommit.com/blog/scala/is-scala-really-the-next-c#comment-3561</guid>
		<description>daniel, i really like your blog content.  however, i think your article is poorly titled.  there is a bit of a &quot;scala is complex&quot; meme and your title does not help.  many folks only skim titles, and you may be unintentionally reinforcing this fallacy.

would like to see more  scala examples on:

1. clean break - the language stands on its own and java-like is just an illusion (a great examples of this are the for comprehension, and that everything is an object...)

2. the language is orthogonal - any feeling of complexity in the language is there for a reason (amazing type system, or the ability to extend the language with constructs that look and feel like keywords or DSLs).

3. how simple it is to express things in scala via direct comparisons with ruby and java (you&#039;ve done a bit of this in the past).

keep up the great work.</description>
		<content:encoded><![CDATA[<p>daniel, i really like your blog content.  however, i think your article is poorly titled.  there is a bit of a &#8220;scala is complex&#8221; meme and your title does not help.  many folks only skim titles, and you may be unintentionally reinforcing this fallacy.</p>
<p>would like to see more  scala examples on:</p>
<p>1. clean break &#8211; the language stands on its own and java-like is just an illusion (a great examples of this are the for comprehension, and that everything is an object&#8230;)</p>
<p>2. the language is orthogonal &#8211; any feeling of complexity in the language is there for a reason (amazing type system, or the ability to extend the language with constructs that look and feel like keywords or DSLs).</p>
<p>3. how simple it is to express things in scala via direct comparisons with ruby and java (you&#8217;ve done a bit of this in the past).</p>
<p>keep up the great work.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joerg Gottschling</title>
		<link>http://www.codecommit.com/blog/scala/is-scala-really-the-next-c/comment-page-1#comment-3558</link>
		<dc:creator>Joerg Gottschling</dc:creator>
		<pubDate>Tue, 06 May 2008 19:35:38 +0000</pubDate>
		<guid isPermaLink="false">http://www.codecommit.com/blog/scala/is-scala-really-the-next-c#comment-3558</guid>
		<description>@Paul: My personal opinion about groovy is, that it is not really &quot;clean&quot;. That is why I think it is more like C++ then Scala. Scala is much much cleaner. It has some features it do not like much. But it is a very clean language in contrast to Groovy. :-\</description>
		<content:encoded><![CDATA[<p>@Paul: My personal opinion about groovy is, that it is not really &#8220;clean&#8221;. That is why I think it is more like C++ then Scala. Scala is much much cleaner. It has some features it do not like much. But it is a very clean language in contrast to Groovy. :-\</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Paul King</title>
		<link>http://www.codecommit.com/blog/scala/is-scala-really-the-next-c/comment-page-1#comment-3557</link>
		<dc:creator>Paul King</dc:creator>
		<pubDate>Tue, 06 May 2008 00:16:16 +0000</pubDate>
		<guid isPermaLink="false">http://www.codecommit.com/blog/scala/is-scala-really-the-next-c#comment-3557</guid>
		<description>I am a lot more optimistic about Groovy (but I am one of those involved in its evolution). Groovy mostly provides Java compatible syntax (but does make a clean break in some places). It also can be argued that Groovy allows a Java programmer to make a clean break from Java&#039;s static typing if they so choose. I have nothing bad to say about Scala as it has many nice features and is very well designed but I do think Groovy packages up powerful features on the whole in a more accessible form to everyday programmers than Scala does. I am optimistic that both will be around for the long haul and both have a great role to play in the JVM&#039;s evolution.</description>
		<content:encoded><![CDATA[<p>I am a lot more optimistic about Groovy (but I am one of those involved in its evolution). Groovy mostly provides Java compatible syntax (but does make a clean break in some places). It also can be argued that Groovy allows a Java programmer to make a clean break from Java&#8217;s static typing if they so choose. I have nothing bad to say about Scala as it has many nice features and is very well designed but I do think Groovy packages up powerful features on the whole in a more accessible form to everyday programmers than Scala does. I am optimistic that both will be around for the long haul and both have a great role to play in the JVM&#8217;s evolution.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

