[Pythonmac-SIG] Mac User Python Newbies

[Bob Ippolito]

On Feb 14, 2005, at 12:09 PM, has wrote:

> 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?

Maybe because in many cases, the users are the developers and adding 
those 20%s together makes for some big ugly mess.

> 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.

I think Eclipse is intended to be like this -- though I can't say I 
have real experience using 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. 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.

Personally, I hope that developers See The Light and do interface 
building in a separate but integrated application like Xcode and 
Interface Builder.  If for no other reason than it's simply not 
possible to integrate a Tkinter GUI builder inside of a wxPython IDE or 
vice versa.  Without this separation, all of the features of the IDE 
*are* locked into a particular event loop.

> 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 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.

> 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.

I think this is largely caused by complexity of the alternative and the 
convenience of doing it in this way.

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.  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..  that, and it's much easier to design 
something ad-hoc if you don't concern yourself with keeping things 
modular.

The design of py2app definitely exhibits the "large core" issue as part 
of its development cycle.  In order to add a particular feature I'll 
add whatever code is necessary to make that happen.  After I've used it 
a while I'll figure out how to pare it down and modularize it into 
something more generally useful and distinct from everything else going 
on.  The alternative is to do more design up front (try to guess what 
you'll want to use it for and how) which means spending all your time 
thinking instead of writing usable code.

-bob