[Pythonmac-SIG] Mac User Python Newbies

[has]

Bob Ippolito wrote:

>>>Maybe because in many cases, the users are the developers and adding
>>>those 20%s together makes for some big ugly mess.
>>
>>I'm not sure that qualifies as an excuse; more making their bed and 
>>lying in it. :)
>
>Well the people writing these things obviously write it such that it 
>suits them, so perhaps they find this bed to be comfortable?

People are generally lazy. They'll do less work now even if it means 
more work later. (Perl's definition of 'lazy', while charming, is 
seriously optimistic.)


>>>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.


>>>  > 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?  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.


>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.


>>But there are ways. OpenDoc was built upon Apple events, for example.
>
>I've never seen it done in Python really easily.

Which is not to say it can't be done. It just means than in order for 
it to be done, some poor sap will have to have to step up and do all 
the hard work themselves. Which means lots of exploration and 
experimentation and lots of throwing out and starting over until the 
answers start emerging.


>>It's interesting that even MS are now moving away from the DCOM 
>>approach and towards an Apple event/Apple Event Object Model 
>>approach. I think Apple were definitely onto something with these: 
>>it's all about where you make the split, and finding the right 
>>point makes the difference between moving Mohammed or moving the 
>>mountain.
>
>And we all know how well Apple has been implementing Apple Events in 
>its more recent applications.  It's simply Not That Easy to do so, 
>so it's simply not done well or not done at all.

Apple can't even come up with a half decent explanation of what Apple 
events are. Wanna take bets on the total amount of resources they 
bother to invest in them internally? Is it any surprise they so often 
don't get supported properly? It's hardly like this is the first time 
Apple have come up with a great technology and consistently fumbled 
its deployment. Only Xerox seems able to consistently make an even 
bigger arse of things. I think you're much to quick in throwing up 
your hands; there's a big difference between a bolloxed execution and 
a bolloxed concept, and failure of one doesn't automatically imply 
failure of the other.


>>>that, and it's much easier to design something ad-hoc if you don't 
>>>concern yourself with keeping things modular.
>>
>>Of course. I often start out that way myself; it's hard to know 
>>what kind of high-level structure you're going to need if it's your 
>>first time exploring this particular problem. The trouble sets in 
>>when an initially ad-hoc design doesn't bother to improve its 
>>internal organisation as it grows;
>
>Well yeah, you do have to clean up your mess every so often.

Or constantly, if you're like me. I don't have much choice: I have 
such poor ability to cope with complexity, I either keep constantly 
on top of it or I'm screwed. Mind you, in some ways I think this 
actually leaves me at an advantage compared to folks with a much 
higher tolerance for complexity since it leaves me much less able to 
dig myself into a really deep hole. I can't help but write 
modularised code. :)


>>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.

Cheers,

has
-- 
http://freespace.virgin.net/hamish.sanderson/