Linux-Advocacy Digest #517, Volume #29 Sun, 8 Oct 00 08:13:07 EDT
Contents:
Re: Winvocates and Linvocates: What do you use your desktop OS for? (Pete Goodwin)
Re: Because programmers hate users (Re: Why are Linux UIs so crappy?) (Richard)
Re: Because programmers hate users (Re: Why are Linux UIs so crappy?) (Steve Mading)
Re: Why is MS copying Sun??? (Zenin)
Re: How low can they go...? ("JS/PL")
Re: Why is MS copying Sun??? ("JS/PL")
Re: Because programmers hate users (Re: Why are Linux UIs so crappy?) (FM)
----------------------------------------------------------------------------
From: Pete Goodwin <[EMAIL PROTECTED]>
Crossposted-To: comp.os.ms-windows.nt.advocacy
Subject: Re: Winvocates and Linvocates: What do you use your desktop OS for?
Date: Sun, 08 Oct 2000 09:07:57 GMT
In article <[EMAIL PROTECTED]>,
Gardiner Family <[EMAIL PROTECTED]> wrote:
> What a load of rot, there is tonnes of applications such as
StarOffice,
> Netscape, the 1,000s of GNU applications being/have developed, and
games
> for Linux, Simcity 3000, Quake, Doom and other verious titles. I think
that
> the old wives tale that there is not enough apps or games for linux
has run
> its course!
Can you get every game for Windows on Linux? No you can't.
It's not an old wives tale, its the truth!
--
---
Pete
Coming soon: Kylix!
(I do not need the destruction of Microsoft to succeed).
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Richard <[EMAIL PROTECTED]>
Subject: Re: Because programmers hate users (Re: Why are Linux UIs so crappy?)
Date: Sun, 08 Oct 2000 09:21:53 GMT
Steve Mading wrote:
> Question: Does Smalltalk have security mechanisms to make certain
> methods only usable by some objects and not others? (I'm not
> familiar with it, so I'll have to trust whatever you say here).
No, it does not. If Smalltalk did and did so in a clean manner then
it would be an Operating System. (This is easier to see in Self.)
> : You are correct, that "feature" is absent in Smalltalk. And good riddance!
> : Why the hell would I *want* to switch from a programming mindset to an
> : algebraic mindset in the middle of programming ??
>
> Because it *IS* math, duh. Notice the example I gave? It *WAS*
> an algebreic expression. To make it work any way other than in
> algebreic precidence is silly.
No, it's not. I'm working towards a math degree and I can tell you that I
do *not* want to do math when I program. The two activities are very
different and the mindsets required are disjoint. I don't want to have
to switch between them just because some people are too lazy to put
brackets or switch the order around so that an algebraic expression
evaluates correctly.
OTOH, mathematicians don't care about evaluation order or arithmetic.
Some of them forget how to count!
> It should be trivially obvious to everyone except the most egotistical
> prick that one's own judgement of whether or not a feature is
> *useless* is going to be heavily laced with predjudice and emotion.
I'll agree on the emotion but not the prejudice.
> *I* am the one that gets to decide in a feature is useless in my
> program, not the language designer.
Using multiple completely different languages is vastly
superior to using a single Frankenstein's monster to do
everything. If your application requires different styles,
paradigms, or inconsistent sets of features then it also
requires completely different mindsets when you go to
implement and understand your code. Why not express this
by writing it in different languages? So long as each
language is clean internally, I have absolutely no problem
with that (and it is on that basis that I dispute your
claim above that language choice is laced with prejudice).
To my mind, it could only promote modular thinking since
the features of one language aren't going to interact
with the features of another language in unexpected ways!
> I despise languages where the language designer had the hubris to
> assume that he can think of everything that could ever possibly
> be useful to do, and therefore provides no mechanism to break out
> of the limiting shell he builds for programmers. (Case in point:
> Pascal with it's use of features that it refused to pass on to
> users of the language. - Note how writeln() has varying args, yet
> you can't make your own varying arg functions in Pascal.)
I agree completely. Smalltalk attempts to give users all the features
it uses. In Squeak, you can even extend the VM with your own
primitives.
> Can you write Smalltalk in Smalltalk? If not, then it's such a
Already been done. Squeak Smalltalk is written entirely in Smalltalk.
> hubris-laced language. If you can, then I'll have to consider
> looking into it.
http://www.squeak.org
If you're going to code in ST though, get a dialect with a port
of the Refactoring Browser.
------------------------------
From: Steve Mading <[EMAIL PROTECTED]>
Subject: Re: Because programmers hate users (Re: Why are Linux UIs so crappy?)
Date: 8 Oct 2000 09:32:40 GMT
FM <[EMAIL PROTECTED]> wrote:
: Steve Mading <[EMAIL PROTECTED]> wrote:
:>I despise languages where the language designer had the hubris to
:>assume that he can think of everything that could ever possibly
:>be useful to do, and therefore provides no mechanism to break out
:>of the limiting shell he builds for programmers.
: I hate it even more when the design of a language is
: made without regard to extending the language, and then
: proceeds to provide extension mechanisms that so
: obviously break the conceptual model of the language
It would be nice if this were possible while maintaining
speed, but I've yet to see a language that can parse itself
at runtime without being an interpeted rather that
compiled language. (For example, perl can do "eval" on
a string, but this can't (as far as I know) be done in a
compiled language). Ideally, What would be nice for
operater overloading would be the ability to MAKE new
operators of your own. I think this was avoided in C++
purely for impelentation reasons (It requires that the
syntax scanner be dynamically malleable, for example
if you want to make a "@" operator, you'd have to tell
the scanner to change its behavior, and it would have to
do so halfway through the compile (at the moment the
compiler saw the declaration of the new "@" operator, it
would have to start tagging it as an operator). Now,
allowing identifiers as operators would be a good idea
Basicly there are three types of operators you could
make - binary, infix, and postfix. These could be implemented,
but it would be hell on the parser. (Is this valid
syntax: "id1 id2 id3" ? well, if id2 refers to a binary
operator it is, else it isn't...)
So, the reason, I would guess, for picking only the
built-in pre-existing operators in C++ for operator
"methods" was that it relieves some of the pain of
implementing the compiler. "a + b" is always going to
be valid syntax, regardless of what "+" means.
Also, there's the problem of precedence. To make
homemade operators work, there would either have to
be a way to let the programmer define the operator's
precedence, or the language would have to ignore all
precedence and do everything left-to-right. The second
solution (which is what I gather Smalltalk does from
what Richard said) is distasteful to me because it
diverges from the way we've been educated to view math
expressions (It seems "icky" to have a language that
does 2+3*x in the wrong algebraic order. It means I'm
going to have to insert a heck of a lot of parentheses
in any nontrivial expression.)
: (C++/Operator Overloading/Function Pointers/Etc). I guess
: I can understand in case of C++, which in some subtle way
: assumes that the class library designers are much better
: programmers than users of these libraries and allow ways
: to encapsulate much of the ugliness of the language in
: classes (the process of which also happens to be ugly),
: thereby freeing the less experienced programmers from the
: burden of dealing with C++'s low-level details.
:>(Case in point:
:>Pascal with it's use of features that it refused to pass on to
:>users of the language. - Note how writeln() has varying args, yet
:>you can't make your own varying arg functions in Pascal.)
: Actually, your real complaint in that case is that the
: language has primitives with priviledges that fundamentally
: distinguish them from user-defined abstractions.
Well, using purely theoretical terminology, that's what I
don't like, but I don't like the theoretical terminology
because it tends to ignore real-world problems that it
is folly to forget about. In the real world, it is necessary
to have the language implementation at some point reach the
actual bare metal. Otherwise the whole excercise is pointless.
So it's inevitable that there will be some sort of a wall
between "stuff the language implementer can do" and "stuff
a user of the language can do". What I don't like is when
a language puts too much stuff on the "implementor" side of
the wall instead of the "user" side of the wall. It's
inevitable that there will be *some* stuff on the implementor
side of the wall, and it should be on that side of the
wall for a good reason. I consider "is hardware dependant",
for example, to be a good reason to put something on the
implementor side of the wall, but I don't consider, "Treating
the programmer like a baby" to be a good reason to take away
power from him.
: At some
: level it's inevitable, though some languages make it far
: more obvious than would be useful. It would be akin to C++
: allowing something like "cout << x" and not allowing one to
: use/define such operators in analogous, but distict
: contexts. But on the other hand, consider the extent of
: ugliness C++ went to allow this in many aspects of the
: language and how that would fit into Pascal, which as far
: as I know, was designed to be a rigid and simple language.
:>Can you write Smalltalk in Smalltalk? If not, then it's such a
:>hubris-laced language. If you can, then I'll have to consider
:>looking into it.
: It's absolutely trivial (from a theoretical perspective) to
: "implement" a turing-complete language in another turing-
: complete language.
That's true, but in some languages it's going to be needlessly
inefficient. (Because you spend time fighting the language
instead of getting the job done. (For example, implementing
Pascal's writeln() as a varying argument function in C would
be much simpler than implementing it in Pascal.) )
------------------------------
From: Zenin <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.ms-windows.nt.advocacy,comp.arch,alt.conspiracy.area51,comp.os.netware.misc,comp.protocols.tcp-ip,comp.lang.java.advocacy
Subject: Re: Why is MS copying Sun???
Date: Sun, 08 Oct 2000 09:53:11 -0000
Simon Cooke <[EMAIL PROTECTED]> wrote:
: "T. Max Devlin" <[EMAIL PROTECTED]> wrote in message
:> Pretty pathetic, isn't it. WINE can't even get a fucking NOTEPAD to work
:> correctly. Sounds to me like Win32 is a complete piece of shit, and MS
:> ought to be taken out and shot just for pretending its a useable API.
:
: Sounds to me like WINE's developers don't know their arses from their
: elbows. Win32 is perfectly usable -- you just have to take the time and
: energy to understand it.
The *documented* parts of Win32 are well covered...it's the
*undocumented* parts which have caused WINE developers extreme
pain. You'll note that from small (notepad) to large (MS Office),
MS applications are of course the most common abusers of such
undocumented "features"...which is why MS applications have
traditionally been the hardest to get running correctly under tools
like WINE.
How well WINE does or doesn't run Windows applications has no
relevance on the design quality of the Win32 API...it only has
relevance with regards to MS's underhanded business practices.
--
-Zenin ([EMAIL PROTECTED]) From The Blue Camel we learn:
BSD: A psychoactive drug, popular in the 80s, probably developed at UC
Berkeley or thereabouts. Similar in many ways to the prescription-only
medication called "System V", but infinitely more useful. (Or, at least,
more fun.) The full chemical name is "Berkeley Standard Distribution".
------------------------------
From: "JS/PL" <[EMAIL PROTECTED]>
Crossposted-To:
comp.lang.java.advocacy,comp.os.ms-windows.advocacy,comp.os.ms-windows.nt.advocacy
Subject: Re: How low can they go...?
Date: Sun, 8 Oct 2000 07:01:43 -0400
Reply-To: "JS/PL" <[EMAIL PROTECTED]>
"Mike Byrns" <"mike.byrns"@technologist,.com> wrote to T. Max Devlin
> You are irrational and inflammatory. Votes on this from COMNA? Cmon
folks who
> thinks Max is irrational and inflammatory?
Got my vote.
------------------------------
From: "JS/PL" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.ms-windows.nt.advocacy,comp.arch,comp.lang.c
Subject: Re: Why is MS copying Sun???
Date: Sun, 8 Oct 2000 07:04:42 -0400
Reply-To: "JS/PL" <[EMAIL PROTECTED]>
"T. Max Devlin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Said JosB in comp.os.linux.advocacy;
> [...]
> >I still consider Novell Netware superior to MS windows NT/2000.
> >But that is pure the Fileserver and printserver part.
> >And perhaps for Oracle databases.
> >
> >NT is probably still a better application server. :-(
>
> I don't know about you, but when I hear the term 'application server', I
> mostly think of Oracle databases, or X clients programs.
That's because your an idiot.
------------------------------
From: [EMAIL PROTECTED] (FM)
Subject: Re: Because programmers hate users (Re: Why are Linux UIs so crappy?)
Date: 8 Oct 2000 11:16:04 GMT
Reply-To: [EMAIL PROTECTED]
Steve Mading <[EMAIL PROTECTED]> wrote:
>FM <[EMAIL PROTECTED]> wrote:
>: Steve Mading <[EMAIL PROTECTED]> wrote:
>:>I despise languages where the language designer had the hubris to
>:>assume that he can think of everything that could ever possibly
>:>be useful to do, and therefore provides no mechanism to break out
>:>of the limiting shell he builds for programmers.
>: I hate it even more when the design of a language is
>: made without regard to extending the language, and then
>: proceeds to provide extension mechanisms that so
>: obviously break the conceptual model of the language
>It would be nice if this were possible while maintaining
>speed, but I've yet to see a language that can parse itself
>at runtime without being an interpeted rather that
>compiled language.
It can be accomplished by providing a sufficiently
knowledgeable macro facility that understands the
syntactic structure of the language.
>(For example, perl can do "eval" on
>a string, but this can't (as far as I know) be done in a
>compiled language). Ideally, What would be nice for
>operater overloading would be the ability to MAKE new
>operators of your own. I think this was avoided in C++
>purely for impelentation reasons (It requires that the
>syntax scanner be dynamically malleable, for example
>if you want to make a "@" operator, you'd have to tell
>the scanner to change its behavior, and it would have to
>do so halfway through the compile (at the moment the
>compiler saw the declaration of the new "@" operator, it
>would have to start tagging it as an operator). Now,
>allowing identifiers as operators would be a good idea
>Basicly there are three types of operators you could
>make - binary, infix, and postfix. These could be implemented,
>but it would be hell on the parser. (Is this valid
>syntax: "id1 id2 id3" ? well, if id2 refers to a binary
>operator it is, else it isn't...)
Well, not only that, in C++, operators are delimiters.
a+5 is a valid expression but I don't see how one can
make dabc4 parsed to mean d abc 4, if abc was an
operator. Besides, operators can be viewed as syntactic
conventions in C++ so I'm not sure if it would be useful
to introduce more operators. But it sure as hell hurts
my eyes to see how C++ distinguishes between postfix
unary and prefix unary operators for overloading.
>:>(Case in point:
>:>Pascal with it's use of features that it refused to pass on to
>:>users of the language. - Note how writeln() has varying args, yet
>:>you can't make your own varying arg functions in Pascal.)
>: Actually, your real complaint in that case is that the
>: language has primitives with priviledges that fundamentally
>: distinguish them from user-defined abstractions.
>Well, using purely theoretical terminology, that's what I
>don't like, but I don't like the theoretical terminology
>because it tends to ignore real-world problems that it
>is folly to forget about.
No, they are not awfully theoretical. They are a bit
abstract, but such is the matter we're dealing with
here.
>In the real world, it is necessary
>to have the language implementation at some point reach the
>actual bare metal. Otherwise the whole excercise is pointless.
>So it's inevitable that there will be some sort of a wall
>between "stuff the language implementer can do" and "stuff
>a user of the language can do". What I don't like is when
>a language puts too much stuff on the "implementor" side of
>the wall instead of the "user" side of the wall. It's
>inevitable that there will be *some* stuff on the implementor
>side of the wall, and it should be on that side of the
>wall for a good reason. I consider "is hardware dependant",
>for example, to be a good reason to put something on the
>implementor side of the wall, but I don't consider, "Treating
>the programmer like a baby" to be a good reason to take away
>power from him.
So the ideal language would really be a meta-language
of its own. I don't think it gets much better than
Lisp.
>:>Can you write Smalltalk in Smalltalk? If not, then it's such a
>:>hubris-laced language. If you can, then I'll have to consider
>:>looking into it.
>
>: It's absolutely trivial (from a theoretical perspective) to
>: "implement" a turing-complete language in another turing-
>: complete language.
>
>That's true, but in some languages it's going to be needlessly
>inefficient. (Because you spend time fighting the language
>instead of getting the job done. (For example, implementing
>Pascal's writeln() as a varying argument function in C would
>be much simpler than implementing it in Pascal.) )
There's a difference between implementing a language from
the scratch and implementing parts of a language with other
parts of the language. You can't implement writeln() in
Pascal without Pascal just as you can't implement printf()
in C without C. Then the matters comes down to whether some
parts of the language can be implemented in other parts of
the language and are indistinguishable from user-defined
abstractions. Or conversely, whether you can write user-defined
abstractions that work exactly like built-in primitives. It
doesn't get much better than Scheme, IMO, and this point
really doesn't help C++ at all. I'd imagine that Smalltalk
beats C++ in this respect as well, though I could easily be
wrong. C++ has way too many features that simply were not
designed to be extended, and then a whole bunch of features
were added to make some of them more extensible, and you get
a horribly inconsistent language that is only somewhat
extensible. Many features in C++ are still completely ad-hoc
and work at a level unreachable by user-level abstractions.
Dan.
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.advocacy) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Advocacy Digest
******************************
