Newbie switching from TCL

[Alex Martelli]

"Robin Becker" <robin at jessikat.fsnet.co.uk> wrote in message
news:WMCNkKAOfDp5EwGf at jessikat.fsnet.co.uk...
    [snip]
> I never said that select was the be all or end all of anything; I think
> you inferred that.

Yep, from the apparent induction you asserted 'win32 can only do select
on sockets' ->'win32 is no good at I/O eventing'.  This would only
follow IF one believed select was somehow 'the' privileged way to
do eventing on I/O.

> I was responding to the assertion that baroque can be good.

Who made that assertion which you were responding to?  It was
not made on this thread.  I easily might make it (Johann Sebastian
Bach on my left side, Georg Friedrich Haendel on my right side,
Antonio Vivaldi in front of me, Benedetto Marcello behind me...),
but when did the discussion turn to music?

> I use select only because it's in python for sockets. In win32 Tcl
> I used the event model which relied on threading to do the notification.
> I regard that as rather strange especially since as you so helpfully
> point out there are dozens of ways to do it.

Tcl's architects may have chosen that architecture for portability
reasons.  There may be a few ways to do general eventing on
System V, a couple more to do it on BSD, a few more to do it
in VMS, yet others for Win32, MacOS, BeOS, etc, etc -- but if
you want to use a single architecture and do a decent job of
covering them all, you're probably left with auxiliary thread[s]
as maybe the only choice that stands a chance.

> I think M$ failure to
> capture the hearts and minds of people like me who have been programming
> for a long time is the very baroqueness which you regard as good.

Please quote specifically the sentence, which you appear to think
I've written, where I state I regard 'baroqueness' as 'good' in any
IT architecture.  I have, of course, never written anything of the
kind, but I'm curious to see if your misunderstanding is in any
way explainable, or if you're just being deliberately perverse, as
I'm starting to suspect.

Personally, however, I believe that MS's failures regarding the
"capturing of hearts and minds" stem from very different sources
than the undeniable complexity of many of their architectures.
Proof: when they DO come up with a good architecture, some
people keep fighting it blindly anyway, just BECAUSE it comes
from Microsoft -- and their blind hate of Microsoft takes pride
of place over any other consideration.  If they've been around
long enough, they probably hated IBM with identical fervor 20
years ago.  Don Box, once MS-hater, has written a good piece
about how he had to recant (and how hard it was) when his
nose got rubbed into COM and he finally had to admit to himself
that it was a truly brilliant architecture -- he's now acknowledged
as #1 guru of COM and related matters.  (Other MS-haters, at
mozilla.org, are faithfully copying COM as their component
architecture -- ever heard "imitation is the sincerest form of
flattery"?-).

> I would like to use the same metaphor for any streamlike object.

As I keep repeating, nothing stops you from doing so in
Windows -- at whatever level you need to program.  From
kernel-or-close to it calls (the uniform metaphor at that
level is 'overlapped IO', with 'IO completion routines' that
you can supply and the system will call back when the I/O
operation has finished), all the way up to high-level access
quite suitable for scripting languages such as Visual Basic
and Python (the uniform metaphor at that level is COM events,
for which you may register event-handlers, that are the
high-level equivalent of called-back routines).

It just so happens that none of these 'uniform metaphors'
that Windows offers (for event-driven I/O processing) is
particularly close to 'select'; the latter is offered on Windows
only for compatibility with BSD sockets.  Python support
is also a concern (there are some issues with COM events
in Python's win32com, and I don't know whether win32all
supports overlapped I/O with completion routines at all),
as is portability of the various architectural approaches you
could take (few systems, apart from VMS and Windows,
have good support for asynchronous callbacks on I/O
completion, for example).  But such concerns are not valid
criticisms of Windows regarding event-driven I/O.


> I'm already suffering from information overload and the fact that
> someone can bring out a book with hundreds of hidden api calls for Win
> 2000 should really raise a flag. Most people have an every day
> vocabulary in hundreds. An OS with hundreds or thousands of entry points
> is too complicated.

If you count all un-documented, non-architected, 'hidden' as you
say, entries, I doubt any substantial operating system of today
has fewer than 'hundreds of entry points' (system-calls, or kernel
API's, whatever the nomenclature).  But, save for special needs,
one's applications shouldn't be using such low-level entries
anyway; that's what frameworks and libraries are for.

> I program win32 on the surface because that's the
> bit most likely to stay sane and stable. I have been undone by Mr Gates
> many times before and expect future problems.

COM is the level I prefer, and I expect it to remain pretty well
supported even as the preferred architecture migrates to .NET
over the next few years.


> It's very strange, but every time I'm in a university computing
> department they laugh at and make jokes about Bill, when I meet
> commercial computer people they don't have the same attitude. It's
> probably a money thing.

Funny, I've heard just as much laughter and jokes in commercial
development shops.  From my personal observation, and I've been
a university professor as well as a commercial software architect,
the key motivation of the best technical people is always the same:
the underlying fascination with this technology and its implications.
Money, academic accolades, and other external indicators of one's
success, are neat, sure -- but they are never the primary motivators
for those people who'll make a real difference.


Alex