Charles Hartman wrote:
So an environment (in the vernacular, not the Unix sense) is what the beginner needs -- an IDE from within which everything you need to do can be done, and not dangerously much else. But if the IDE is complete enough for this beginner to work in, isn't it likely to be a reasonable place for someone to work who knows more, too?
I think Joel Spolsky hits on the broader problem when talking about bloat vs features <http://www.joelonsoftware.com/articles/fog0000000020.html>:
"80% of the people use 20% of the features. Unfortunately, it's never the same 20%."
Thus we end up with big, extremely complex programs like MS Word, and the first thing new users have to do is to determine all the bits that they can simply ignore so they can concentrate on learning the bits they actually do need. Uber-geeks may enjoy the feeling of absolute control that comes from having more buttons and knobs at hand than they can count, but us ordinary schmoes just drown in that crap. 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?
My preferred IDE architecture would be built on a completely component-oriented architecture. That way it can ship with the minimal components required to get started, and users can add, upgrade and remove components as and when they need them. For example, a new user needs everything visible so they can see what's available; an experience one may prefer everything driven by memorised keyboard combinations so they can devote screen estate to more important things like their code instead of floating palettes, on-screen help, etc.
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. And it allows individual features to develop at their own rate, so you're not stuck with the perpetually 'almost-there-but-not-quite' situation that somebody else mentioned.
Python's myriad web frameworks are in exactly the same situation, btw: they should be building smaller and simpler for greater flexibility and custom assembly, but instead seem only to build bigger and more complex with major lock-in and the result is systems that only their existing long-time users want to use because the cost of mastering one of these monsters has grown so high as to deter newcomers. Who then turn to simpler, less powerful systems, master those, and then complain about the lack of features until they too evolve into the same monolithic giants that they'd rejected in the first place.
I've never understood what the obsession with building every conceivable feature into the application core, least of all when it's coming from unix folks who really should know better. The central tenet of Unix design philosophy is to build small, interchangeable, single-purpose components that can be easily assembled into whatever form the user needs. So I see this as just sensible design, and the fact that it happens to scale well to fit lots of different user requirements is an added plus. And I despair when I see all these other unix-raised OSS folk rushing in the exact opposite direction, and am at a loss to understand what they're thinking.
HTH
has
--
"Oh, cut the bleeding heart crap, will ya? We've all got our switches, lights, and knobs to deal with, Striker. I mean, down here there are literally hundreds and thousands of blinking, beeping, and flashing lights, blinking and beeping and flashing - they're *flashing* and they're *beeping*. I can't stand it anymore! They're *blinking* and *beeping* and *flashing*! Why doesn't somebody pull the plug!"
_______________________________________________
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
