Dreaming of new generation IDE

[Alf P. Steinbach]

* Steven D'Aprano:
> 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 
> between:
> 
> def func(flag):
>     if flag:
>         blockA
>     else:
>         blockB
> 
> 
> and
> 
> 
> def funcA():
>     blockA
> 
> def funcB():
>     blockB
> 
> 
> 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.

I agree with your reasoning :-), but it's not either/or.

Consider, sometimes one wants to do

   switch.off()

and sometimes one wants to do

   original_switch_state = switch.state()
   switch.off()
   # ... Do things that are best done in utter darkness.
   switch.set_state( original_switch_state )

E.g. the "switch" might be the enabled/disabled state of some GUI widget.

So IMHO it depends.

Sometimes one wants both kinds of "protocols".



Cheers,

- Alf