<?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: On Modalities and Misadventures</title>
	<atom:link href="http://dtrace.org/blogs/bmc/2008/11/16/on-modalities-and-misadventures/feed/" rel="self" type="application/rss+xml" />
	<link>http://dtrace.org/blogs/bmc/2008/11/16/on-modalities-and-misadventures/</link>
	<description>Views on software from Bryan Cantrill&#039;s deck chair</description>
	<lastBuildDate>Wed, 24 Aug 2011 00:55:27 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.2</generator>
	<item>
		<title>By: UX-admin</title>
		<link>http://dtrace.org/blogs/bmc/2008/11/16/on-modalities-and-misadventures/#comment-916</link>
		<dc:creator>UX-admin</dc:creator>
		<pubDate>Sat, 31 Jul 2010 15:25:27 +0000</pubDate>
		<guid isPermaLink="false">http://dtrace.org/blogs/bmc/2008/11/16/on-modalities-and-misadventures/#comment-916</guid>
		<description>As the poor schmuck stuck with a huge and complex build system in Perl, I can only share your sentiments towards it.

As one highly paid consultant once put it to me so crisply:

&quot;I ditched Perl because it was all too easy to write sloppy code in it.&quot;

And now that I&#039;m stuck with that same Perl and code where the original author went on one of those &quot;let&#039;s see how far I can push the language&quot;, not only do I feel sorry for myself, but also share in your frustration...</description>
		<content:encoded><![CDATA[<p>As the poor schmuck stuck with a huge and complex build system in Perl, I can only share your sentiments towards it.</p>
<p>As one highly paid consultant once put it to me so crisply:</p>
<p>&#8220;I ditched Perl because it was all too easy to write sloppy code in it.&#8221;</p>
<p>And now that I&#8217;m stuck with that same Perl and code where the original author went on one of those &#8220;let&#8217;s see how far I can push the language&#8221;, not only do I feel sorry for myself, but also share in your frustration&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Spencer Christensen</title>
		<link>http://dtrace.org/blogs/bmc/2008/11/16/on-modalities-and-misadventures/#comment-109</link>
		<dc:creator>Spencer Christensen</dc:creator>
		<pubDate>Fri, 02 Jan 2009 11:26:41 +0000</pubDate>
		<guid isPermaLink="false">http://dtrace.org/blogs/bmc/2008/11/16/on-modalities-and-misadventures/#comment-109</guid>
		<description>From my perspective it looks like you have been hurt/frustrated by perl and have longed for some reason to leave it.  I&#039;ve met many other programmers with similar stories with various languages (I personally left Java long ago and feel good riddance).  But the fact is that millions of other programmers use those very tools successfully and happily.  It doesn&#039;t mean that they are all stupid for not seeing the same problems that we see.  It just means that we&#039;re not comfortable using those languages any more and personally feel more comfortable with something else.
The languages and tools we use definitely have pros and cons, but those pros and cons have varying degrees of weight with us due to our own biases and personal experiences.  You found a solution that you like and feel comfortable with.  If someone else was in your place perhaps they would have stuck with perl (or gone with python or ruby or lisp or ...).  My point is that programmers have opinions about what is &quot;right&quot; or &quot;wrong&quot; with a given tool or language, and often those opinions are strong and heated.  But unless we are aware of our own biases and admit them, we&#039;ll never get passed our own opinions.  There is always more than one way to do what we need no matter the tool or language or skill set; there is always a different path.  Just because we prefer one method to get to a destination doesn&#039;t mean the others are wrong for other people to take.
Now, getting passed that issue- I&#039;m impressed with this project and your solution.  I&#039;m a big fan of SpiderMonkey and glad to see yet another use for it.  Nice work.
</description>
		<content:encoded><![CDATA[<p>From my perspective it looks like you have been hurt/frustrated by perl and have longed for some reason to leave it.  I&#8217;ve met many other programmers with similar stories with various languages (I personally left Java long ago and feel good riddance).  But the fact is that millions of other programmers use those very tools successfully and happily.  It doesn&#8217;t mean that they are all stupid for not seeing the same problems that we see.  It just means that we&#8217;re not comfortable using those languages any more and personally feel more comfortable with something else.<br />
The languages and tools we use definitely have pros and cons, but those pros and cons have varying degrees of weight with us due to our own biases and personal experiences.  You found a solution that you like and feel comfortable with.  If someone else was in your place perhaps they would have stuck with perl (or gone with python or ruby or lisp or &#8230;).  My point is that programmers have opinions about what is &quot;right&quot; or &quot;wrong&quot; with a given tool or language, and often those opinions are strong and heated.  But unless we are aware of our own biases and admit them, we&#8217;ll never get passed our own opinions.  There is always more than one way to do what we need no matter the tool or language or skill set; there is always a different path.  Just because we prefer one method to get to a destination doesn&#8217;t mean the others are wrong for other people to take.<br />
Now, getting passed that issue- I&#8217;m impressed with this project and your solution.  I&#8217;m a big fan of SpiderMonkey and glad to see yet another use for it.  Nice work.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Michael Ernest</title>
		<link>http://dtrace.org/blogs/bmc/2008/11/16/on-modalities-and-misadventures/#comment-108</link>
		<dc:creator>Michael Ernest</dc:creator>
		<pubDate>Sun, 28 Dec 2008 10:01:37 +0000</pubDate>
		<guid isPermaLink="false">http://dtrace.org/blogs/bmc/2008/11/16/on-modalities-and-misadventures/#comment-108</guid>
		<description>I just wanted to say I&#039;m deeply gratified to see code comments that are as heated as mine sometimes are, but also more elegant (ahem, less coarse) than what I put down. Also nice to know that limited skills like mine aren&#039;t the only just cause of an antipathy for Perl. Thanks!
</description>
		<content:encoded><![CDATA[<p>I just wanted to say I&#8217;m deeply gratified to see code comments that are as heated as mine sometimes are, but also more elegant (ahem, less coarse) than what I put down. Also nice to know that limited skills like mine aren&#8217;t the only just cause of an antipathy for Perl. Thanks!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kebabbert</title>
		<link>http://dtrace.org/blogs/bmc/2008/11/16/on-modalities-and-misadventures/#comment-107</link>
		<dc:creator>Kebabbert</dc:creator>
		<pubDate>Thu, 27 Nov 2008 08:01:10 +0000</pubDate>
		<guid isPermaLink="false">http://dtrace.org/blogs/bmc/2008/11/16/on-modalities-and-misadventures/#comment-107</guid>
		<description>Ive heard lots about Python being much more productive than Perl. Did you consider Python at all? And if no, why not?
</description>
		<content:encoded><![CDATA[<p>Ive heard lots about Python being much more productive than Perl. Did you consider Python at all? And if no, why not?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Robin Houston</title>
		<link>http://dtrace.org/blogs/bmc/2008/11/16/on-modalities-and-misadventures/#comment-106</link>
		<dc:creator>Robin Houston</dc:creator>
		<pubDate>Mon, 24 Nov 2008 03:39:39 +0000</pubDate>
		<guid isPermaLink="false">http://dtrace.org/blogs/bmc/2008/11/16/on-modalities-and-misadventures/#comment-106</guid>
		<description>It sounds as replacing Perl with a language you understand better was the right thing for you to do. I think it&#039;s worth pointing out, though, at least for the benefit of passers-by, that in Perl you can turn numeric conversion warnings into exceptions simply by writing:
use warnings FATAL =&gt; &quot;numeric&quot;;
</description>
		<content:encoded><![CDATA[<p>It sounds as replacing Perl with a language you understand better was the right thing for you to do. I think it&#8217;s worth pointing out, though, at least for the benefit of passers-by, that in Perl you can turn numeric conversion warnings into exceptions simply by writing:<br />
use warnings FATAL =&gt; &quot;numeric&quot;;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bryan Cantrill</title>
		<link>http://dtrace.org/blogs/bmc/2008/11/16/on-modalities-and-misadventures/#comment-105</link>
		<dc:creator>Bryan Cantrill</dc:creator>
		<pubDate>Mon, 17 Nov 2008 12:59:54 +0000</pubDate>
		<guid isPermaLink="false">http://dtrace.org/blogs/bmc/2008/11/16/on-modalities-and-misadventures/#comment-105</guid>
		<description>Some other guy,
As I made clear, the comment was indeed a coping mechanism.  But I don&#039;t believe that I am blaming my &quot;own lack of enlightenment on the mistakes of others&quot;, and I&#039;m not sure how exactly one could draw the inference from my comment.  Indeed, it sounds like your comment here may well be its own coping mechanism for a deeper pathology, so I&#039;ll leave you to it, and wish you well in conquering your personal demons...
</description>
		<content:encoded><![CDATA[<p>Some other guy,<br />
As I made clear, the comment was indeed a coping mechanism.  But I don&#8217;t believe that I am blaming my &quot;own lack of enlightenment on the mistakes of others&quot;, and I&#8217;m not sure how exactly one could draw the inference from my comment.  Indeed, it sounds like your comment here may well be its own coping mechanism for a deeper pathology, so I&#8217;ll leave you to it, and wish you well in conquering your personal demons&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: some other guy</title>
		<link>http://dtrace.org/blogs/bmc/2008/11/16/on-modalities-and-misadventures/#comment-104</link>
		<dc:creator>some other guy</dc:creator>
		<pubDate>Mon, 17 Nov 2008 12:50:51 +0000</pubDate>
		<guid isPermaLink="false">http://dtrace.org/blogs/bmc/2008/11/16/on-modalities-and-misadventures/#comment-104</guid>
		<description>Raids of teenagers? 
As a guy who started coding in the late jurassic, and having managed programmers for a long, long time, I can tell you that the most common reason for &quot;vitriolic comments&quot; comes from ignorance(!) in young programmers. It&#039;s a phase, much like adolescence, unrequited crushes and belief in one&#039;s own omnipotence and perfection.
Don&#039;t get me wrong - such comments usually are way more useful than you&#039;d think - but unfortunately, they never get sent to the guy(s) who implemented the original language/code/system/paradigm. And it&#039;s a shame, because the more obvious a language/system/paradigm is, the more easily it will be adopted.
But that never happens.
Instead, such quotes are written as a psychological coping mechanism, one that allows a programmer to blame their own lack of enlightenment on the mistakes of others.  
You&#039;ll eventually grow out of it, usually at about the time someone else points out your own coding and design failures for about the 100th time.
</description>
		<content:encoded><![CDATA[<p>Raids of teenagers?<br />
As a guy who started coding in the late jurassic, and having managed programmers for a long, long time, I can tell you that the most common reason for &quot;vitriolic comments&quot; comes from ignorance(!) in young programmers. It&#8217;s a phase, much like adolescence, unrequited crushes and belief in one&#8217;s own omnipotence and perfection.<br />
Don&#8217;t get me wrong &#8211; such comments usually are way more useful than you&#8217;d think &#8211; but unfortunately, they never get sent to the guy(s) who implemented the original language/code/system/paradigm. And it&#8217;s a shame, because the more obvious a language/system/paradigm is, the more easily it will be adopted.<br />
But that never happens.<br />
Instead, such quotes are written as a psychological coping mechanism, one that allows a programmer to blame their own lack of enlightenment on the mistakes of others.<br />
You&#8217;ll eventually grow out of it, usually at about the time someone else points out your own coding and design failures for about the 100th time.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bryan Cantrill</title>
		<link>http://dtrace.org/blogs/bmc/2008/11/16/on-modalities-and-misadventures/#comment-103</link>
		<dc:creator>Bryan Cantrill</dc:creator>
		<pubDate>Mon, 17 Nov 2008 11:03:33 +0000</pubDate>
		<guid isPermaLink="false">http://dtrace.org/blogs/bmc/2008/11/16/on-modalities-and-misadventures/#comment-103</guid>
		<description>That snippet was really meant to be more of an example of my frustration than anything else, but let&#039;s pick up the issue to which it&#039;s referring:  the fundamental problem here is not the warnings -- it is the fact that Perl&#039;s exception mechanism is unspeakably broken.  In most languages, I would expect an illegal coercion to generate an exception that can then be caught and explicitly handled.  But because Perl elected to overload die() as an exception mechanism (and because Perl warns on an illegal coercion instead of die()&#039;ing), the only way to achieve the reasonable result is to have the warning actually die().  The code that I quoted was relying on this, but you wouldn&#039;t know it from the snippet that I provided here: the next line was a check against $EVAL_ERROR, propagating the &quot;exception&quot; if it&#039;s set.  So I&#039;m afraid that the &quot;fix&quot; of simply turning off warnings doesn&#039;t work here.  And even if it did work (that is, even if we were not seeking to explicitly handle the coercion failure), it would still be an unacceptable solution:  turning off warnings in Perl allows for too many silent failure conditions to be safely used in production code.
While I happen to think that Perl&#039;s busted exception mechanism is a perfectly good example of its flaws, I&#039;ll agree that there are so many such examples that it&#039;s difficult to choose -- and that this example may indeed be poor relative to Perl&#039;s more glaring deformities...
</description>
		<content:encoded><![CDATA[<p>That snippet was really meant to be more of an example of my frustration than anything else, but let&#8217;s pick up the issue to which it&#8217;s referring:  the fundamental problem here is not the warnings &#8212; it is the fact that Perl&#8217;s exception mechanism is unspeakably broken.  In most languages, I would expect an illegal coercion to generate an exception that can then be caught and explicitly handled.  But because Perl elected to overload die() as an exception mechanism (and because Perl warns on an illegal coercion instead of die()&#8217;ing), the only way to achieve the reasonable result is to have the warning actually die().  The code that I quoted was relying on this, but you wouldn&#8217;t know it from the snippet that I provided here: the next line was a check against $EVAL_ERROR, propagating the &quot;exception&quot; if it&#8217;s set.  So I&#8217;m afraid that the &quot;fix&quot; of simply turning off warnings doesn&#8217;t work here.  And even if it did work (that is, even if we were not seeking to explicitly handle the coercion failure), it would still be an unacceptable solution:  turning off warnings in Perl allows for too many silent failure conditions to be safely used in production code.<br />
While I happen to think that Perl&#8217;s busted exception mechanism is a perfectly good example of its flaws, I&#8217;ll agree that there are so many such examples that it&#8217;s difficult to choose &#8212; and that this example may indeed be poor relative to Perl&#8217;s more glaring deformities&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: glue-huffing Perl-coding 34-year-old teenager Robert de Forest</title>
		<link>http://dtrace.org/blogs/bmc/2008/11/16/on-modalities-and-misadventures/#comment-102</link>
		<dc:creator>glue-huffing Perl-coding 34-year-old teenager Robert de Forest</dc:creator>
		<pubDate>Mon, 17 Nov 2008 02:11:51 +0000</pubDate>
		<guid isPermaLink="false">http://dtrace.org/blogs/bmc/2008/11/16/on-modalities-and-misadventures/#comment-102</guid>
		<description>You turn warnings on, try to pull the last character off a string and coerce it to a number and then complain about figuring out how to suppress the &quot;non numeric string in addition&quot; warning?
Since Perl 5.6 (March 2000) you can turn warnings off within a block:
    $val = do { no warnings; substr($value, 0, -1) + 0.0; }
Perl is certainly not perfect, but yours was a poor example of its flaws.  (I stopped reading at &quot;tourist destinations.&quot;)
</description>
		<content:encoded><![CDATA[<p>You turn warnings on, try to pull the last character off a string and coerce it to a number and then complain about figuring out how to suppress the &quot;non numeric string in addition&quot; warning?<br />
Since Perl 5.6 (March 2000) you can turn warnings off within a block:<br />
    $val = do { no warnings; substr($value, 0, -1) + 0.0; }<br />
Perl is certainly not perfect, but yours was a poor example of its flaws.  (I stopped reading at &quot;tourist destinations.&quot;)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Roland Mainz</title>
		<link>http://dtrace.org/blogs/bmc/2008/11/16/on-modalities-and-misadventures/#comment-101</link>
		<dc:creator>Roland Mainz</dc:creator>
		<pubDate>Sun, 16 Nov 2008 19:12:59 +0000</pubDate>
		<guid isPermaLink="false">http://dtrace.org/blogs/bmc/2008/11/16/on-modalities-and-misadventures/#comment-101</guid>
		<description>&gt; you&#039;ll see that it has essentially nothing in common with ksh93.
Erm... are you sure ? I had to look twice to see the difference between your example and normal ksh93 syntax (the explicit &quot;run&quot; function and that &quot;for&quot; is written &quot;for( expr1; expr2; expr3)&quot; instead of &quot;for(( expr1; expr2; expr3))&quot; are the only major differences, the other things exist in ksh93, too (e.g. OO-style types+functions/methods, string operators, list/tree objects, structured variables etc.)))
</description>
		<content:encoded><![CDATA[<p>&gt; you&#8217;ll see that it has essentially nothing in common with ksh93.<br />
Erm&#8230; are you sure ? I had to look twice to see the difference between your example and normal ksh93 syntax (the explicit &quot;run&quot; function and that &quot;for&quot; is written &quot;for( expr1; expr2; expr3)&quot; instead of &quot;for(( expr1; expr2; expr3))&quot; are the only major differences, the other things exist in ksh93, too (e.g. OO-style types+functions/methods, string operators, list/tree objects, structured variables etc.)))</p>
]]></content:encoded>
	</item>
</channel>
</rss>

