Dreaming of new generation IDE
steve at REMOVE-THIS-cybersource.com.au
Sun Feb 7 02:57:24 CET 2010
On Sun, 07 Feb 2010 01:34:14 +0000, bartc wrote:
> For a real-world example, it means instead of having a room with a
> light-switch in it, if I *know* I want the light on or off, I should
> have two rooms: one with the light permanently on, and one with it
> permanently off, and just walk into the right one.
I don't think you can apply real-world analogies to software in that way.
They're too different.
Think of the objections to having two rooms, one permanently lit up, the
other permanently not:
(1) Having two rooms is expensive and wasteful of physical space, which
is in short supply.
(2) You typically use rooms for storing things (furniture and smaller
objects), having two rooms mean you would need to clone every object
inside it and somehow keep them in perfect synchronisation.
(3) the light that is always on will use electricity 24 hours a day,
regardless of whether you are inside it or not.
But none of those objections apply to functions:
(1) Functions are cheap and live in memory, which is not in short supply
unless you're programming for an embedded device.
(1a) Even if you are programming in a device that is short of memory, the
overhead of a second function is minimal. There's little difference
for any non-trivial code blocks, particularly if any common code is
factored out into another function which you call.
(2) Functions aren't typically used for storage, and when they need
external data, it is easy to have them access a common data store.
(3) Functions don't use CPU cycles just by existing.
More information about the Python-list