<?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: The C++ bashing season is back</title>
	<atom:link href="http://eli.thegreenplace.net/2009/10/17/the-c-bashing-season-is-back/feed/" rel="self" type="application/rss+xml" />
	<link>http://eli.thegreenplace.net/2009/10/17/the-c-bashing-season-is-back/</link>
	<description>Eli Bendersky's personal website</description>
	<lastBuildDate>Wed, 10 Mar 2010 17:32:25 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Praki prakash</title>
		<link>http://eli.thegreenplace.net/2009/10/17/the-c-bashing-season-is-back/comment-page-1/#comment-220315</link>
		<dc:creator>Praki prakash</dc:creator>
		<pubDate>Wed, 28 Oct 2009 14:25:13 +0000</pubDate>
		<guid isPermaLink="false">http://eli.thegreenplace.net/?p=1959#comment-220315</guid>
		<description>I like your post. However, I don&#039;t agree with many of the points you are making. It&#039;s certainly possible to build high performance web servers in other languages (check out the one built in Erlang, yaws). Apache has had a number of optimizations to its advantage, yet the Erlang implementation comes quite close. Along the same lines, as others have commented, quite a bit of Firefox is written in Javascript. It would be quite reasonable to guess that, less than 20% of the code accounts for 80% of the execution cost which makes the mixed implementation models work quite well.

A lot of real world programs require CPU and IO. As soon as IO is in the picture, performance of the code execution is less of an issue and managing IO well trumps everything else. Unless you are working with highly CPU centric code or interfacing with hardware at a very fine granularity, Java or any other decent VM implementation gets you there. To squeeze out that last ounce of performance, you do need to break through the VM layer. When you start to worry about memory layout, L1/L2 cache misses, pipeline stalls, is when things get really interesting and you need a language closer to the bare metal. C is a fine language to do it as long as it is written carefully. I would wager that, in most cases, efficiency is affected more by the implementation design rather the vehicle of implementation.

The problem with C++ is its complexity. There is much to like it when you use it in disciplined manner. It is also a treasure trove of clever doodads and serves very well for the mavens of complexity. One can use C++ successfully and many do. You have to take it seriously when the designers of STL claim that there is no other language in which they could have implemented STL. 

One is also prone to strongly argue for for their hard won C++ skills :)</description>
		<content:encoded><![CDATA[<p>I like your post. However, I don&#8217;t agree with many of the points you are making. It&#8217;s certainly possible to build high performance web servers in other languages (check out the one built in Erlang, yaws). Apache has had a number of optimizations to its advantage, yet the Erlang implementation comes quite close. Along the same lines, as others have commented, quite a bit of Firefox is written in Javascript. It would be quite reasonable to guess that, less than 20% of the code accounts for 80% of the execution cost which makes the mixed implementation models work quite well.</p>
<p>A lot of real world programs require CPU and IO. As soon as IO is in the picture, performance of the code execution is less of an issue and managing IO well trumps everything else. Unless you are working with highly CPU centric code or interfacing with hardware at a very fine granularity, Java or any other decent VM implementation gets you there. To squeeze out that last ounce of performance, you do need to break through the VM layer. When you start to worry about memory layout, L1/L2 cache misses, pipeline stalls, is when things get really interesting and you need a language closer to the bare metal. C is a fine language to do it as long as it is written carefully. I would wager that, in most cases, efficiency is affected more by the implementation design rather the vehicle of implementation.</p>
<p>The problem with C++ is its complexity. There is much to like it when you use it in disciplined manner. It is also a treasure trove of clever doodads and serves very well for the mavens of complexity. One can use C++ successfully and many do. You have to take it seriously when the designers of STL claim that there is no other language in which they could have implemented STL. </p>
<p>One is also prone to strongly argue for for their hard won C++ skills <img src='http://eli.thegreenplace.net/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Wheaties</title>
		<link>http://eli.thegreenplace.net/2009/10/17/the-c-bashing-season-is-back/comment-page-1/#comment-219464</link>
		<dc:creator>Wheaties</dc:creator>
		<pubDate>Mon, 26 Oct 2009 20:48:09 +0000</pubDate>
		<guid isPermaLink="false">http://eli.thegreenplace.net/?p=1959#comment-219464</guid>
		<description>&quot;...and you could never, ever, make it so fast and small
using any other language. C++ and C are the only
options you have here.&quot;

Also honing in on that I have to disagree.  Look at OCaml which provides in many cases the same performance as C++.  All it lacks is true multi-threading.  Then again so does Python.  What about Tcl which was designed for embedded systems?  There&#039;s just too many languages for everyone to keep track but to say C++ is the only option...</description>
		<content:encoded><![CDATA[<p>&#8220;&#8230;and you could never, ever, make it so fast and small<br />
using any other language. C++ and C are the only<br />
options you have here.&#8221;</p>
<p>Also honing in on that I have to disagree.  Look at OCaml which provides in many cases the same performance as C++.  All it lacks is true multi-threading.  Then again so does Python.  What about Tcl which was designed for embedded systems?  There&#8217;s just too many languages for everyone to keep track but to say C++ is the only option&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: notwithstanding</title>
		<link>http://eli.thegreenplace.net/2009/10/17/the-c-bashing-season-is-back/comment-page-1/#comment-218062</link>
		<dc:creator>notwithstanding</dc:creator>
		<pubDate>Thu, 22 Oct 2009 23:59:36 +0000</pubDate>
		<guid isPermaLink="false">http://eli.thegreenplace.net/?p=1959#comment-218062</guid>
		<description>If you have to write C++ I strongly agree that Qt is the library to use.  It&#039;s the only C++ library that&#039;s (a) featureful enough to give Java a run for its money in terms of features out of the box [i.e. why is there STILL no standard C++ socket library???], (b) portable to the major platforms and (c) highly readable.  Other libraries don&#039;t come close in mixing these three.  In particular portability and feature set tend to pull in opposite directions, and readability is a place where C++ can be particularly hard to deal with.</description>
		<content:encoded><![CDATA[<p>If you have to write C++ I strongly agree that Qt is the library to use.  It&#8217;s the only C++ library that&#8217;s (a) featureful enough to give Java a run for its money in terms of features out of the box [i.e. why is there STILL no standard C++ socket library???], (b) portable to the major platforms and (c) highly readable.  Other libraries don&#8217;t come close in mixing these three.  In particular portability and feature set tend to pull in opposite directions, and readability is a place where C++ can be particularly hard to deal with.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: notwithstanding</title>
		<link>http://eli.thegreenplace.net/2009/10/17/the-c-bashing-season-is-back/comment-page-1/#comment-218061</link>
		<dc:creator>notwithstanding</dc:creator>
		<pubDate>Thu, 22 Oct 2009 23:54:48 +0000</pubDate>
		<guid isPermaLink="false">http://eli.thegreenplace.net/?p=1959#comment-218061</guid>
		<description>I&#039;ll add my chips to the pile of people supporting D as a strong alternative to C++.  I got into the language when I read the feature list and I realized it was a list of fixes for everything I don&#039;t like about C++.  Everything I don&#039;t like about C too: just two features, an actual module system (that isn&#039;t the total sludge that #include turns a program into), and arrays/strings that know how big they are, are sufficient for me to prefer D over C for any program I can get away with doing in it.  With C++ the reasons for preferring it are even greater: no manual memory management (except when you really want it), no pointers (except when you really want them), exceptions that work properly, *parsable syntax* (hugely important if you want to write tools), templates that don&#039;t make your eyes bleed, compile-time evaluation of code (this is how you get to be faster than C: have the compiler do work in advance).

The language needs to settle some and the standard library needs to settle some.  When that happens I will actively advocate D over C++ for even commercial code.  I already prefer it for any systems programming I need to do.</description>
		<content:encoded><![CDATA[<p>I&#8217;ll add my chips to the pile of people supporting D as a strong alternative to C++.  I got into the language when I read the feature list and I realized it was a list of fixes for everything I don&#8217;t like about C++.  Everything I don&#8217;t like about C too: just two features, an actual module system (that isn&#8217;t the total sludge that #include turns a program into), and arrays/strings that know how big they are, are sufficient for me to prefer D over C for any program I can get away with doing in it.  With C++ the reasons for preferring it are even greater: no manual memory management (except when you really want it), no pointers (except when you really want them), exceptions that work properly, *parsable syntax* (hugely important if you want to write tools), templates that don&#8217;t make your eyes bleed, compile-time evaluation of code (this is how you get to be faster than C: have the compiler do work in advance).</p>
<p>The language needs to settle some and the standard library needs to settle some.  When that happens I will actively advocate D over C++ for even commercial code.  I already prefer it for any systems programming I need to do.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: blankthemuffin</title>
		<link>http://eli.thegreenplace.net/2009/10/17/the-c-bashing-season-is-back/comment-page-1/#comment-217827</link>
		<dc:creator>blankthemuffin</dc:creator>
		<pubDate>Thu, 22 Oct 2009 09:43:58 +0000</pubDate>
		<guid isPermaLink="false">http://eli.thegreenplace.net/?p=1959#comment-217827</guid>
		<description>The best alternative to C++ I reckon is D ( http://www.digitalmars.com/d/ ), it has some rather large flaws ( two standard libraries, a buggy compiler, lack of tools, lack of documentation ), but it&#039;s under development, and it looks to be well designed. If more people adopt it, I can see it becoming a nice language to use, what I believe C++ should have been.</description>
		<content:encoded><![CDATA[<p>The best alternative to C++ I reckon is D ( <a href="http://www.digitalmars.com/d/" rel="nofollow">http://www.digitalmars.com/d/</a> ), it has some rather large flaws ( two standard libraries, a buggy compiler, lack of tools, lack of documentation ), but it&#8217;s under development, and it looks to be well designed. If more people adopt it, I can see it becoming a nice language to use, what I believe C++ should have been.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: José Hérnandez</title>
		<link>http://eli.thegreenplace.net/2009/10/17/the-c-bashing-season-is-back/comment-page-1/#comment-217308</link>
		<dc:creator>José Hérnandez</dc:creator>
		<pubDate>Tue, 20 Oct 2009 10:31:56 +0000</pubDate>
		<guid isPermaLink="false">http://eli.thegreenplace.net/?p=1959#comment-217308</guid>
		<description>I don&#039;t think one can make a strong argument can be made for C++ anymore. The fundamental problem with its complexity is that it tries to be high and low level at the same time. The intelligent programmer would write most code in a high level language like Python and write the core, fundamental parts in C. It&#039;s dumb to waste one&#039;s time writing a complete GUI in C, but it&#039;s smart to write a matrix multiplying algorithm in C. If one resorts to this tactic of mixing languages, the arguments for C++ give way to the simplicity and efficiency of C. One ought to do the high level abstraction stuff in a high level language, not a language like C++.</description>
		<content:encoded><![CDATA[<p>I don&#8217;t think one can make a strong argument can be made for C++ anymore. The fundamental problem with its complexity is that it tries to be high and low level at the same time. The intelligent programmer would write most code in a high level language like Python and write the core, fundamental parts in C. It&#8217;s dumb to waste one&#8217;s time writing a complete GUI in C, but it&#8217;s smart to write a matrix multiplying algorithm in C. If one resorts to this tactic of mixing languages, the arguments for C++ give way to the simplicity and efficiency of C. One ought to do the high level abstraction stuff in a high level language, not a language like C++.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Guy</title>
		<link>http://eli.thegreenplace.net/2009/10/17/the-c-bashing-season-is-back/comment-page-1/#comment-217185</link>
		<dc:creator>Guy</dc:creator>
		<pubDate>Mon, 19 Oct 2009 21:38:40 +0000</pubDate>
		<guid isPermaLink="false">http://eli.thegreenplace.net/?p=1959#comment-217185</guid>
		<description>&quot;µTorrent is written in C++, and you could never, ever, make it so fast and small using any other language. C++ and C are the only options you have here.&quot;

What is required is the program be compiled to optimal native code. C/C++ is just one of a several ways to do that. It is the most popular at present.</description>
		<content:encoded><![CDATA[<p>&#8220;µTorrent is written in C++, and you could never, ever, make it so fast and small using any other language. C++ and C are the only options you have here.&#8221;</p>
<p>What is required is the program be compiled to optimal native code. C/C++ is just one of a several ways to do that. It is the most popular at present.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Lachlan Stuart</title>
		<link>http://eli.thegreenplace.net/2009/10/17/the-c-bashing-season-is-back/comment-page-1/#comment-216930</link>
		<dc:creator>Lachlan Stuart</dc:creator>
		<pubDate>Sun, 18 Oct 2009 23:50:49 +0000</pubDate>
		<guid isPermaLink="false">http://eli.thegreenplace.net/?p=1959#comment-216930</guid>
		<description>While I agree with your arguments against C++, I disagree with your statement:

`&lt;code&gt;__abENT__quot;__abENT__#46;__abENT__#46;__abENT__#46;and you could never, ever, make it so fast and small
using any other language__abENT__#46; C++ and C are the only
options you have here__abENT__#46;__abENT__quot;&lt;/code&gt;`

While factually this is true(ignoring ASM), I believe you&#039;re arguing for the wrong thing. What if you could have 50% more ease of programming for 10% more size? After all, a similar sacrifice was made moving from ASM to C++, you really need to look at this as a ease vs size spectrum and stop using C++ as the baseline for size, because it&#039;s not! 
Take D Programming Language for instance. Its based loosely on C++, but has many new features and a significantly tidied syntax. It has slightly larger output than C++ but provides a MUCH more enjoyable coding experience. In my opinion, D is a much better sweet spot on the ease vs speed scale.

There are actually quite a few tragically unappreciated compile-to-native-code languages out there, such as D Programming Language, Haskell, Objective-C, OCaml, Modula-2, etc...
I really wish people would stop using C++ because at least one of these will always be an alternative. Sure you may have to transcribe header files to import symbols from a DLL, but the benefits far outweigh this initial cost.</description>
		<content:encoded><![CDATA[<p>While I agree with your arguments against C++, I disagree with your statement:</p>
<div class="backtick"><pre><code>&quot;&#46;&#46;&#46;and you could never, ever, make it so fast and small
using any other language&#46; C++ and C are the only
options you have here&#46;&quot;</code></pre></div>
<p>While factually this is true(ignoring ASM), I believe you&#8217;re arguing for the wrong thing. What if you could have 50% more ease of programming for 10% more size? After all, a similar sacrifice was made moving from ASM to C++, you really need to look at this as a ease vs size spectrum and stop using C++ as the baseline for size, because it&#8217;s not!<br />
Take D Programming Language for instance. Its based loosely on C++, but has many new features and a significantly tidied syntax. It has slightly larger output than C++ but provides a MUCH more enjoyable coding experience. In my opinion, D is a much better sweet spot on the ease vs speed scale.</p>
<p>There are actually quite a few tragically unappreciated compile-to-native-code languages out there, such as D Programming Language, Haskell, Objective-C, OCaml, Modula-2, etc&#8230;<br />
I really wish people would stop using C++ because at least one of these will always be an alternative. Sure you may have to transcribe header files to import symbols from a DLL, but the benefits far outweigh this initial cost.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: SJS</title>
		<link>http://eli.thegreenplace.net/2009/10/17/the-c-bashing-season-is-back/comment-page-1/#comment-216921</link>
		<dc:creator>SJS</dc:creator>
		<pubDate>Sun, 18 Oct 2009 22:44:38 +0000</pubDate>
		<guid isPermaLink="false">http://eli.thegreenplace.net/?p=1959#comment-216921</guid>
		<description>C isn&#039;t the only alternative to C++, and it&#039;s a bit misleading to imply that it is. Objective-C is compatible with C (and does a better job of it than C++), provides object-oriented features, and is a lot less insane than C++.

The problems small enough to be manageable in C++ are problems small enough to be managed in vanilla C; problems too big for C are going to be too big for C++ -- but that won&#039;t become apparent for quite awhile.  Up until that point, it will make it easier, which is nice if you&#039;re not the one on the tail end of the development cycle.

(As you might have guessed, I&#039;ve been in that position. I&#039;d rather maintain Ada than C++.)</description>
		<content:encoded><![CDATA[<p>C isn&#8217;t the only alternative to C++, and it&#8217;s a bit misleading to imply that it is. Objective-C is compatible with C (and does a better job of it than C++), provides object-oriented features, and is a lot less insane than C++.</p>
<p>The problems small enough to be manageable in C++ are problems small enough to be managed in vanilla C; problems too big for C are going to be too big for C++ &#8212; but that won&#8217;t become apparent for quite awhile.  Up until that point, it will make it easier, which is nice if you&#8217;re not the one on the tail end of the development cycle.</p>
<p>(As you might have guessed, I&#8217;ve been in that position. I&#8217;d rather maintain Ada than C++.)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Andreas Schipplock</title>
		<link>http://eli.thegreenplace.net/2009/10/17/the-c-bashing-season-is-back/comment-page-1/#comment-216871</link>
		<dc:creator>Andreas Schipplock</dc:creator>
		<pubDate>Sun, 18 Oct 2009 18:18:39 +0000</pubDate>
		<guid isPermaLink="false">http://eli.thegreenplace.net/?p=1959#comment-216871</guid>
		<description>choose the right tool for the job. If one has to write a webserver, he probably wants to do that in c as you already mentioned. Someone who wants to do web development probably doesn&#039;t want to put his hands on assembler.</description>
		<content:encoded><![CDATA[<p>choose the right tool for the job. If one has to write a webserver, he probably wants to do that in c as you already mentioned. Someone who wants to do web development probably doesn&#8217;t want to put his hands on assembler.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
