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
_______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
