[Pythonmac-SIG] Mac User Python Newbies

[has]

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


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


>  > Python's myriad web frameworks are in exactly the same situation, btw
>
>I think WSGI (pep 333) is a good step to fixing this problem.  If you
>target WSGI, at least you can shoehorn your app into a giant framework
>when you need one.

If I understand it correctly, WSGI decouples the app framework from 
the web server, which is a good thing in itself. It doesn't do 
anything to address the pathological kitchen sink-ism within the rest 
of the web-app framework, however. I think you'd need a chainsaw for 
that.


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


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


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

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.

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)

IDEs are exactly the sort of problem that's crying out for exactly 
this sort of hard, hard tearing down and rebuilding approach because 
right throughout their lives there's going to be this strong 
requirement to add new features, specialist tools, remove obsoleted 
tools, replace, extend, rebuild, etc. One really good, extensible IDE 
application framework and we might not be in this foolish situation 
where there's a dozen all "nearly done" IDEs, all with a huge amount 
of overlapping functionality, which means duplication of effort; i.e. 
a waste of time and energy.

Folk seem to acknowledge there's a constant underlying problem at 
work, so why don't they spend more time trying to put that right 
instead of reinventing the same old mistakes as before? It should be 
a wonderfully rich and tasty problem for those that fancy the 
exercise, and I'm sure there's folk that would; maybe not as 
instantly glamorous as "oh look I just made a yet-another-editor", 
but no passing flash in the pan either if/when they manage to pull it 
off.

Cheers,

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