[Pythonmac-SIG] Mac User Python Newbies

[Bob Ippolito]

On Feb 14, 2005, at 2:29 PM, has wrote:

> Bob Ippolito wrote:
>
>>  > MS builds software that way cos they like to get their users 
>> locked into
>>  > a perpetual upgrade cycle from which they can make money, but 
>> what's
>>  > OSS's excuse?
>>
>> 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?

>>  > Furthermore, those users aren't locked into a single fixed solution
>>  > for, say, building GUIs: as long as wxPython, PythonCard, etc. 
>> provide
>>  > compatible components they can plug in whichever one they want.
>>
>> 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. That was the idea behind OpenDoc, for example: the 
> user's work is more important than the tools, so make it the center of 
> attention by using a document-oriented model instead of an 
> application-oriented one. Either way though the technical goal is 
> exactly the same: keep the coupling between components as loose as 
> possible. That's the _key_ to getting the design right: decoupling 
> each functional area from the others. The rest is just finding the 
> slickest, most convenient presentation. Unfortunately, I think most 
> folk are only thinking about the presentation when they 'design' their 
> system, and so they miss this. They get the form looking almost right 
> superficially, but they don't get the substance. And then they wonder 
> why they can't get the form any better, and why it starts falling 
> apart when they try to take it any further.

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.

>>  > 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).  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.  
In some cases, such as your own appscript/aem/etc., this kind of 
external componentization is more of a hassle than anything else.  
You're releasing them on basically the same schedule, but you make the 
user worry about dealing with them separately.  I decided to go the 
other way with py2app.  It has four distinct components, but it makes 
little sense to distribute them separately, so I don't.  
altgraph/modulegraph will eventually be available separately for the 
sake of other platforms, but macholib, py2app, and bdist_mpkg will 
forever be distributed in a single unit (unless of course some of it 
ends up in the standard library -- which hopefully at least 
altgraph/modulegraph will someday).

>> The problem with the Unix model is that processes only know how to
>> exchange raw data (sockets, pipes, files).  In lots of cases you want
>> to exchange a higher level representation of information, and there
>> aren't a whole lot of easy ways to do that.
>
> But there are ways. OpenDoc was built upon Apple events, for example. 
> And assuming you only have Python talking to Python then you don't 
> even need something that complex. It's not like there isn't prior art 
> to study and take ideas from.

I've never seen it done in Python really easily.  It's like programming 
with threads, people think it's easy, but then a piano falls on their 
head a couple hundred lines of code later cause they didn't truly 
understand what they were getting into.  There is certainly no standard 
library support for such a feature, other than marshal and pickle, but 
those are only formats for data exchange, they do nothing to help you 
exchange the data.

>> I'm pretty sure that these
>> large frameworks suffer from the same problem.  It's much easier to
>> exchange high level representations of data with yourself than it is 
>> to
>> exchange them with someone else..
>
> 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.

>> 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; if you don't keep that burgeoning complexity 
> under control then sooner or later the whole thing degenerates into a 
> big ball of mud. It's a great very-short-term strategy, but an 
> ultimately counter-productive stinker if you're planning to be in for 
> the long haul and fail to replace it ASAP.

Well yeah, you do have to clean up your mess every so often.

> 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', and to then throw that code away 
> and start all over again is anathema. Coming from a fine art 
> background, I _know_ that if you've a day to draw a life picture, then 
> the best way to spend that time is 'wasting' the first half on 
> throwaway sketches and only sitting down to the final version in the 
> final few remaining hours, not spend all day hammering away at this 
> one single drawing from 9 till 5.

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.

> You mention py2app, but must realise yourself that py2app's potential 
> for growth and improvement is itself ultimately constrained by the 
> framework you've built it in, i.e. distutils. And, conversely, 
> distutils' room for improvement is severely constrained by the need 
> not to rock the boat for those that have already built upon it. The 
> longer code is left to harden, the harder it will be to do anything to 
> change it later, so best spend as much energy as you can as early on 
> as possible to ensure that when it does set, it's not in a form you're 
> going to regret years from now. (Unless you're the perverse sort that 
> actively enjoys doing heroic total rewrites for the rest of your 
> life...:p)

Obviously you've not really looked much at the source of py2app.  The 
only part of it that is really bound to distutils is the "user 
interface".  It's done this way because it's a familiar interface 
(lower learning curve for developers with relevant experience) and it 
provides features that I don't have to implement on my own.  Command 
line parsing, extension building, etc.  Everything it does could be 
done by plugging all of its constituent components together without 
distutils, but there's no real good reason to do that.  I hope people 
don't start doing it this way though, because I am only willing to 
support the distutils interface.  I reserve the right to refactor the 
other layers without caring about compatibility with anything but 
itself.

-bob