Newbie switching from TCL

[Robin Becker]

In article <8o18no01svn at news1.newsguy.com>, Alex Martelli
<alex at magenta.com> writes
>"Robin Becker" <robin at jessikat.fsnet.co.uk> wrote in message
>news:0k4seKAxmAp5EwR8 at jessikat.fsnet.co.uk...
>> In article <8o0scj01hch at news1.newsguy.com>, Alex Martelli
>> <alex at magenta.com> writes
>> ....
>> etc etc etc etc; crappy === baroque === perl === win32 or is that too
>> pre-modernist.
....

I never said that select was the be all or end all of anything; I think
you inferred that. I was responding to the assertion that baroque can be
good. 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. 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. I
would like to use the same metaphor for any streamlike object.

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

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.

>It's, to be extremely nice to you, over-simplified to the point of
>ludicrousness.  You asserted that something couldn't be done
>(on a system you clearly know little about: it's wiser to avoid
>talking about systems one doesn't know well, _particularly_
>rich and complex ones); now, faced with the fact that, yes, of
>course it can be done (in several ways, at different levels:
>kernel, low-level COM, simplified higher-level COM/Automation,
>were three I showed), you seem to be retreating into
>name-calling against this sytem you dislike so much.
>
>I prefer simplicity; but I'd never be so foolish as to assert
>that something "can't be done" in Perl (for example), despite
>knowing it passably well, exactly because it's such a rich and
>baroque environment.
>
>In this specific case, there are reasonable justifications for
>some of the architecture's complexities.  COM, the main level
>of access to the system's functionalities, is not all-pervasive:
>in particular, it does not extend all the way down to the kernel
>and other very low-level subsystems, because those systems
>predate the invention and spread of COM architecture.  Quite
>similarly, no object-oriented or component-oriented approach
>will ever be all-pervasive in Unix systems, because the syscalls
>(which have been around for ages) will predate such a system.
>
>You either scrap the whole thing and restart from scratch, or
>take a vow against any architecture that wasn't around in '70,
>or resign yourself to having at least two different approaches
>to the same functionality.  The latter choice is no doubt the
>most sensible one in practice.
>
>COM itself tends to come in two layers: a lower one, optimized
>for speed; a higher one, easier to use, with some sacrifice of
>performance.  The latter is what you'd normally approach from
>such environments as Python, or Basic, but sometimes it can
>be quite handy that the lower-level is also exposed.  Do you
>consider Python 'baroque' or 'crappy' when it takes a similar
>two-pronged approach, e.g. the two (abstract and concrete)
>layers of calls in the C API?
>
>Of course, such two-pronged approaches are not always
>very well designed; IDispatch itself, the core of most 'higher
>level' COM architectures, has serious design flaws, for
>example.  Still, I consider 'events' one of the cases which
>were designed pretty well.
>
>
>If I were to recommend one uniform 'eventing' approach in
>Win32, in the abstract, it would be the higher-level COM one --
>the performance loss is slight, the uniformity rewarding.
>Only rarely, when really top performance or some peculiar
>requisite demands, may one have to dip lower.  Unfortunately,
>Python's win32com may not support this optimally; but that
>is another issue.
>
>What ever gave you the idea that support for 'select' is the
>end-all, be-all of 'eventing', or even a good design for
>general 'eventing' at all...?
>
>
>Alex
>
>
>

-- 
Robin Becker