[Pythonmac-SIG] Mac User Python Newbies

[Bob Ippolito]

On Feb 14, 2005, at 18:29, has wrote:

> Bob Ippolito wrote:
>
>>>> Personally, I hope that developers See The Light and do interface
>>>> building in a separate but integrated application like Xcode and
>>>> Interface Builder.
>>>
>>> Exactly. Or separate, integrateable components that plug into a 
>>> common base framework.
>>
>> Well, separate processes is necessary.. a component based model can't 
>> work, because certain components just can't live in the same process 
>> with one another.
>
> Why not? And even where multiple processes are needed, why shouldn't 
> we still hide the distinction from the user? (e.g. Erlang is virtually 
> nothing _but_ processes.) Application-centric metaphors are nothing 
> special. Hierarchical file/folder metaphors are nothing special. 
> They're not inviolable holy of holies.

It's simply, without a doubt, no way around it, not technically 
possible to hide the separation from the user if you want to support 
components written using different GUI frameworks -- and that is an 
explicit requirement.  On Mac OS X, each process may have zero or one 
GUI event loops, and each event loop may have zero or one Mac OS X menu 
bars.  You simply can not design it any other way without being 
shackled to a particular GUI framework.

Why the heck should a text editor share a menu and accelerator keys 
with an interface builder anyway?

>>>>  > I've never understood what the obsession with building every
>>>>  > conceivable feature into the application core,
>>>>
>>>> I think this is largely caused by complexity of the alternative and 
>>>> the
>>>> convenience of doing it in this way.
>>>
>>> Developer convenience up to a point, yes. It requires less up-front 
>>> planning and major direction changes: just jump in and write some 
>>> code. Yet the same could be said for procedural vs OO construction, 
>>> so why are developers seeing the advantages of modular design in the 
>>> small but still missing it so often in the large?
>>
>> I think in a lot of cases this may be somewhat incorrect.  A lot of 
>> times you have a really modular framework, but it's not easy to rip 
>> apart into its constituent components and install just what you want 
>> (Twisted 1.x is an example of this).
>
> There's no excuse for coupling, say, persistence mechanisms and 
> templating mechanisms into the framework. Argue the point again when 
> they've at least managed to split those off.

So what if having Twisted installed gets you both persistence and 
templating functionality?  They are not tightly coupled to anything 
else in Twisted that don't absolutely require them to function, and you 
don't have to use them.

>> So what?  Although Twisted 2.x is moving away from this model, it's 
>> to accommodate a more flexible release schedule, not to split it up 
>> for the sake of splitting it up.
>
> IOW, there are benefits to modular, componentized architecture. I'm 
> certainly not arguing doing it simply for its own sake.

The *architecture* has been componentized since the start (or at least 
for the past few years, pre-1.0).  The release packages were not.

>> In some cases, such as your own appscript/aem/etc., this kind of 
>> external componentization is more of a hassle than anything else.
>
> Bad example. Appscript/aem's heavily componentized architecture is not 
> the problem. The problem with appscript is that 1. Python's own module 
> management mechanism is mediocre, and 2. I haven't bothered 
> compensating for this weakness by providing an easy 'all-in-one' 
> installer.

I don't think you understood my point.

Twisted 1.x is fully modular and componentized, but is distributed as a 
single unit
Twisted 2.x is fully modular and componentized, and will be distributed 
as multiple units (or one "sumo" installer that has them all)

There's no technical advantage whatsoever to Twisted 2's organization, 
but it makes sense given the need to have distinct release cycles -- 
which is simply a matter of scale.

appscript takes this to the extreme by separating several related 
things into different packages when they follow in lock-step anyway.  
Distutils is perfectly suitable for installing several packages at the 
same time in the same setup(...) invocation, there is *no good reason* 
for the appscript suite to be distributed in several units.  It's just 
a hassle for everyone, probably including yourself, because you have to 
upload and manage several different packages.

>>> And it seems that very often programmers never do get around to that 
>>> 'rebuild and replace' stage, because as soon as they've reached 
>>> working code it's considered 'done',
>>
>> Lots of people think that throwing away an application and starting 
>> over is a real mistake.  Joel Spolsky has an article on this that 
>> everyone likes to quote.
>
> Throwing away an _application_ is a sign that you've massively 
> fubared, and anyone who does that _should_ indeed be bloody ashamed of 
> themselves. Whereas generating and chucking away lots of fast working 
> sketches is an indication that you're already planning and 
> anticipating well ahead, because you're throwing out at a time when 
> the cost of doing so is still extremely low and more than amply 
> compensated for by the faster, deeper, greater learning you do along 
> the way. The whole point is to learn enough so that when you do 
> finally start on the deployment version you _won't need_ to throw it 
> away when it's done because you'll get it pretty much right first time 
> round.
>
> Fine art and Buddhist philosophy are the two things they should teach 
> every CS undergrad from as soon as they step through the door. The 
> moment you get precious, you're screwed. Learning how to humph hours, 
> weeks, even months of work into the skip _is_ hard (I've been there), 
> but once you do you'll be a better artist/developer for it.

Sure, I throw away code all the time -- probably a lot more than is 
necessary.  If it takes more than a day or two to get to the 'build and 
replace' stage you're probably at the "throwing away an application" 
state that some people say you should never do.  Instead, they say you 
should more or less just beat on it until it works right, because at 
least you'll have something resembling usable along the way.

-bob