[Python-Dev] On the dangers of giving developers the best resources (original) (raw)

Daniel Holth dholth at gmail.com
Tue Oct 8 23:57:14 CEST 2013

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" <guido at 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.delaney at gmail.com>wrote: On 9 October 2013 03:35, Guido van Rossum <guido at python.org> wrote:

On Tue, Oct 8, 2013 at 8:33 AM, R. David Murray <rdmurray at 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 at python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/dholth%40gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20131008/4e43ac79/attachment-0001.html>

More information about the Python-Dev mailing list