It's not actually so much the extreme waste that I'm looking to expose, but rather the day-to-day annoyances of stuff you use regularly that slows you down by just a second (or ten), or things that gets slower at each release. On Tue, Oct 8, 2013 at 2:57 PM, Daniel Holth <dholth at gmail.com> wrote: > 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 >> >> -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20131008/ee7e2124/attachment.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4