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