Sounds like you are suggesting we get a raspberry pi. All sorts of dumb waste shows up when you run code on those. El oct 8, 2013 4:46 p.m., "Guido van Rossum" <gu...@python.org> escribió:
> 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.). > > > On Tue, Oct 8, 2013 at 1:30 PM, Tim Delaney > <timothy.c.dela...@gmail.com>wrote: > >> On 9 October 2013 03:35, Guido van Rossum <gu...@python.org> wrote: >> >>> On Tue, Oct 8, 2013 at 8:33 AM, R. David Murray >>> <rdmur...@bitdance.com>wrote: >>> >>>> PS: I have always thought it sad that the ready availability of memory, >>>> CPU speed, and disk space tends to result in lazy programs. I >>>> understand >>>> there is an effort/value tradeoff, and I make those tradeoffs myself >>>> all the time...but it still makes me sad. Then, again, in my early >>>> programming days I spent a fair amount of time writing and using Forth, >>>> and that probably colors my worldview. :) >>>> >>> >>> 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. >>> >> >> 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. >> >> 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. >> >> 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. >> >> Tim Delaney >> > > > > -- > --Guido van Rossum (python.org/~guido) > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/dholth%40gmail.com > >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
