RE: [GD-General] Eiffel

[Philip H. <ph...@me...>]

> Unusable UI (just try getting a decent window manager/GUI on
> Windows...), excessive difficulty or inability to=20
> tailor/replace to personal preferences (eg I don't allow=20
> icons on any system I run), poor process model (eg no=20
> UI-exposed generic process IPC/sequencing ala forks/pipes),=20
> unusable shell (even Cygwin's bash is crippled), CLI opaque,=20
> single-user, intransigent authentication schema, poor interop=20
> and integration with foreign systems (eg NFS, AFS, LDAP,=20
> Kerberos, PAM, etc), fundamentally broken SMTP support (list=20
> owner beef), interop unfriendly internal security semantics=20
> (eg ACLs on dirs not files), end results of=20
> embrace-and-extend run rampant, incompleat syscall interface,=20
> broken/unreliable POSIX supports, consistent and uneditable=20
> RFC violations, network opaque at the host and GUI and=20
> application level, poor tools (that (X)Emacs even runs is a=20
> miracle), untrustable kernel, difficult and unfriendly to=20
> automation, monolithic unified opaque API interfaces, code=20
> porting unfriendly, resource consumptive, operation requires=20
> you to put your body in front of the machine (side effect of=20
> being network opaque), consistent assumption that the user=20
> will work and operate in the manner and with approaches=20
> envisioned by MS (I don't).

That's a great list of problems with Windows but the majority if not all
of them only apply to 99.99% of users. The fact that the kernel is
untrustable and that is has an incomplete syscall interface makes no
difference to my productivity and I spend roughly 75% of my time
developing software.

> and ease of building new tools.  We're engineers -- that's
> what we do: build and use tools.  Windows tends to assume=20

That's not how I see it at all, yes we use tools, we probably build our
own tools as well, but they are just tools. What matters is the results,
specifically are they the results our customers want. I really don't
care whether the cabinet maker has his own tools are simply uses his
teeth, all I'm interested in is whether the cabinets are good and can he
deliver what I've ordered when he says.

Now if Windows actually stops you producing those results then that's a
problem but for the majority of people that is not going to be the case.
The work I do (and I'm sure this applies to a lot of people, even if you
aren=92t one of them) the vast majority of my time is centered around
solving a problem. At the moment it's behaviour AI and the solution does
not depend on Windows and Windows has no effect on how efficiently I
solve that problem. Nor do the tools for that matter, C++ affects the
implementation but actually solving the problem and getting the
behaviour I want has nothing to do with OS or language or tools or RFC
compliance.

Once I have the solution I'm going to sit down with my editor and write
some code. Windows still isn't going to get in the way. If I was using
Emacs under UNIX the process would be virtually the same.

I'm guessing that you do a lot of UNIX system level type stuff in which
case Windows isn't going to provide what your looking for but then it
isn't supposed to. But that doesn't make Windows "excessively difficult
to be productive under".

Phil