<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Language comparisons and benchmarks are based on problems that are already solved. &nbsp;Is the true value of programming, solving new ones? &nbsp;In the comparison involving the 100 doors problem, the point should be the comparison of techniques that lead to the solution as if one does not exist. &nbsp;Which of these 'languages' leads to a solution that recognizes the square-root property? &nbsp;Can a language lead to such a solution? &nbsp;Or is it the programming techniques that use the language?<div><br></div><div><div>My point of view stems from experience, which might not be typical: many projects are over budget and behind schedule because programs do not work. &nbsp;They do not work because they are not designed sensibly, yet organizations insist to fuss over issues such as those covered in comparisons often shown in web pages: interpreted vs compiled, this language vs that one, this unrolled loop vs that embedded machine code, etc.</div><div><br></div><div>Computers are part of a fantastic technology that allows us to solve problems which are not even necessarily technical, but their technical implementation distracts us mercilessly.</div><div><br></div><div>rac</div><div><br></div></div><div><div>On May 3, 2010, at 6:35 AM, Samuel Williams wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Dear Shriram,<div><br></div><div>Thanks for your reply.</div><div><br></div><div><div><div>On 4/05/2010, at 2:31 AM, Shriram Krishnamurthi wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Let me caricature (a part of) this exchange:<br><br>Samuel: ... interpreted vs compiled ...<br><br>Shriram: nonsensical!<br><br>Samuel: well, most X's have interpreters, most Y's have compilers, so<br>it's reasonable to call X interpreted and Y compiled<br><br>Doug: convention is good, and anyway some languages are more static<br>and others are more dynamic, so we can use "interpreted" and<br>"compiled" as proxies<br><br>Samuel: yes, the term doesn't quite make sense (think about JITs), but<br>also, what Doug said!<br><br>To which I offer several responses:<br><br>1. Notice how you (Samuel) subtly shifted your argument.<br><br></div></blockquote><br><div><div>Thanks for your clarification. I feel that it is simply a matter of being aware that there are a vast range of terminologies and that not everyone agrees on the same meaning. I think its perfectly valid to be aware that terminology can be used in different ways with different meanings, and I appreciate your insights.</div><div><br></div><div>I don't think I've ever made an argument one way or another - I have simply done my best to use accepted conventions - but I appreciate that this might not be the best approach...</div><div><br></div><div><div>What is really important, as you have pointed out (point #3), is the general biases and assumptions made by the affiliation of a particular terminology to a particular language, and in a sense its implementation. I think this is actually a very important point which I haven't considered much.</div></div></div><br><blockquote type="cite"><div>2. If you want to use "interpreted" and "compiled" as aliases for<br>"dynamic" and "static", why not just use "dynamic" and "static"<br>instead, instead of abusing terminology? &nbsp;Indeed, if you are trying to<br>create an EDUCATIONAL site, why not EDUCATE people that their<br>terminology is wrong, rater than propagate their mistakes?<br></div></blockquote><div><br></div><div>This makes a lot of sense. So, do you separate it like this:</div><br><blockquote type="cite"><div><br>3. These terms are not value-neutral. &nbsp;People hear "compiled" and<br>think "fast"; they hear "interpreted" and think "slow". &nbsp;(Admit it, so<br>do you.) &nbsp;Of course, this might have nothing to do with the reality of<br>implementations. &nbsp;But it damns languages prematurely.<br></div></blockquote><div><br></div><div>Well, in a sense, it depends on terminology and understanding. When I think compiled I think rigid and structured, and when I think interpreted I think potentially slow and somewhat more flexible.</div><div><br></div><div>I think generally this is a relatively well accepted understanding - but I'm not suggesting that it is correct. From your arguments I believe that it might not be a good way to portray languages.</div><div><br></div><blockquote type="cite"><div><br>4. Sometimes, these terms are references not to the implementation<br>strategy but to the interaction interface: "interpreted" means "offers<br>a REPL" while "compiled" means "works off a command-line". &nbsp;But in<br>fact that is another bogus alias. &nbsp;Furthermore, it does a great<br>disservice to compiler writers for languages like Scheme, who've taken<br>the trouble to write actual compilers while providing the *interface*<br>of an "interpreter". &nbsp;Why don't you give them credit for their work?<br><font class="Apple-style-span"><font class="Apple-style-span" color="#144FAE"><br></font></font></div></blockquote><div><br></div><div>Sure, this makes sense.</div><br><blockquote type="cite"><div>Personally, I learned Scheme using a compiler and C using an<br>interpreter (really), so these terms have always struck me as bogus.<br><br></div></blockquote><div><br></div><div>Understandably so.</div><br><blockquote type="cite"><div>As for paradigms, I've made my point in my document. &nbsp;Glad you enjoyed<br>reading it. &nbsp;If you insist on using absurd terminology, I won't get in<br>your way.<br></div></blockquote><div><br></div><div>Well, while I think your response is overly harsh, I think you make valid points and I'll certainly do my best to improve the standard of the material.</div><div><br></div><div>Can you give me some feedback about the categorization:</div><div><br></div><div><div>Statically Typed:</div><div><span class="Apple-tab-span" style="white-space: pre; ">        </span>C, C++, Haskell, Java, Pascal</div><div><br></div><div>Dynamically Typed:</div><div><span class="Apple-tab-span" style="white-space: pre; ">        </span>Ruby, Python, Scheme, Smalltalk, Perl,&nbsp;Basic,&nbsp;JavaScript, PHP</div></div><div><br></div><div>I personally still see issues with the terminology, but please suggest the way it can be improved for better education and awareness. I'll also discuss this with my professors.</div><div><br></div><div>Do you think its appropriate to mention that the main implementation is compiler or interpreter? Or is this pretty much a non-issue in your mind?</div><br><blockquote type="cite"><div><br>As for the broader issues with your site, Neil and Jos have made the<br>relevant points admirably.<br><br>Shriram<br></div></blockquote></div><br></div><div>Kind regards,</div><div>Samuel</div></div>_________________________________________________<br> &nbsp;For list-related administrative tasks:<br> &nbsp;<a href="http://list.cs.brown.edu/mailman/listinfo/plt-scheme">http://list.cs.brown.edu/mailman/listinfo/plt-scheme</a><br></blockquote></div><br></body></html>