<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.3.3" -->
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	>
<channel>
	<title>Comments for Tomas Varsavsky</title>
	<link>http://tomasvarsavsky.com</link>
	<description>Ramblings about life, the universe and everything</description>
	<pubDate>Sat, 06 Sep 2008 02:25:15 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.3.3</generator>
		<item>
		<title>Comment on Virtualised Ruby on Rails development environment for dummies by Jan Kaas</title>
		<link>http://tomasvarsavsky.com/2008/02/25/virtualised-ruby-on-rails-development-environment-for-dummies/#comment-203</link>
		<dc:creator>Jan Kaas</dc:creator>
		<pubDate>Wed, 28 May 2008 13:07:54 +0000</pubDate>
		<guid>http://tomasvarsavsky.com/2008/02/25/virtualised-ruby-on-rails-development-environment-for-dummies/#comment-203</guid>
		<description>@Richard Durnall

Don't make stupid comments, you know you want to!</description>
		<content:encoded><![CDATA[<p>@Richard Durnall</p>
<p>Don&#8217;t make stupid comments, you know you want to!</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Evaluating OpenCms, Alfresco and Liferay by Marcelo Ruiz Camauer</title>
		<link>http://tomasvarsavsky.com/2007/09/21/evaluating-opencms-alfresco-and-liferay/#comment-185</link>
		<dc:creator>Marcelo Ruiz Camauer</dc:creator>
		<pubDate>Mon, 10 Mar 2008 15:30:08 +0000</pubDate>
		<guid>http://tomasvarsavsky.com/2007/09/21/evaluating-opencms-alfresco-and-liferay/#comment-185</guid>
		<description>Please take another look at Liferay now. Jorge has updated the Wiki and now it much more sophisticated. LR has a new major version out, 4.4 which adds as usual a lot of great features. Version 5 is a few weeks away, and it will be JSR-286 compliant!  We have been developing fulltime using LR as our base system for two years and we love it. It is updated very quickly, the community is fairly responsive (nothing is ever perfect), the system is solid and is just a good platform on which to base any web-based application, portal, website or CMS, based on Java.</description>
		<content:encoded><![CDATA[<p>Please take another look at Liferay now. Jorge has updated the Wiki and now it much more sophisticated. LR has a new major version out, 4.4 which adds as usual a lot of great features. Version 5 is a few weeks away, and it will be JSR-286 compliant!  We have been developing fulltime using LR as our base system for two years and we love it. It is updated very quickly, the community is fairly responsive (nothing is ever perfect), the system is solid and is just a good platform on which to base any web-based application, portal, website or CMS, based on Java.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Virtualised Ruby on Rails development environment for dummies by uvt</title>
		<link>http://tomasvarsavsky.com/2008/02/25/virtualised-ruby-on-rails-development-environment-for-dummies/#comment-183</link>
		<dc:creator>uvt</dc:creator>
		<pubDate>Tue, 04 Mar 2008 12:46:40 +0000</pubDate>
		<guid>http://tomasvarsavsky.com/2008/02/25/virtualised-ruby-on-rails-development-environment-for-dummies/#comment-183</guid>
		<description>Cool Tomas, Though I figured out all this myself and am using it since long, it was good to find that you have documented it quite well here. Thx!</description>
		<content:encoded><![CDATA[<p>Cool Tomas, Though I figured out all this myself and am using it since long, it was good to find that you have documented it quite well here. Thx!</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Virtualised Ruby on Rails development environment for dummies by Richard Durnall</title>
		<link>http://tomasvarsavsky.com/2008/02/25/virtualised-ruby-on-rails-development-environment-for-dummies/#comment-174</link>
		<dc:creator>Richard Durnall</dc:creator>
		<pubDate>Mon, 25 Feb 2008 02:04:08 +0000</pubDate>
		<guid>http://tomasvarsavsky.com/2008/02/25/virtualised-ruby-on-rails-development-environment-for-dummies/#comment-174</guid>
		<description>Buy a mac! You know you want to.</description>
		<content:encoded><![CDATA[<p>Buy a mac! You know you want to.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on TDD requires a leap of faith by Oscar Huseyin</title>
		<link>http://tomasvarsavsky.com/2007/08/18/tdd-requires-a-leap-of-faith/#comment-166</link>
		<dc:creator>Oscar Huseyin</dc:creator>
		<pubDate>Sun, 27 Jan 2008 10:02:01 +0000</pubDate>
		<guid>http://tomasvarsavsky.com/2007/08/18/tdd-requires-a-leap-of-faith/#comment-166</guid>
		<description>Hey Tom,

Ive been spending a lot of my time during th latter half of 2007 reading about TDD and questioning its effectiveness and practicality.  Ive read a few scientific studies into the development process which are really interesting.  Here's one of them:

http://iit-iti.nrc-cnrc.gc.ca/publications/nrc-47445_e.html

And heres a post that summarises the paper.

http://scruffylookingcatherder.com/archive/2008/01/22/tdd-proven-effective-or-is-it.aspx</description>
		<content:encoded><![CDATA[<p>Hey Tom,</p>
<p>Ive been spending a lot of my time during th latter half of 2007 reading about TDD and questioning its effectiveness and practicality.  Ive read a few scientific studies into the development process which are really interesting.  Here&#8217;s one of them:</p>
<p><a href="http://iit-iti.nrc-cnrc.gc.ca/publications/nrc-47445_e.html" rel="nofollow">http://iit-iti.nrc-cnrc.gc.ca/publications/nrc-47445_e.html</a></p>
<p>And heres a post that summarises the paper.</p>
<p><a href="http://scruffylookingcatherder.com/archive/2008/01/22/tdd-proven-effective-or-is-it.aspx" rel="nofollow">http://scruffylookingcatherder.com/archive/2008/01/22/tdd-proven-effective-or-is-it.aspx</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Code complexity vs size by Brian Guthrie</title>
		<link>http://tomasvarsavsky.com/2007/12/22/code-complexity-vs-size/#comment-158</link>
		<dc:creator>Brian Guthrie</dc:creator>
		<pubDate>Mon, 24 Dec 2007 01:54:17 +0000</pubDate>
		<guid>http://tomasvarsavsky.com/2007/12/22/code-complexity-vs-size/#comment-158</guid>
		<description>I'm not sure you do have to understand the same set of concepts.  The Ruby idiom (of the form File.open()) abstracts over that stuff and gives you an 80% solution:  we're going to assume the file is there, and if it isn't we're going to die, and if it is we're going to give it to you line by line.  In contrast, Java forces you to make those choices each and every time you want to engage in IO, even if your answers don't change.  In languages that offer closures, rather than being a one-off, this linguistic feature has a ripple effect across your entire code base; suddenly you can abstract any idiom of the form "do this one repetitive thing, then some unique thing, then another repetitive thing" into a much cleaner representation.  There's a tremendous amount of unavoidable boilerplate code you have to write in Java simply to transform a list of one thing into a list of another that simply isn't necessary in Ruby or Java for this very reason.

Even better, you now have a way of storing these choices in code.  You don't need to have a rule that tells programmers to always handle a certain error in a certain way; you can offer them a method that accepts a block, and it takes care of it.  You've just made their lives simpler.

Going back to the first point, no codebase of a thousand classes is perfectly factored or a hundred percent domain-based.  Suddenly you don't need an IMoney interface or a CurrencyAdapter or a BankTransactionFactory, or the added cognitive overhead they impose.

Even if none of this were the case, it takes longer and requires more thought to visually parse through nine lines of code than it does three.</description>
		<content:encoded><![CDATA[<p>I&#8217;m not sure you do have to understand the same set of concepts.  The Ruby idiom (of the form File.open()) abstracts over that stuff and gives you an 80% solution:  we&#8217;re going to assume the file is there, and if it isn&#8217;t we&#8217;re going to die, and if it is we&#8217;re going to give it to you line by line.  In contrast, Java forces you to make those choices each and every time you want to engage in IO, even if your answers don&#8217;t change.  In languages that offer closures, rather than being a one-off, this linguistic feature has a ripple effect across your entire code base; suddenly you can abstract any idiom of the form &#8220;do this one repetitive thing, then some unique thing, then another repetitive thing&#8221; into a much cleaner representation.  There&#8217;s a tremendous amount of unavoidable boilerplate code you have to write in Java simply to transform a list of one thing into a list of another that simply isn&#8217;t necessary in Ruby or Java for this very reason.</p>
<p>Even better, you now have a way of storing these choices in code.  You don&#8217;t need to have a rule that tells programmers to always handle a certain error in a certain way; you can offer them a method that accepts a block, and it takes care of it.  You&#8217;ve just made their lives simpler.</p>
<p>Going back to the first point, no codebase of a thousand classes is perfectly factored or a hundred percent domain-based.  Suddenly you don&#8217;t need an IMoney interface or a CurrencyAdapter or a BankTransactionFactory, or the added cognitive overhead they impose.</p>
<p>Even if none of this were the case, it takes longer and requires more thought to visually parse through nine lines of code than it does three.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Code complexity vs size by Tomas Varsavsky</title>
		<link>http://tomasvarsavsky.com/2007/12/22/code-complexity-vs-size/#comment-157</link>
		<dc:creator>Tomas Varsavsky</dc:creator>
		<pubDate>Sun, 23 Dec 2007 04:41:21 +0000</pubDate>
		<guid>http://tomasvarsavsky.com/2007/12/22/code-complexity-vs-size/#comment-157</guid>
		<description>By equivalent I mean that they represent the same concept. For example, a financial application will have the concepts of Account, Transaction, Money, etc. If I follow good design principles like single responsibility per class and simplicity, there should be approximately the same number of classes representing these concepts regardless of the language used. So I don't think I would have less Ruby classes than Java but I probably would have fewer LoC per class. 

As to Yegge's first point, I agree that more code is always a maintenance problem when comparing code bases written in the same language. My point is that LoC and complexity/maintainability are not linearly proportional when comparing across programming languages. For the same problem, a 150,000 line solution in one language is not necessarily 3 times (or 2 times, or at all) less complex than a 500,000 solution in a different language. 

On his second point, maybe we have a different definition of complexity? To me a piece of code that opens a file, processes lines, handles errors and then closes the file implemented in Java with a loop and a try catch block is just a complex as the Ruby solution using closures because you still have to understand the same set to concepts. I think of complexity as the number of concepts and interaction between those concepts, not how many lines of code it takes to express them. Besides, if I really wanted to I could achieve code compression in the Java version. I guess the difference is that I would have to do it myself instead of leveraging a core language feature like closures.</description>
		<content:encoded><![CDATA[<p>By equivalent I mean that they represent the same concept. For example, a financial application will have the concepts of Account, Transaction, Money, etc. If I follow good design principles like single responsibility per class and simplicity, there should be approximately the same number of classes representing these concepts regardless of the language used. So I don&#8217;t think I would have less Ruby classes than Java but I probably would have fewer LoC per class. </p>
<p>As to Yegge&#8217;s first point, I agree that more code is always a maintenance problem when comparing code bases written in the same language. My point is that LoC and complexity/maintainability are not linearly proportional when comparing across programming languages. For the same problem, a 150,000 line solution in one language is not necessarily 3 times (or 2 times, or at all) less complex than a 500,000 solution in a different language. </p>
<p>On his second point, maybe we have a different definition of complexity? To me a piece of code that opens a file, processes lines, handles errors and then closes the file implemented in Java with a loop and a try catch block is just a complex as the Ruby solution using closures because you still have to understand the same set to concepts. I think of complexity as the number of concepts and interaction between those concepts, not how many lines of code it takes to express them. Besides, if I really wanted to I could achieve code compression in the Java version. I guess the difference is that I would have to do it myself instead of leveraging a core language feature like closures.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Code complexity vs size by Brian Guthrie</title>
		<link>http://tomasvarsavsky.com/2007/12/22/code-complexity-vs-size/#comment-156</link>
		<dc:creator>Brian Guthrie</dc:creator>
		<pubDate>Sat, 22 Dec 2007 17:21:36 +0000</pubDate>
		<guid>http://tomasvarsavsky.com/2007/12/22/code-complexity-vs-size/#comment-156</guid>
		<description>What evidence do you have for your assertion that a code base with 1000 Java classes is just as complex as a code base with 1000 Ruby classes but with fewer lines of code?  What's an "equivalent" class?  If you're writing 3-4 times fewer lines of code, won't you need fewer Ruby classes (in my experience, you will)?

In my mind, Yegge is essentially asserting two things.  One, that more lines of code--in an absolute sense--always causes more maintenance problems.  You seem to disagree with him there; you claim that class count causes complexity, not line count.  Two, that languages--like Java--without any code compression capabilities will always suffer in that regard; without closures, you cannot compress idioms, like file IO, down to their essence.  Is that right?</description>
		<content:encoded><![CDATA[<p>What evidence do you have for your assertion that a code base with 1000 Java classes is just as complex as a code base with 1000 Ruby classes but with fewer lines of code?  What&#8217;s an &#8220;equivalent&#8221; class?  If you&#8217;re writing 3-4 times fewer lines of code, won&#8217;t you need fewer Ruby classes (in my experience, you will)?</p>
<p>In my mind, Yegge is essentially asserting two things.  One, that more lines of code&#8211;in an absolute sense&#8211;always causes more maintenance problems.  You seem to disagree with him there; you claim that class count causes complexity, not line count.  Two, that languages&#8211;like Java&#8211;without any code compression capabilities will always suffer in that regard; without closures, you cannot compress idioms, like file IO, down to their essence.  Is that right?</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Code complexity vs size by Andres Massello</title>
		<link>http://tomasvarsavsky.com/2007/12/22/code-complexity-vs-size/#comment-155</link>
		<dc:creator>Andres Massello</dc:creator>
		<pubDate>Sat, 22 Dec 2007 16:42:06 +0000</pubDate>
		<guid>http://tomasvarsavsky.com/2007/12/22/code-complexity-vs-size/#comment-155</guid>
		<description>May I humbly suggest you to think in terms of DSL's instead on "delete" refactoring? You can make DSL easily with Ruby, see http://blog.jayfields.com/search/label/DSL</description>
		<content:encoded><![CDATA[<p>May I humbly suggest you to think in terms of DSL&#8217;s instead on &#8220;delete&#8221; refactoring? You can make DSL easily with Ruby, see <a href="http://blog.jayfields.com/search/label/DSL" rel="nofollow">http://blog.jayfields.com/search/label/DSL</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Evaluating OpenCms, Alfresco and Liferay by Arash Kaffamanesh</title>
		<link>http://tomasvarsavsky.com/2007/09/21/evaluating-opencms-alfresco-and-liferay/#comment-55</link>
		<dc:creator>Arash Kaffamanesh</dc:creator>
		<pubDate>Thu, 13 Dec 2007 15:21:19 +0000</pubDate>
		<guid>http://tomasvarsavsky.com/2007/09/21/evaluating-opencms-alfresco-and-liferay/#comment-55</guid>
		<description>Hi Tomas,
hello together,
I'm working since 5 years with OpenCms for internet and very large intra- / extra- net projects, OpenCms is used as a content delivery service for delivering static content to commercial portal servers like WebSphere Portal Server and is being used Standalone for Intranet Projetcs. I'm doing currently a proof of concept to integrate OpenCms with Liferay as one of the best open source portal frameworks. On the other hand we are thinking about to investigate some effort in the area of Alfresco  Liferay integration. Alfresco's WCM is very young and the community edition is not stable enough for enterprise projects, but it seems to compete with OpenCms  and Magnolia with her WCM capabilities in the near future in enterprise sectors. In general I think Alfresco is also going to compete more with Intervowen TeamSite and MS SharePoint in ECM sector. Anyway OpenCms will remain as the best LightWeight Open Source Enterprise WCMS and the upcoming OpenCms JSR168 Module Contribution from China will add the desired portal capabilities to her rich feature list. Cheers!</description>
		<content:encoded><![CDATA[<p>Hi Tomas,<br />
hello together,<br />
I&#8217;m working since 5 years with OpenCms for internet and very large intra- / extra- net projects, OpenCms is used as a content delivery service for delivering static content to commercial portal servers like WebSphere Portal Server and is being used Standalone for Intranet Projetcs. I&#8217;m doing currently a proof of concept to integrate OpenCms with Liferay as one of the best open source portal frameworks. On the other hand we are thinking about to investigate some effort in the area of Alfresco  Liferay integration. Alfresco&#8217;s WCM is very young and the community edition is not stable enough for enterprise projects, but it seems to compete with OpenCms  and Magnolia with her WCM capabilities in the near future in enterprise sectors. In general I think Alfresco is also going to compete more with Intervowen TeamSite and MS SharePoint in ECM sector. Anyway OpenCms will remain as the best LightWeight Open Source Enterprise WCMS and the upcoming OpenCms JSR168 Module Contribution from China will add the desired portal capabilities to her rich feature list. Cheers!</p>
]]></content:encoded>
	</item>
</channel>
</rss>
