[Pythonmac-SIG] Mac User Python Newbies

[has]

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!"