Linux-Advocacy Digest #265, Volume #29 Fri, 22 Sep 00 16:13:05 EDT
Contents:
Re: filename extensions are NOT a kludge (Richard)
Re: Linux to reach NT 3.51 proportions in next 2 years ("Yannick")
Re: Because programmers hate users (Re: Why are Linux UIs so crappy?) ("Yannick")
Re: filename extensions are NOT a kludge (Donovan Rebbechi)
Re: [OT] Tholen & Global warming. (was Public v. Private Schools) (Jack Troughton)
Re: Linsux as a desktop platform (=?ISO-8859-1?Q?Lars_Tr=E4ger?=)
Re: Because programmers hate users (Re: Why are Linux UIs so crappy?) (Richard)
Re: angry programmers (Richard)
Re: Implications ([EMAIL PROTECTED])
Re: hypocritical Unix apologists (Richard)
Re: Because programmers hate users (Re: Why are Linux UIs so crappy?) (Richard)
----------------------------------------------------------------------------
From: Richard <[EMAIL PROTECTED]>
Subject: Re: filename extensions are NOT a kludge
Date: Fri, 22 Sep 2000 19:16:24 GMT
Donovan Rebbechi wrote:
> On Fri, 22 Sep 2000 08:44:43 GMT, Richard wrote:
> >That is so fucking hilarious. I don't even believe it's possible
> >to be OO in C++ because you'll always end up making mistakes (if
>
> What do you mean ?
I mean that programming in a language that doesn't impose OO,
you'll find yourself using shortcuts that break OO. You'll also
give up on OO much faster even if ultimately there is a perfectly
OO design that would simplify the programming.
Just look at the design of dtfs. Assuming the paper is accurate,
the design is crap. It's not even properly *modular* let alone OO.
Geez, at one point he says that low-lewel physical addresses are
needed in the higher layer "for efficiency" and later on he says
that efficiency doesn't matter because it's a research project.
Great, so not only did he break layering, but he broke it for no
reason.
> >if you have to waste brain power making your code OO then you will
> >have that much less to spend on high-level architectural issues.
>
> You don't "spend brain power on making your code OO". You do your
> "high level design" and "architecture", and then if your design
> requires the use of OO, you go and code it.
Do you seriously believe in the Cascade model of the development
cycle? Architecture is different from design btw, so first you
do your architecture then you do the design and /then/ you code
it. Sometimes architectural changes are made at design or coding
time; bad practice but it happens. And in any case, how are you
supposed to keep the architecture in mind, first and foremost, when
you have to bother figuring out the OO design? Additionally, people
are going to cut corners, and I'd rather they cut the design phase
than the architecture phase. That's what I ended up doing because
I can keep the design in my head. <- note that this is *not* the
same as "you go and code it" since I'm incapable of coding anything
until I know exactly how the methods are all going to interact; I
certainly go through a separate design phase, it just happens all
in my brain. I wouldn't be able to do that in a language that didn't
take a lot of the load off my shoulders.
That I have Doorways as gatekeepers to Rooms, that these Doorways
can be of type {Portal, Door} X {Higher, Even, Lower}, that they
pass along messages as well as spawn new Doorways, this is all
architecture. That Doorways contain Type and Direction objects and
that they split the createDoorway message into spawnThisDoorway
and spawnThatDoorway because that's the only way to keep all of the
logic where it belongs; this is all design. And yeah, it takes quite
a bit of effort to make sure it is OO and elegant; it's not intuitive
that using the passTo method instead of reimprementing it is the
right way to go when its signature is
#passTo:selector:closePerms:distantPerms:topology: and the second
argument is a symbol even longer than the passTo's signature and the
passTo seems to send a gratuitous #perform message. You have to
understand that the compiler *will* be able to take out the perform
at compile time and that by reimplementing the functionality you
need from passTo you would redo *all* of the passTo's functionality.
And it certainly isn't intuitive that you should have separate
spawnThisDoorway and spawnThatDoorway methods when Portals do
the exact same thing for both, Doors do only slightly different
stuff, and I've already got a dozen methods all required for
"only" linking rooms together and that by considering the two
cases separately, I've just doubled the number of things I have
to keep straight in my head. This is all *design* and /not/
coding.
Claiming nowadays that you don't "need" OO and can get away with
using an imperative language is like someone claiming a couple
decades back that they don't need "high-level" imperative languages
and that they can get away with structured programming! Imperative
programming is obsolete.
------------------------------
From: "Yannick" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.ms-windows.nt.advocacy
Subject: Re: Linux to reach NT 3.51 proportions in next 2 years
Date: Fri, 22 Sep 2000 19:21:35 GMT
Mike Byrns <[EMAIL PROTECTED]> a �crit dans le message :
[EMAIL PROTECTED]
> Why stick with these two dimensional desktop metaphors anyway?
> PARC-style desktops are not the be all and end all of human-computer
> interaction. I'd like to navigate into folders like I walk into a room
> in Unreal Tournament. I'm not saying that it should look like that but
> the concept of being able to "look around" with the mouse while going
> forward and backward with the arrow keys (of the mouse wheel maybe :-)
> is so natural. Imagine navigating "up" over a landscape or some such
> construct and getting a "higher view". You see something that by rough
> shape, color or other attribute discernible from a distance, interests
> you. You move the mouse to "look" at it and move towards it. As you
> get closer more information is displayed progressively until you can
> either dive inside it (if it's a container) or it opens if it's not.
I'm not against the concept myself. There _is_ a potential in a 3D
representation of things. But when I try to imagine it, I sort of get a
virtual headache (especially with room-oriented things). Though that's not
an aversion for 3D virtual worlds, since I'm used to first-person games, but
if you have played such games you know that it's easy to get lost in some
places. Organizing data in a 3D way surely has potential, among which the
power to shorten the distance between data. But I think that using a
building-like 3D representation of data has to go along with a new
organisation of the data itself to take advantage of the new possibilities.
As for the landscape view, it might be cool in general (not necessarily
using a landscape view, the good old folder tree view could
be enhanced) to have some more global info using colors or whatever about
closed folders, for instance. (Something to show the size of the folder, or
the main type of its contents, or whatever. See what I mean ?)
Yannick.
------------------------------
From: "Yannick" <[EMAIL PROTECTED]>
Subject: Re: Because programmers hate users (Re: Why are Linux UIs so crappy?)
Date: Fri, 22 Sep 2000 19:21:36 GMT
Nigel Feltham <[EMAIL PROTECTED]> a �crit dans le message :
8q29hn$e50kt$[EMAIL PROTECTED]
> So my win95 system must also be broken then as when I open a shell
> (command.com) and type :-
>
> note.txt
>
> it is not auto changed to
>
> notepad.exe note.txt
>
> it also doesn't just open notepad with note.txt loaded.
>
It does not work with Win9x's command.com, but it works with Windows NT's
cmd.exe. I think it uses the default association for the file (i.e. the
default action, since you can attach several actions to each file type).
Besides, on WinNT, you can enable auto-completion by changing an entry in
the registry. (Though why this is not enabled by default or available as an
option I still wonder).
> >IOW, I don't think that associations belong in the GUI.
>
> Where is that MS shell file association config file again?
It's in the registry. The registry is not necessarily part of the GUI, in
MSDN library it is under "base services"... Not that it makes much
difference, but still...
> Doesn't KDE do this (at least partially) - I know it does reopen any
> applications
> that were open at last logout but I am not sure if files in those
> applications are
> also reopened.
OS/2 did quite the same, IIRC. They had a concept of open objects that would
reopen on reboot. Windows does this for its own explorer windows. As for
other apps, reopening them would not be difficult. Making them reopen the
file could be tricky without adapting the apps, but it wouldn't take much to
modify the apps. After all, it is on this point a similar problem for KDE.
> There is one good reason why the programmers write linux to work the way
> they want - it is because
> they are the ones who are going to be using it, at least to start with so
> why would they write something
> that doesn't fit the way they want to use their machines?
That's all right if they are aiming at themselves. They should take care
however, so that developing for their particular case won't prevent them
from opening up to other users and/or machines (because seemingly
unimportant restrictions in the initial design could become burdens in a
wider scope).
Yannick.
------------------------------
From: [EMAIL PROTECTED] (Donovan Rebbechi)
Subject: Re: filename extensions are NOT a kludge
Date: 22 Sep 2000 19:22:09 GMT
On Fri, 22 Sep 2000 08:31:19 GMT, Richard wrote:
>Donovan Rebbechi wrote:
>IF you understand what weak typing means, why
>it is important and why an OS must be weakly-
>typed
This is not about weak typing. This is about gratuitous
overloading, and using the same operation to perform two
very different functional tasks. This is error prone.
I don't see how you can sit there and deny the fact that
allowing the user to accidently change types while trying to
rename is not error prone.
>how proper typing is the *same* operation as
>naming THEN the first solution is more elegant.
I disagree. Again, it's error prone.
This is the main reason why I disagree.
>Timestamps are read but never written by /all/ users. Users
>perform operations which change timestamps as side-effects.
This is flase. One may often write timestamps. They are not
read only. ( and there's no reason why they should be )
[ snip ]
Whatever. I believe that your "system" is fragile and error prone,
and I doubt the users would like it that much. I wouldn't. But then,
if it's what you want, I don't have a problem with you trying to
implement it. Though I'll admit to being sceptical about your chances
of actually implementing any of it.
>common with a Smalltalk system than with a C/C++ program since
>an OS is *inherently* and *constantly* *dynamic*, just like any
>Smalltalk system is meant to be. And one of the reasons that
>Smalltalk is weakly typed is because strong typing hampers
>dynamic extensibility
You are babbling pure nonsense here. Learn C++, and learn it
properly, and then talk. You can make C++ act like smalltalk
if you want. Most of the time, C++ programmers don't want. But
when they do, it can be done.
[ snip ]
Well, I can't say I think that much of your system. It's hampered by lack of
compatibility which means that it is unlikely to ever even exist, and I
don't believe you've offered any compelling advantages regarding your
way of "designing" things.
I am reminded here of the fact that a lot of projects ( for example java )
were supposed to produce something better than C++, and despite the
apparent advantage of not having compatibility burdens, they didn't do
substantially better.
I suspect that if you had to actually implement anything, instead of
just doing your ivory-tower "enlightened high level design", you'd
get a dose of reality. I do pure math research and one thing I've
learned in my programming experience is that it's not like math. In
math, you don't care that much about efficiency ( "a solution exists" ! )
and you don't need to be terribly pragmatic. When you're programming,
you do.
--
Donovan
------------------------------
From: Jack Troughton <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.os2.advocacy,comp.sys.mac.advocacy,comp.os.ms-windows.nt.advocacy
Subject: Re: [OT] Tholen & Global warming. (was Public v. Private Schools)
Date: Fri, 22 Sep 2000 15:17:51 -0400
Sam Morris wrote:
>
> My god, Dave, pick an address to deflect spam and keep it! Stop changing it
> every five minutes! Killfiling you is really hard!
>
> --
> Cheers,
>
> Sam
Dave is always [EMAIL PROTECTED] It's his imitators you're having
a problem with.
--
==========================================================
* Jack Troughton jake at jakesplace.dhs.org *
* http://jakesplace.dhs.org ftp://jakesplace.dhs.org *
* Montr�al PQ Canada news://jakesplace.dhs.org *
==========================================================
------------------------------
From: [EMAIL PROTECTED] (=?ISO-8859-1?Q?Lars_Tr=E4ger?=)
Crossposted-To: comp.sys.mac.advocacy,comp.os.ms-windows.advocacy,comp.unix.advocacy
Subject: Re: Linsux as a desktop platform
Date: Fri, 22 Sep 2000 21:38:58 +0200
<[EMAIL PROTECTED]> wrote:
> On Mon, 18 Sep 2000 17:47:01 +0200, Lars Tr�ger <[EMAIL PROTECTED]> wrote:
> ><[EMAIL PROTECTED]> wrote:
> >
> >> On Fri, 15 Sep 2000 17:39:23 +0200, Lars Tr�ger <[EMAIL PROTECTED]>
> >> wrote:
> >> ><[EMAIL PROTECTED]> wrote:
> >> >
> >> >> Are you sure? Both Atari and Commodore had 2 button mice. If
> >> >> M$ "invented" the 2 button mouse then it was one of those
> >> >> "tree falling in a forest" things where either noone was there
> >> >> to notice or noone cared (or both).
> >> >
> >> >And both came later than the MS-Mouse. Anyway I wasn't quite right:
> >>
> >> Microsoft didn't even have overlapping Windows in 85.
> >
> >What the *$%& does this have to do with the mouse? Damn, you're just as
>
> It demonstrates just how "progressive" they tend to be with
> technology. This may or may not apply to a particular bit
> of hardware.
It would have been easier just saying so.
> >wiered as Steve Giovanella. The VisiCorp mouse (for PC) also came before
> >Atari and Commodore. Its right button was labled "scroll" and it was
> >optical BTW. And it had provisions for a third button (you had to get a
> >new top).
>
> Unless you've got a release date handy, that's not well established.
I got the info from an article in a german computer magazin from
december 1983. Unless you *are* like SG, you will admit that this was
quite some time before the ST and Amiga.
Lars T.
------------------------------
From: Richard <[EMAIL PROTECTED]>
Subject: Re: Because programmers hate users (Re: Why are Linux UIs so crappy?)
Date: Fri, 22 Sep 2000 19:44:54 GMT
Donovan Rebbechi wrote:
> On Fri, 22 Sep 2000 09:35:17 GMT, Richard wrote:
> > I do wonder where this attitude comes from if it
> >doesn't come from the programmers.
>
> from very anti social people. Usenet tends to attract them.
Granted, there are huge distortions due to USENET.
> > Either way, they don't seem
> >too worried about defusing it
>
> Some of them do. See the "Linux advocacy howto" for example. And some
> of the documents it references.
>
> > (more like worried about how to
> >exploit it for their own prestige and power).
>
> Nonsense.
You just provided an example. "advocacy" is about channeling
user anger instead of dealing with it.
And exploiting other people's fuckups instead of repairing
them is a common theme; academics that exploit the destruction
wreaked by the education system instead of fixing it, despite
all of their moaning about the very damage they're exploiting.
> >Limitations exist because nobody seems to think about the higher
> >level architectural issues that *dictate* the limitations.
>
> Good programmers know how to design software by definition.
Not correct. You're shifting the definitions of design and
good programmer around. Are hackers good programmers? And
yet, they don't seem able to design. I'm not sure we mean
the same thing by 'design'.
> It's not true that "all programmers are bad programmers" or even that
> "most programmers are bad programmers". ( again, the best 50% are "good" )
LOL.
> Nonsense. Limitations are inevitable. My text editor can't make me coffee.
> If it could make me coffee, I could find something else it can't do.
That's my point. But limitations in software are *not* dictated by
the nature of software. Physical objects obey immutable physical laws;
by comparison, software is infinitely malleable. Programmers have to
choose limitations but they have to choose sensible ones. Anyone who
fails to do architectural design has just ensured that the limitations
will be nonsensical and arbitrary.
> >Hmmm, good point. Somehow, I got the impression that the sysadmin
> >was a coder. I should research this mythos sometime.
>
> Not necessarily. A lot of sys admins are mediocre or lousy coders. The
> two skill sets tend to be almost orthogonal.
Oh, I realize that but I had this impression like
In The Beginning, there was the Hacker ....
> For example, there's no smalltalk VM on the system at my school, so
> I can't run smalltalk apps there.
Assuming there is a VM for that platform and assuming you have
the authority to install Smalltalk apps, then you could certainly
install the VM needed by those apps.
> Unfortunately, it's difficult to gain access to a decent set of APIs
> without "fucking a goat". You can write your toy algorithm programs
> in any language, but once you want the program to actually do something,
> you need APIs.
Like the native Smalltalk APIs? :-)
> >Depending on the dialect, it's either free (Squeak) or there is support
> >for splicing the VM into your app (VisualWorks).
>
> Which makes your app bigger, right ?
That's inevitable when you want to run apps written in one language on
an OS that uses a completely different language. If you used an OS built
on Smalltalk, you'd be paying this penalty only for C/C++ apps.
> That makes the language less safe. For example, inserting a string
> into a list of integers is probably an error.
*Probably*. But maybe not. "more safe" and "more extensible" are
understood by most people who argue about typing to be an inherent
tradeoff. And then there's Eiffel, which more or less has both ....
I honestly don't want to get into an argument about language typing
since I don't understand how C++ does it exactly, let alone the pros
and cons of it.
------------------------------
From: Richard <[EMAIL PROTECTED]>
Subject: Re: angry programmers
Date: Fri, 22 Sep 2000 19:47:45 GMT
Donovan Rebbechi wrote:
> Your whole rhetoric about "programmers" is misdirected IMO. The people
> you are complaining about are really "antisocial geeks". SOme of them
> are hobby programmers. Sopme of them are sys admins. A few of them are
> programmers. BUt the common thread is that they're computer-literate
> anti-social geeks, who may or may not be programmers.
Alright, I can accept that. (Still doesn't explain why software sucks
so badly but anyways.)
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.misc,comp.os.linux.setup,comp.software.config-mgmt
Subject: Re: Implications
Date: Fri, 22 Sep 2000 19:53:57 GMT
In article <[EMAIL PROTECTED]>,
Andreas K�h�ri <[EMAIL PROTECTED]> wrote:
> In article <%0Iy5.12646$[EMAIL PROTECTED]>,
> paul snow <[EMAIL PROTECTED]> wrote:
> >Implications
> >========
> >
> >So suppose that you are required to come up with a model that
explains not
> >only what your software does (which various OO technologies do with
varying
> >success), but also where your software comes from.
>
> Your software comes from you.
I don't write every program I use, and I know I didn't write every
program he uses.
>
> >This requirement would
> >force you past the von Neumann model, where the program store P
defines the
> >execution environment E:
>
> I fail to see the connection to the von Neumann model.
> The program store does not define an execution environment.
Your machine is off. You turn it on. Something executes. What
defines that something?
>
> >
> > P --> E
> >
> >Non-trivial computer systems are constructed from a collection of
> >software, installed in some order.
>
> If you're not talking about microcode, cache protocols or the like,
> then I would say that this is nonsense. The complexity of a computer
> system does not depend on e.g. the operating system it runs.
Huh? I can't for the life of me figure out what he could possibly mean
here.
>
> >So in non-trivial computer systems, there always
> >exists some independent definition of P. Call this definition X.
> >
> > X --> P --> E
> >
> >Furthermore, X is not generally a single source. If X is a disk
image
> >applied to the hard drive (the P of a computer system), then X may
in fact
> >be a single source. But usually it isn't.
>
> (void)
>
> >
> >So X is made up of a set of components representing the number of
installs n
> >required to build up P in a given computer system.
> >
> > X = {X(1), X(2), X(3),...,X(n)}
> >
> >Our current software architectures do not model X. In fact, they
doesn't
> >tend to model installation and integration at all. IT spends 75
percent of
> >their money in this area, but it doesn't seem to be important enough
to
> >study.
>
> Eh, what's "software architecture"? I know that the hardware
> architecture does not model X (the software). That's because it's not
> its task.
X is the set of software that can be installed on a computer system.
P is the set of installed software in a computer system.
E is what you get when you turn your computer system on.
I get the impression that he didn't have a clue.
> >
> >With open software, modeling X is even more important, since the
various
> >components of X come from different sources, and in many different
releases
> >and versions. Understanding and modeling how this is done will lead
to
> >better solutions and mechanisms for software development and
distribution.
>
> Buggerit.
>
> Why do we want to model software?! Please, tell me! Oh, don't bother
> BTW, I just killfiled you anyway so I won't see your answer.
Everything we do is patterned around some model of the problem. That
is what math is, a model of the relationships between concepts. If you
can prove things about the real world using mathmatical models, you can
reach the moon.
My claim is that we have a big integration, development, and deployment
problem with software. And we do not have an appropriate model of the
problem. Why would we need such a model? Well, so we can make
progress, do things better, understand what and why we do what we do.
> >
> >Fun Implications
> >===========
> >
> >This math may remind some (those with a biological background) of
DNA. It
> >should. I would claim that all process based systems are forced
into this
> >model, by definition. X forms the DNA for a computer system. Genes
are the
> >components of DNA, much like some X(i) is a component of X.
> >
> >Thus there is a very literal genetic component to computer systems
because
> >both a living cell and a computer system are process based systems.
> >
> >The genetic nature of computer systems can not be circumvented.
> >
> >Really Fun Implications
> >===============
> >
> >So software is defined by the "genes" of a computer system, the
installation
> >medium. That means that a software package, like what I might buy
at a
> >computer store, represents genetic material.
>
> That is a valid picture of it, yes.
>
> >
> >The biological term for the exchange of genetic material is... sex.
>
> Ok.
>
> >
> >Adding software to my software library is a literal form of computer
sex.
>
> Whatever turns you on.
>
> >
> >So all along, our computers have been using us to spread their
genetic
> >material, like bees.
>
> No. Computers are, by definition, unable to use anything. It has no
> free will and can not think. It can't plan or spread its software or
> write license agreements or produce new operating systems. A computer
> will do whatever you tell it to do. If you tell it to do whatever it
> wants to do, you must first tell it about the options it has. It's an
> it. It will always be limited.
Nothing I wrote here claimed otherwise. I am just about to say the
same thing...
>
> >
> >We are also their agents for developing new genetic material, and we
are the
> >environmental agents that supply the developmental pressures that
drive some
> >genetic material to extinction, while other material (like Linux
perhaps?)
> >flourishes.
>
> Nope.
I think I just said what he said previously. Okay, I left out the
phrase "agents of change that respond to those pressures". But if he
had not been so disoriented by a new idea, he could have picked up the
spirit there.
> >
> >And most of the alternatives to Linux require people pay for their
> >software...
> >
> >
> >Paul Snow
> >[EMAIL PROTECTED]
> >
> >
>
> Intresting views, but really off topic.
>
> *plonk*, sir.
>
> What a strange person...
Thanks.
>
> /A
>
> --
> Andreas K�h�ri, <URL:http://hello.to/andkaha/>. Junk mail, no.
> ----------------------------------------------------------------------
--
> What part of "GNU" did you not understand? <URL:http://www.gnu.org/>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Richard <[EMAIL PROTECTED]>
Subject: Re: hypocritical Unix apologists
Date: Fri, 22 Sep 2000 20:02:18 GMT
FM wrote:
> required in programming is minimal, but when a guy
> is showing complete inability to understand
> abstract concepts, you can often attribute that to
> the lack of basic mathematical skills.
ROTFLMAO. You have no idea how wide your shot went.
I was weaned on mathematics, I grew up on it and
I could leave you reeling in any discussion on the
topics of physics, mathematics, philosophy, politics,
sociology and psychology; basically anything and
everything theoretical. And my ability to understand
abstract concepts is *superlative*.
You're projecting again.
When one deals with the sublime on a day to day
basis, it is difficult to see the "beauty" in a
pile of dog turds. Maybe you're accustomed to
ugliness ... or maybe you're just an idiot.
------------------------------
From: Richard <[EMAIL PROTECTED]>
Subject: Re: Because programmers hate users (Re: Why are Linux UIs so crappy?)
Date: Fri, 22 Sep 2000 20:07:28 GMT
Gary Hallock wrote:
> Gee, do some programmer beat you as a child? Where does all this hatred for
> programmers come from?
Unix is a piece of crap. For no better reason than Inertia, it will
continue to dominate for decades. Do I need a better reason?
It doesn't help that software interfaces are written in such a
way that they can only be described as "utter assholes" if you
were to label them with human characteristics. So my anger stems
from the fact that I have to deal with utter assholes on a daily
basis. Seem reasonable to you?
------------------------------
** 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
******************************
