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