<div dir="ltr">Let's agree to disagree then. I see your methodology used all around me with often problematic results. Maybe devs should have two machines -- one monster that is *only* usable to develop fast, one small that where they run their own apps (email, web browser etc.).<br>

</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Oct 8, 2013 at 1:30 PM, Tim Delaney <span dir="ltr"><<a href="mailto:timothy.c.delaney@gmail.com" target="_blank">timothy.c.delaney@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5">On 9 October 2013 03:35, Guido van Rossum <span dir="ltr"><<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Oct 8, 2013 at 8:33 AM, R. David Murray <span dir="ltr"><<a href="mailto:rdmurray@bitdance.com" target="_blank">rdmurray@bitdance.com</a>></span> wrote:<br>





<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
PS: I have always thought it sad that the ready availability of memory,<br>
CPU speed, and disk space tends to result in lazy programs.  I understand<br>
there is an effort/value tradeoff, and I make those tradeoffs myself<br>
all the time...but it still makes me sad.  Then, again, in my early<br>
programming days I spent a fair amount of time writing and using Forth,<br>
and that probably colors my worldview. :)<br></blockquote></div><br></div><div class="gmail_extra">I never used or cared for Forth, but I have the same worldview. I remember getting it from David Rosenthal, an early Sun reviewer. He stated that engineers should be given the smallest desktop computer available, not the largest, so they would feel their users' pain and optimize appropriately. Sadly software vendors who are also hardware vendors have incentives going in the opposite direction -- they want users to feel the pain so they'll buy a new device.</div>



</div></blockquote><div><br></div></div></div><div>I look at it a different way. Developers should be given powerful machines to speed up the development cycle (especially important when prototyping and in the code/run unit test cycle), but everything should be tested on the smallest machine available.</div>



<div><br></div><div>It's also a good idea for each developer to have a resource-constrained machine for developer testing/profiling/etc. Virtual machines work quite well for this - you can modify the resource constraints (CPU, memory, etc) to simulate different scenarios.</div>



<div><br></div><div>I find that this tends to better promote the methodology of "make it right, then make it fast (small, etc)", which I subscribe to. Optimising too early leads to all your code being complicated, rather than just the bits that need it.</div>

<span class="HOEnZb"><font color="#888888">
<div><br></div><div>Tim Delaney </div></font></span></div></div></div>
</blockquote></div><br><br clear="all"><br>-- <br>--Guido van Rossum (<a href="http://python.org/~guido">python.org/~guido</a>)
</div>