Erik Naggum wrote:
"on this topic, I might add that I have never quite figured out why
employees don't interview their employers at least as rigorously as they
interview them, but I have always been an independent consultant because
I don't want to work for people who don't realize that they have to give
me a very solid reason to work for them for at least 8 hours a day in a
location of their choice, nor do I understand why people individually
accept so horrible working conditions that they have to form labor unions
so they don't have to accept them, anymore, but I digress."
and denied that fear of destitution was why:
"no, that is not the explanation, although some would have you believe
that people can be forced to accept anything under threat of becoming
destitute if they don't."
Erik, your implication is clear; they are foolish for not standing up for
themselves in the first place as _you_ do. No matter that you run no risk
of being beaten, tortured, or murdered, or of starving if you express your
wants directly to your prospective employers.
You deride people who would forfeit their lives and/or their loved ones'
lives if they stood up to their employers, for not being independent
consultants.
Your post is offensive.
My understanding of it is not faulty, as evinced by the responses of
others, who pointed out, with no little sarcasm, that the reason such
people don't stand up to their employers is that they would become
destitute or dead if they did so.
You were not saying "Gee, this is a mystery to me! Please somebody explain
this to me!" Try as you might to make this a jesuitical dispute, your
meaning is clear. You deride the opressed just as you deride and abuse
posters to comp.lang.lisp, because you are a verbally abusive, disdainful
person. I believe a very good case can be made that you actively drive
people _away_ from lisp because of the tone of your posts to c.l.l. Though
you have said "lisp is better off without them," I'm sure others believe
with me, that c.l.l might well be better off _with_ them, and without your
abusive posts.
As for those who _really_ believe that Erik was _actually_ asking an
honest question above (not those stating the theoretical possibility that
some abstract speaker could have meant those words as a real question), I
suggest that you have either an enviable lack of exposure to Erik's c.l.l
vitriol, or a lamentable inability to discern a speaker's real meaning.
Raf
--
Raffael Cavallaro, Ph.D.
·······@mediaone.net
From: Arne Knut Roev
Subject: Re: With friends like Erik, c.l.l doesn't need enemies
Date:
Message-ID: <FID23A.Fx9@online.no>
Raffael Cavallaro <·······@mediaone.net> wrote:
[a rather long rant...]
In an earlier post, a certain Raffael Cavallaro <·······@mediaone.net> wrote:
>No, see, there's an option in most decent newsreaders that allows you to
>post a _new_ thread. You must be familiar with it, since _you_ started
>_this_ thread with a rather long rant.
>
>Everyone else in this thread can claim to be responding to someone else's
>post, but _not_ you, 'cause _you_ started the thread. See how that works?
Pot.
Kettle.
Black.
NOW, can we get back to lisp ?
--
Arne Knut Roev <······@online.no> Snail: N-6141 ROVDE, Norway
=
James, you ought to discover some day that words have an exact meaning.
From: Greg
Subject: Re: With friends like Erik, c.l.l doesn't need enemies
Date:
Message-ID: <m3btaygrfb.fsf@erols.com>
>
> You were not saying "Gee, this is a mystery to me! Please somebody explain
> this to me!" Try as you might to make this a jesuitical dispute, your
> meaning is clear. You deride the opressed just as you deride and abuse
> posters to comp.lang.lisp, because you are a verbally abusive, disdainful
> person. I believe a very good case can be made that you actively drive
> people _away_ from lisp because of the tone of your posts to c.l.l. Though
> you have said "lisp is better off without them," I'm sure others believe
> with me, that c.l.l might well be better off _with_ them, and without your
> abusive posts.
Thank you Raffael! That was better said than anything I could come up
with. I absolutely agree. Posters like Erik make usenet and mailing
lists a lot less enjoyable for everyone, regardless of how correct
they are or not on a given topic.
Erik, I also don't appreciate the tone you have taken towards me and
many others. I'm not commenting on technical questions, only that, in
my opinion, your abusive approach ends up stifling discussion and
intimidating people who might have something to contribute.
Gregm
From: Erik Naggum
Subject: Re: With friends like Erik, c.l.l doesn't need enemies
Date:
Message-ID: <3146849045057050@naggum.no>
* Greg <······@erols.com>
| Posters like Erik make usenet and mailing lists a lot less enjoyable for
| everyone, regardless of how correct they are or not on a given topic.
I'm actually curious: why do you think Raffael Cavallaro's contributions
are laudable and applaudable? how come you "back" him and decide to go
public with it, if what you say here is true? why is his abuse to be
defended? do you actually see him as a poor, defenseless person who has
every right to defend himself, and I have no right to voice my strong
disagreement with his numerous unfounded attacks against my person? and
why is it better to attack a person in vague, general terms with no sign
of a cease of attacks in sight than to attack a few specific things he
chooses to do, which he can choose to cease to do, taking all criticism
with it? since you take a stand, and fault me, I must assume that you
see nothing at all wrong with Raffael Cavallaro. is that indeed true?
#:Erik
From: Reini Urban
Subject: Re: With friends like Erik, c.l.l doesn't need enemies
Date:
Message-ID: <37e5ff33.85114768@judy>
Greg wrote:
>> You were not saying "Gee, this is a mystery to me! Please somebody explain
>> this to me!" Try as you might to make this a jesuitical dispute, your
>> meaning is clear. You deride the opressed just as you deride and abuse
>> posters to comp.lang.lisp, because you are a verbally abusive, disdainful
>> person. I believe a very good case can be made that you actively drive
>> people _away_ from lisp because of the tone of your posts to c.l.l. Though
>> you have said "lisp is better off without them," I'm sure others believe
>> with me, that c.l.l might well be better off _with_ them, and without your
>> abusive posts.
>
>Thank you Raffael! That was better said than anything I could come up
>with. I absolutely agree. Posters like Erik make usenet and mailing
>lists a lot less enjoyable for everyone, regardless of how correct
>they are or not on a given topic.
>
>Erik, I also don't appreciate the tone you have taken towards me and
>many others. I'm not commenting on technical questions, only that, in
>my opinion, your abusive approach ends up stifling discussion and
>intimidating people who might have something to contribute.
Erik is much better than e.g. tom christianson from the perl group or
other morons from other groups. (Erik is NO moron, Tom is one.)
I appreciate erik's harsh tone here much more than the tone in the big
perl (comp.lang.perl.misc) or other religious groups, mainly because he
stays always accurate and precise. In the perl group for example you
don't even dare to ask about Win32 problems. This is motivated by
arrogance, politics and myths, not by knowledge.
Similar problems exist in all big language groups.
To continue with the (slightly unfair) analogy and to make my point,
perl -the language, the libs and the community- is still good even if
its main discussion group is ruled by arrogant and abusive posters.
--
Reini
another typical example of recent overreaction: NSAKEY
http://hyperarchive.lcs.mit.edu/telecom-archives/archives/back.issues/recent.single.issues/V19_%23379
From: Erik Naggum
Subject: Re: With friends like Erik, c.l.l doesn't need enemies
Date:
Message-ID: <3146818590591111@naggum.no>
* Greg <······@erols.com>
| Erik, I also don't appreciate the tone you have taken towards me and
| many others. I'm not commenting on technical questions, only that, in
| my opinion, your abusive approach ends up stifling discussion and
| intimidating people who might have something to contribute.
so try to fail to post drivel and see that my reaction changes, too.
#:Erik
From: IBMackey
Subject: Re: With friends like Erik, c.l.l doesn't need enemies
Date:
Message-ID: <btaxwwvq.fsf@stic.net>
Actually, I find comp.lang.lisp to be very depressing sometimes. I
think the digs, criticisms, and personal attacks lower its value as a
help source. When I've had problems that I posted, I got a lot of
email answers. I suspicion it's because people don't want to get
involved with this viciousness.
Is there any way we could set up a comp.lang.lisp.advocacy where
people could have full swing on their emotions and bitterness, and
then leave comp.lang.lisp as a true help group?
Ex-hippie and free spirit,
i.b.
Greg <······@erols.com> writes:
> >
> > You were not saying "Gee, this is a mystery to me! Please somebody explain
> > this to me!" Try as you might to make this a jesuitical dispute, your
> > meaning is clear. You deride the opressed just as you deride and abuse
> > posters to comp.lang.lisp, because you are a verbally abusive, disdainful
> > person. I believe a very good case can be made that you actively drive
> > people _away_ from lisp because of the tone of your posts to c.l.l. Though
> > you have said "lisp is better off without them," I'm sure others believe
> > with me, that c.l.l might well be better off _with_ them, and without your
> > abusive posts.
>
> Thank you Raffael! That was better said than anything I could come up
> with. I absolutely agree. Posters like Erik make usenet and mailing
> lists a lot less enjoyable for everyone, regardless of how correct
> they are or not on a given topic.
>
> Erik, I also don't appreciate the tone you have taken towards me and
> many others. I'm not commenting on technical questions, only that, in
> my opinion, your abusive approach ends up stifling discussion and
> intimidating people who might have something to contribute.
>
> Gregm
From: Kent M Pitman
Subject: Re: With friends like Erik, c.l.l doesn't need enemies
Date:
Message-ID: <sfwhfkpbla8.fsf@world.std.com>
IBMackey <····@stic.net> writes:
> Is there any way we could set up a comp.lang.lisp.advocacy where
> people could have full swing on their emotions and bitterness, and
> then leave comp.lang.lisp as a true help group?
Usenet is a free speech forum. Your best protection is your personal
killfile. Even if you made these other forums, it's no guarantee
they'd be used as you want them to. Nor that if they were used in the
way the creator intended others would think they were being properly
used.
The best policies when things are this way are either to not read
or to focus on making your own posts constructive. A wealth of positive
posts will make the negative ones recede into the background. If there
are not enough positive posts, that's why the negatives take center stage.
Erik sometimes says things I don't agree with or like. I just ignore
those. That's what I assume people do with the things I say that they
don't agree with or like. None of us is perfect. Sometimes I think to
the archlike thing in Star Trek Classic's "City on the Edge of Forever"
where the Enterprise crew is fussing over the fact that the arch has no
speed control. It says something like, "I was made to offer the past
in this way." The mere fact that it can't be fine tuned doesn't mean
it's not a marvelous device. I sometimes think people are that way, too.
For whatever that's worth.
I have saved many of Eric's postings, even though I often think he is
wrong and I occasionally think he is unnecessarily harsh. In spite of
this, he is one of the giants of the group in terms of lisp knowledge,
and his philosophical, uh, musings are almost always interesting,
often entertaining, and sometimes enlightening. The price you pay is
that he `doesn't suffer fools gladly.'
I think his input is worth the price---but everyone has to decide that
for himself. If you don't think that way, please use a kill file
entry and insulate yourself.
--
Fred Gilham ······@csl.sri.com
"Come to me, all who labor and are heavy laden, and I will give you
rest. Take my yoke upon you, and learn from me, for I am gentle and
lowly in heart, and you will find rest for your souls. For my yoke
is easy, and my burden is light." --Jesus of Nazareth
In article <··············@snapdragon.csl.sri.com>, Fred Gilham
<······@snapdragon.csl.sri.com> wrote:
> The price you pay is that he `doesn't suffer fools gladly.'
I think we pay a higher price than that.
I have been waging a ten-year-long campaign at NASA to convince
people that Lisp is a respectable option for developing spacecraft
software. I have found that people rarely make decisions based on
first hand information. They are much more likely to base their
views on gut feel, zeitgeist, and the opinions of other people that
they like and respect. Likewise, people will often take contrary
positions to those that they don't like and don't respect even in
the face of objective evidence.
For example: you will find many people in positions of authority at
NASA who believe that Lisp should not fly on a spacecraft because
garbage collection can make the spacecraft go catatonic at a critical
time. This despite the fact that 1) this has never ever been true
and 2) Lisp has actually flown on a spacecraft. They believe this
because everyone they associate with believes it. The people they
associate with in turn believe it for the same reason. It's a
self-perpetuating myth, and it survives even in the face of objective
evidence to the contrary, kind of like the idea that HIV causes AIDS.
Now, dear reader, I ask you to stop for a moment and reflect on your
own personal reaction to those last nine words in the previous
paragraph. Unless you happen to be familiar with an obscure school
of thought headed by a fellow named Peter Duesberg your reaction
was almost certainly something like, "What do you mean? OF COURSE
HIV causes AIDS. EVERYONE knows that." Now, I need to be very clear
on one point: it is not my intention to call into question whether
HIV actually causes AIDS or not. The point I want to raise is: if
you, like most people, believe that HIV causes AIDS, *on what basis
do you believe it*? Have you ever personally performed an experiment
to support that view? Have you read any peer-reviewed scientific
papers that justify that conclusion? Most likely the answer is no.
You believe HIV causes AIDS because everyone around you believes it.
Everyone around you believes it because everyone around *them*
believes it. And if you trace things back you will find that everyone
believes that HIV causes AIDS not because there is actualy good scientific
evidence for it, but because in 1984 a US government official called a
news conference to announce that it was so, and no one (except Duesberg)
ever bothered to seriously question it.
It's the same situation for Lisp. Everyone believes that Lisp is
slow, no good for general purpose programming, etc. etc. because at
some point someone said so authoritatively (and perhaps when they
said it was even true) and the idea has been self-perpetuating
ever since.
What does this have to do with Erik? If you're going to try to change
people's minds about a self-perpetuating myth the first thing you have
to do is convince them to pay attention to what you are saying. If
people tune out then you've lost no matter how right you may be. And if
people think you are a raving lunatic, or even just an unpleasant
person, then they tune out. Erik is unnecessarily rude and abrasive.
He intentionally pushes people's hot buttons in the name of stamping
out stupidity. The net result is that they tune out, and in the back
of their minds they add another hash mark to the tally of evidence
that people who like Lisp are arrogant primadonnas, and not the kind
of people whose judgements they wish to rely on.
This negative effect spreads like a cancer. By the time it gets around
to *your* boss he will likely never have encountered Erik directly. But
he will have encountered some people who encountered some people who
encountered Erik and came to the conclusion that Lispers are just a
bunch of asshole flamers. It only takes a few such people with the
right connections to make the world a hostile place for Lisp.
Now, it is certainly *not* the case that the sorry state of Lisp (and any
product that can support only one vendor world-wide is in a sorry state)
is Erik's responsibility, but in the grand scheme of things I
believe he does more harm than good. And I think that's a real shame
because Erik *is* an exceptionally bright guy and he could be a very
effective Lisp advocate if only he could be convinced to change his
style a little. (I tried a new strategy for doing that a few days
ago, but I'm afraid I failed.)
If Lisp is going to survive as anything more than an academic curiosity
it has to be marketed effectively. The price we pay for Erik's insights
is that job becomes a little harder. Ultimately the price we pay is that
we have to program in C++ and Perl in order to make a living. In my
mind that is a high price indeed, particularly since Erik is ostensibly
on my side. That's why I basically agree with the sentiment expressed
by the original poster: with friends like Erik, Common Lisp doesn't need
enemies. This is despite the fact that I personally enjoy reading
Erik's posts and have found many new and interesting ideas in his writings.
I hope he continues to post. I also hope he can be convinced that it
would better advance our common interest if he would be a little less
rude.
Erann Gat
···@jpl.nasa.gov
From: Arne Knut Roev
Subject: Re: With friends like Erik, c.l.l doesn't need enemies
Date:
Message-ID: <FIGxu2.Izx@online.no>
Erann Gat <···@jpl.nasa.gov> wrote:
[a rather long rant where he tries to justify shooting at the wrong target.]
Mr Gat, the logic of your position, as you just described it, reminds me of
a famous court case a Norwegian writer described almost two hundred years
ago. In that case, a murder was committed (and confessed) by the blacksmith
of a village. But, since that village had only one blacksmith, but two
bakers, it was decided that the murder which was committed by the
blacksmith, would be punished by the execution of the oldest baker...
That particular court case was fictional; in your case we are not so lucky.
If we take a look at your description:
> I have found that people rarely make decisions based on
> first hand information. They are much more likely to base their
> views on gut feel, zeitgeist, and the opinions of other people that
> they like and respect. Likewise, people will often take contrary
> positions to those that they don't like and don't respect even in
> the face of objective evidence.
And your subsequent comments on the actions of certain people in this
newsgroup:
> What does this have to do with Erik? If you're going to try to change
> people's minds about a self-perpetuating myth the first thing you have
> to do is convince them to pay attention to what you are saying. If
> people tune out then you've lost no matter how right you may be. And if
> people think you are a raving lunatic, or even just an unpleasant
> person, then they tune out. Erik is unnecessarily rude and abrasive.
> He intentionally pushes people's hot buttons in the name of stamping
> out stupidity. The net result is that they tune out, and in the back
> of their minds they add another hash mark to the tally of evidence
> that people who like Lisp are arrogant primadonnas, and not the kind
> of people whose judgements they wish to rely on.
It is perfectly obvious to me that you are:
1) believing this newsgroup to be intended for advertising the virtues
of lisp, which is a quite ridiculous idea,
2) attacking Erik because he writes what he means, which goes against
the entire idea of newsgroups (always assuming that the given posts
are topical),
3) by not taking action in the case of Nasa employees not doing their
jobs, you are actually condoning that particular behaviour.
To make that third point quite clear: Any person who is in a position to
choose the tools for solving a technical (/engineering) problem, who is
basing their choice on anything but cold, hard, technichal, scientific, and
economical facts, are quite obviously not doing their job. The only possible
exception to this, is in the cases where you have no such information
available, in which case research might be a good idea.
Apart from these points, you may be right...
--
Arne Knut Roev <······@online.no> Snail: N-6141 ROVDE, Norway
=
James, you ought to discover some day that words have an exact meaning.
In article <··········@online.no>, Arne Knut Roev <······@online.no> wrote:
> 3) by not taking action in the case of Nasa employees not doing their
> jobs, you are actually condoning that particular behaviour.
>
>To make that third point quite clear: Any person who is in a position to
>choose the tools for solving a technical (/engineering) problem, who is
>basing their choice on anything but cold, hard, technichal, scientific, and
>economical facts, are quite obviously not doing their job.
Arne, this would be a better world if you were right.
But the world you describe is not the real world. NASA managers are not
robots; they make decisions based on gut feelings and political
rationales, just as managers in industry do. And remember that
"scientific facts" themselves are often in dispute.
> The only possible
>exception to this, is in the cases where you have no such information
>available, in which case research might be a good idea.
Well, at least at the NASA centers where Erann Gat and I work, research
is in fact in our job descriptions. But researchers are not always
open-minded either!
-- Chuck, *definitely* not speaking for NASA or his employer
--
Chuck Fry -- Jack of all trades, master of none
······@chucko.com (text only please) ········@home.com (MIME enabled)
Lisp bigot, mountain biker, car nut, sometime guitarist and photographer
The addresses above are real. All spammers will be reported to their ISPs.
From: Arne Knut Roev
Subject: Re: With friends like Erik, c.l.l doesn't need enemies
Date:
Message-ID: <FIIwKw.Jn2@online.no>
Chuck Fry <······@best.com> wrote:
> In article <··········@online.no>, Arne Knut Roev <······@online.no> wrote:
>> 3) by not taking action in the case of Nasa employees not doing their
>> jobs, you are actually condoning that particular behaviour.
>>
>>To make that third point quite clear: Any person who is in a position to
>>choose the tools for solving a technical (/engineering) problem, who is
>>basing their choice on anything but cold, hard, technichal, scientific, and
>>economical facts, are quite obviously not doing their job.
> Arne, this would be a better world if you were right.
> But the world you describe is not the real world. NASA managers are not
> robots; they make decisions based on gut feelings and political
> rationales, just as managers in industry do. And remember that
> "scientific facts" themselves are often in dispute.
Would you _please_ do us all the favour of either commenting what's actually
written, or not commenting at all ??!?!???
>> The only possible
>>exception to this, is in the cases where you have no such information
>>available, in which case research might be a good idea.
> Well, at least at the NASA centers where Erann Gat and I work, research
> is in fact in our job descriptions. But researchers are not always
> open-minded either!
- - repeat the request written above - -
An additional note:
People who have closed minds, do not fit the job description of researchers.
--
Arne Knut Roev <······@online.no> Snail: N-6141 ROVDE, Norway
=
James, you ought to discover some day that words have an exact meaning.
From: William Deakin
Subject: Re: With friends like Erik, c.l.l doesn't need enemies
Date:
Message-ID: <37E9F90A.A313B9F9@pindar.com>
Chuck Fry wrote:
> But the world you describe is not the real world. NASA managers are not
> robots; they make decisions based on gut feelings and political rationales,
> just as managers in industry do.
This is no suprise, but saddens me enormously. That a flag-ship world class
organisation like NASA is subject to the same ill-informed gossip-based
prejudiced rubbish as less presidious places of work is a sad, sad thing to
behold.
:( will
From: Matt Wette
Subject: Flying LISP [was Re: With friends like Erik, c.l.l ...]
Date:
Message-ID: <7k3dw49k1b.fsf_-_@jpl.nasa.gov>
To make things clear, my comments below represent my own views and not
that of the organization I work for.
William Deakin <·····@pindar.com> writes:
> Chuck Fry wrote:
>
> > But the world you describe is not the real world. NASA managers are not
> > robots; they make decisions based on gut feelings and political rationales,
> > just as managers in industry do.
>
> This is no suprise, but saddens me enormously. That a flag-ship world class
> organisation like NASA is subject to the same ill-informed gossip-based
> prejudiced rubbish as less presidious places of work is a sad, sad thing to
> behold.
Get real. You should take Erann's post in context. You have
basically concluded that NASA is run by bozos because they don't do
what Erann wants. I've worked in industry and now work at JPL (which
has a contract w/ NASA to do space work). The folks at JPL are
technically up there. The managers of technical programs are
engineers who have risen through the ranks; an overwhelming majority
of them are very competent. My experience is that these managers
don't make decisions blindly but take input from their team, and as
Chuck states, "political rationales". If managers don't choose LISP,
then I think the problem is that Erann has not been able to convince
his peers that LISP is the way to go. Remember NASA is out to provide
technology. I don't think many consider LISP in space a technology
item. AI in space yes, ion engines yes, LISP no. LISP has to prove
it's value on some grounds. My guess is that DS1 flew LISP not
because they wanted to prove that it could be done but because they
want to fly the Remote Agent, which was written in LISP.
Look at his post:
Erann wrote ...
> I have been waging a ten-year-long campaign at NASA to convince
> people that Lisp is a respectable option for developing spacecraft
> software. I have found that people rarely make decisions based on
> first hand information. They are much more likely to base their
> views on gut feel, zeitgeist, and the opinions of other people that
> they like and respect. Likewise, people will often take contrary
> positions to those that they don't like and don't respect even in
> the face of objective evidence.
>
> For example: you will find many people in positions of authority at
> NASA who believe that Lisp should not fly on a spacecraft because
> garbage collection can make the spacecraft go catatonic at a critical
> time. This despite the fact that 1) this has never ever been true
> and 2) Lisp has actually flown on a spacecraft. They believe this
> because everyone they associate with believes it. The people they
> associate with in turn believe it for the same reason. It's a
> self-perpetuating myth, and it survives even in the face of objective
> evidence to the contrary, kind of like the idea that HIV causes AIDS.
The term that struck me was "objective evidence." That's a loaded
term. There are many issues wrt flying LISP and management can't go
in the lab and test them all for themselves. They depend on engineers
who *have* gone in the lab and done the work, but the reports they see
may not be completely objective. Any engineer want to see his design
win and will typically work harder to show it works than to show it
doesn't work. Managers are used to this and have to make judgement of
how much of this evidence is marketing.
Let's consider the comments above:
"(1) this has never been true." Now that I read it I don't even know
exactly what the point is. If you mean that GC on LISP has never made
a flying spacecraft go catatonic you are right because it's never been
done before, but you want NASA to risk >$100M just to find out? On
the otherhand if you mean "GC on LISP has never made a system go
catatonic" then I would then wonder about the credibility of this
statement, and hence any statement made with it.
"(2) Lisp ahs actually flown on a spacecraft" Another loaded one.
This statement didn't reflect that the software didn't work completely
correctly. And the flight time is epsilon relative to other systems
(e.g., VxWorks). Many years ago people were nervous about running
*any* commercial software that didn't go through rigorous,
line-by-line flight review. We're doing it now but it takes some time
to get over being nervous about it.
--
Matthew.R.Wette at jpl.nasa.gov -- I speak for myself, not for JPL.
In article <·················@jpl.nasa.gov>, Matt Wette
<···············@jpl.nasa.gov> wrote:
> > This is no suprise, but saddens me enormously. That a flag-ship world class
> > organisation like NASA is subject to the same ill-informed gossip-based
> > prejudiced rubbish as less presidious places of work is a sad, sad thing to
> > behold.
>
> Get real. You should take Erann's post in context. You have
> basically concluded that NASA is run by bozos because they don't do
> what Erann wants. I've worked in industry and now work at JPL (which
> has a contract w/ NASA to do space work). The folks at JPL are
> technically up there.
I agree with Matt. "Ill-informed gossip-based prejudiced rubbish," is
putting it far too strongly. Do you think that most believe believe
that HIV causes AIDS as a result of ill-conceived gossip-based
prejudiced rubbish? My whole point was that people can't possibly
make completely informed decisions in all areas where that's required
of them. They have to rely on other people's judgement. And if you
want to be one of the people on whose judgement other people rely
it helps to be polite.
> > For example: you will find many people in positions of authority at
> > NASA who believe that Lisp should not fly on a spacecraft because
> > garbage collection can make the spacecraft go catatonic at a critical
> > time. This despite the fact that 1) this has never ever been true
> > and 2) Lisp has actually flown on a spacecraft. They believe this
> > because everyone they associate with believes it. The people they
> > associate with in turn believe it for the same reason. It's a
> > self-perpetuating myth, and it survives even in the face of objective
> > evidence to the contrary, kind of like the idea that HIV causes AIDS.
>
> The term that struck me was "objective evidence." That's a loaded
> term. There are many issues wrt flying LISP and management can't go
> in the lab and test them all for themselves. They depend on engineers
> who *have* gone in the lab and done the work, but the reports they see
> may not be completely objective. Any engineer want to see his design
> win and will typically work harder to show it works than to show it
> doesn't work. Managers are used to this and have to make judgement of
> how much of this evidence is marketing.
This is really off the mark. First, "objective evidence" is not a loaded
term. It is a perfectly well defined term. (Note that it does not mean
"proof".) Second, Lisp is not my design, so I cannot possibly be
prejudiced towards it on those grounds. I am a passionate defender of
Lisp because not because it's "mine" but because in my experience it
helps you get the job done. I can use Lisp to implement in a day what
would have taken weeks and months to do in any other language. Life
is too short to program in any other language if you can avoid it.
> Let's consider the comments above:
>
> "(1) this has never been true." Now that I read it I don't even know
> exactly what the point is. If you mean that GC on LISP has never made
> a flying spacecraft go catatonic you are right because it's never been
> done before, but you want NASA to risk >$100M just to find out?
Untrue. It has been done, as you know perfectly well. But it was not
necessary to actually *do* it to know for certain that Lisp GC, correctly
deployed, cannot possibly make the spacecraft go catatonic. There is
nothing at all magical about GC; it's a computation like any other, and
it has no special abilities to make the spacecraft go catatonic more
than any other computation.
> On the otherhand if you mean "GC on LISP has never made a system go
> catatonic" then I would then wonder about the credibility of this
> statement, and hence any statement made with it.
I never said anything of the sort. Of course GC *can* make a system
go catatonic, but so can any other lengthy computation if it's not
deployed correctly.
> "(2) Lisp ahs actually flown on a spacecraft" Another loaded one.
> This statement didn't reflect that the software didn't work completely
> correctly.
This is completely disingenuous. *Lisp* worked perfectly correctly
on the spacecraft. The *program* that was written in Lisp had a bug
in it, but so what? The C code also had bugs. Do you want to stop
using C because someone wrote a buggy C program?
> My LISP knowlege is mediocre at best.
Here we have precisely the situation I am talking about in microcosm.
Matt is self-admitedly ignorant of Lisp, but he feels no compunction
expressing negative views about it as if they were facts, e.g:
> 4. CLOS is slow.
Which he knows because
> I've read through the MOP book a bit.
Or
> 5. LISP is big.
which he knows because
> I've seen moderate LISP in embedded systems come in at > 30Meg.
The current state of the art is under 2 MB for Common Lisp
> 7. Here's another important one. The only LISP I know of that runs
> on a realtime OS must run as one OS threads. It does it's own
> multithreading within that thread. So there is *no* way to have
> two LISP tasks with a C task in between. I'd also guess that the
> LISP environment has no way to handle the classis priority
> inversion problem.
This problem was also recently solved. The current system uses
the vxWorks scheduler to schedule Lisp threads, so their priorities
can be interleaved with C threads.
But I don't really want to belabor Matt's factual errors. The more
salient point is that my office is in the building adjacent to Matt's.
He could have walked over here and asked me if these things were true
and I could have set him straight in about fifteen minutes. I could
have showed him objective evidence that he was wrong, like actual
benchmarks, and real Lisp threads with priorities interleaved with C
processes running on an actual vxWorks testbed. But he chose not to.
Why? Of course, I can only speculate, but I believe it has to do
with the fact that on occasion I behave not so differently from
Erik Naggum. When I say that such behavior is not very effective
(at least in the US) that view is based not on mere speculation but
on first-hand experience.
Erann Gat
···@jpl.nasa.gov
From: William Deakin
Subject: Re: Flying LISP [was Re: With friends like Erik, c.l.l ...]
Date:
Message-ID: <37F08974.B5375F56@pindar.com>
Erann Gat wrote:
> I agree with Matt. "Ill-informed gossip-based prejudiced rubbish," is putting it
> far too strongly.
Probably is. But I get angery with this stuff.
> My whole point was that people can't possibly make completely informed decisions
> in all areas where that's required of them. They have to rely on other people's
> judgement. And if you want to be one of the people on whose judgement other
> people rely it helps to be polite.
But not creepy. It is important that you call a spade a spade and not a manual
operated earth moving implement, or a bloody shovel. But you are right, politness
is important and if you think my posting was rude then you have my humble
appologies,
Best Regards,
:) will
From: William Deakin
Subject: Re: Flying LISP [was Re: With friends like Erik, c.l.l ...]
Date:
Message-ID: <37F08D57.71874A1B@pindar.com>
Matt Wette wrote:
> William Deakin <·····@pindar.com> writes:
>
> > Chuck Fry wrote:
> >
> > > But the world you describe is not the real world. NASA managers are not
> > > robots; they make decisions based on gut feelings and political rationales,
> > > just as managers in industry do.
> >
> > This is no suprise, but saddens me enormously. That a flag-ship world class
> > organisation like NASA is subject to the same ill-informed gossip-based
> > prejudiced rubbish as less presidious places of work is a sad, sad thing to
> > behold.
>
> Get real. You should take Erann's post in context. You have basically concluded
> that NASA is run by bozos because they don't do
> what Erann wants.
Thank you for telling me what I have concluded. It is always nice to have somebody
help me like this, since it is obvious that I cannot mean what I say.
Further, at no point that did I say that NASA was filled with "bozos." However, it
saddens me that a place of excellence does not have a rational policy for making
decisions, but (based on Mr. Gat posting) makes these decisions based on rationales
other than fitness-for-purpose.
If you feel this is "un-real", it probably is. If you feel it is rude then I
appologise.
Best Regards,
:) will
William Deakin <·····@pindar.com> writes:
> Chuck Fry wrote:
>
> > But the world you describe is not the real world. NASA managers are not
> > robots; they make decisions based on gut feelings and political rationales,
> > just as managers in industry do.
>
> This is no suprise, but saddens me enormously. That a flag-ship world class
> organisation like NASA is subject to the same ill-informed gossip-based
> prejudiced rubbish as less presidious places of work is a sad, sad thing to
> behold.
Well, that's the way large organizations work, no matter whether
they are part of industry, the military or the administration /
public-services sectors. If you want to avoid this, work for smaller,
independend entities and/or make yourself into one. This isolates you
somewhat from your customers internal problems (but only somewhat)...
Regs, Pierre.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
From: William Deakin
Subject: Re: Ignorance and gossip in the world (was an ignorant subject line)
Date:
Message-ID: <37EB8496.2D9784E9@pindar.com>
"Pierre R. Mai" wrote:
> Well, that's the way large organizations work, no matter whether
> they are part of industry, the military or the administration /
> public-services sectors. If you want to avoid this, work for smaller,
> independend entities and/or make yourself into one. This isolates you
> somewhat from your customers internal problems (but only somewhat)...
Thank you for your good advice. I do work for a "small" company that operates
closely with a large national company. Things are better here (when compare with
the large fish) but still not good.
Best Regards,
:) will
In article <··········@online.no>,
Arne Knut Roev <······@online.no> writes:
> Erann Gat <···@jpl.nasa.gov> wrote:
> ...
> It is perfectly obvious to me that you are:
> ...
> 3) by not taking action in the case of Nasa employees not doing their
> jobs, you are actually condoning that particular behaviour.
>
> To make that third point quite clear: Any person who is in a position to
> choose the tools for solving a technical (/engineering) problem, who is
> basing their choice on anything but cold, hard, technichal, scientific, and
> economical facts, are quite obviously not doing their job. The only possible
> exception to this, is in the cases where you have no such information
> available, in which case research might be a good idea.
i think that Erann was only a few facts of life as he sees them, not
endorsing them. in most companies the engineers have to go through some
approval process when selecting their tools, and unfortunately technical
merit is not the only selection criterion. this especially is true in
organisations where the top brass is appointed by poliyicians
--
Hartmann Schaffer
It is better to fill your days with life than your life with days
From: Erik Naggum
Subject: Re: With friends like Erik, c.l.l doesn't need enemies
Date:
Message-ID: <3147025591031905@naggum.no>
* Erann Gat
| I have found that people rarely make decisions based on first hand
| information. They are much more likely to base their views on gut feel,
| zeitgeist, and the opinions of other people that they like and respect.
| Likewise, people will often take contrary positions to those that they
| don't like and don't respect even in the face of objective evidence.
I'm really happy that you are beginning to realize this, and thus begin
to see why it is necessary to stop people who make false accusations
against others, such as your own absurd claims about the Holocaust.
| Erik is unnecessarily rude and abrasive. He intentionally pushes
| people's hot buttons in the name of stamping out stupidity.
this is just as unwarranted as everything else you're saying about me:
you make new claims that you have no possible way to know the truth of.
| It only takes a few such people with the right connections to make the
| world a hostile place for Lisp.
have you considered how this process applies to your treatment of me?
considering your "insight" into these processes, why do you do your very
best to continue a bunch of hostile myths against me? I can only assume
that your intention is to destroy me and my reputation much faster than
you think I could do on my own, hence your Holocaust allegations and all
this phenomenal crap.
are you proud of what you are saying and implying, Erann Gat? do you
think you further the cause of anything at all with this crap? and do
you _really_ want to blame your inefficacy in convincing people at NASA
to use Lisp on me? what if they heard, or understood, that Erann Gat is
a person who looks for people to blame, rather than try to solve and
understand complex problems? do you think you, as a proponent of Lisp
inside NASA, is doing Lisp a _favor_ by continuing your "blame others"
approach?
| (I tried a new strategy for doing that a few days ago, but I'm afraid I
| failed.)
you failed because you repeat the same thing that gets you into trouble
every time you slander me: you make stupid claims that far exceed any
possible context in which they could have been discovered, which they
haven't, because you lack the precision and care to bother to check
whether what you believe is relevant or fact. I told you explicitly what
you had to do, and I'll gladly repeat it here:
do me a favor and make an effort to understand this: I have said nothing
about what you have not shown me. when you actually understand this fully,
we can discuss your reactions. until you understand that I have said
nothing at all about what you have not shown me, nothing could ever make it
past that lack of understanding.
you continue to prove my point: you speak volumes about that which you
could not possibly know -- it has to be guesswork and insinuation by its
very definition. the above was the crux my last message to you and
nearly the only part you did not quote in your last reply. do you think
I was making a joke? do you not understand that you are extrapolating in
the directions you like from single data points, and that this is the
core of your problem, and the reason I think you're _really_ stupid and a
danger to anyone who trusts you?
| The price we pay for Erik's insights is that job becomes a little harder.
since you know so much about hos I react, why _did_ you post your
slanderous Holocaust argument? and why do you blame me for Raffael
Cavallaro's _initial_ insane accusations? is it because if you accept
that he is responsible for his own accusations, you are fully responsible
for your most insiduous Holocaust crap, too?
| That's why I basically agree with the sentiment expressed by the original
| poster: with friends like Erik, Common Lisp doesn't need enemies.
of course you agree with him. _anyone_ could predict that you would.
you're the same kind of person: the kind of person who attacks me for
things I have never said, who go one-dimensional on any complex issue
(like, now, it's my fault you can't win NASA over to Lisp and you will
have to program in C++ and Perl to make a living)
| I also hope he can be convinced that it would better advance our common
| interest if he would be a little less rude.
do you think you're helping, Erann Gat? what if you understood that the
more you shut your filthy trap, the less need there will be to show that
you're a destructive asshole without the ability to realize when you've
gone too far slandering others falsely and unfairly?
does the Lisp world need Erann Gat and Raffael Cavallaro? does any world?
#:Erik
From: Erik Naggum
Subject: Re: With friends like Erik, c.l.l doesn't need enemies
Date:
Message-ID: <3147036890336451@naggum.no>
* Erann Gat
| What does this have to do with Erik? If you're going to try to change
| people's minds about a self-perpetuating myth the first thing you have to
| do is convince them to pay attention to what you are saying. If people
| tune out then you've lost no matter how right you may be. And if people
| think you are a raving lunatic, or even just an unpleasant person, then
| they tune out.
let's assume for a second that Erann Gat is not the raving lunatic.
let's consider a few facts that may shed some light on how his mortal
fear of losing the battle he has fruitlessly been fighting for ten years
and now needs to blame me for failing to win, bears out in practice.
let's therefore consider the fairly obvious fact that Erann Gats are
everywhere, also in Norway, and the fact that we have Norwegian
newsgroups for both Lisp and Linux, on which I'm obviously active.
for some time, I have answered people's requests for information about
which programming language to use under Linux with "I can send you a CD
so you can try out Allegro CL under Linux". some people could not stop
themselves from pulling an Erann Gat and posted a lot of drivel which
they had no possible way of knowing -- and they were certainly utterly
disdainful of first-hand knowledge, and much preferred to perpetuate
slander and present their prejudiced idiocy as fact and universal fact at
that. now, I don't suffer Norwegian fools any easier than any other
nationality, so obviously, a debate ensued with one local Erann Gat.
the consequence? an enormous interest in Lisp! I have mailed out almost
150 CD's by now. people have been saying "I have to try this!" and have
come back to me for help and with gratitude and suggestions and wish
lists. I set up an IRC channel to help people, but it's become more than
that -- new people to Lisp have tried things I have not even looked at
because it would require too much work in the first couple weeks, some
people have needed to know a lot about fundamentals and have happily been
able to optimize their code well beyond C++, which sort of proved to some
that Lisp was a viable alternative. in Erann Gat's view, and in the
views of our local version of the same screwed-up mentality where fantasy
is a lot easier to deal with than reality, I am of course nothing but
harm, but the crucial question is: harm to _whom_? if I harm prejudiced
fools, who cares? if I cause a lot of interest and positive feedback
among smart people, who not only go away with the best myth-killer they
could get, but some real hard evidence to back up their opinions, who see
ideas that shape their thinking and which they will use to recognize
other people who have been "exposed" to good thinking, why are the few
prejudiced fools who have suffered such a big deal? they can just stop
being prejudiced fools, can't they? seriously, what's holding them back?
they don't think it's _better_ to be prejudiced fools than to know that
of which they speak, do they?
#:Erik
Erik Naggum <····@naggum.no> writes:
> let's therefore consider the fairly obvious fact that Erann Gats are
> everywhere, also in Norway, and the fact that we have Norwegian
> newsgroups for both Lisp and Linux, on which I'm obviously active.
there is, in my opinion, a *huge* difference between the quality
of those postings and those of Erann Gat. The *only* thing he
did "wrong" was to complain to your association of Microsoft with the
Nazis. I do actually think it is possible and permissible to compare
modern PR methods with G�bbels (I'm sure media scientists do that all the
time), but if you do it in the wrong context, people make the wrong
associations.
And, as Godwin's law stated long time ago, the usenet *is* the wrong
context. The only wrong thing Erann did was that he didn't respect
Godwin's law: When the nazis were mentioned first, we should have
ended this thread immediately.
(uh-oh, I'm breaking the law myself :-()
--
regards,
Espen
(who has met Erik IRL and thinks he's a really nice guy ;-))
* Erann Gat wrote:
> Now, it is certainly *not* the case that the sorry state of Lisp (and any
> product that can support only one vendor world-wide is in a sorry state)
> is Erik's responsibility, but in the grand scheme of things I
> believe he does more harm than good.
Are Harlequin and Digitool (and what others?) out of the Lisp business
then? Last thing I heard they were not. Indeed I was reliably
informed shortly after their recent troubles that their Lisp business
was profitable and growing (and absolutely nothing todo with the
troubles: remember that Lisp is rather a small part of what they did).
In the grand scheme of things, *I* believe that these kind of
premature obituaries for Lisp & Lisp companies do quite a lot more
harm than good.
--tim
In article <···············@lostwithiel.tfeb.org>,
Tim Bradshaw <···@tfeb.org> wrote:
>* Erann Gat wrote:
>> Now, it is certainly *not* the case that the sorry state of Lisp (and any
>> product that can support only one vendor world-wide is in a sorry state)
>> is Erik's responsibility, but in the grand scheme of things I
>> believe he does more harm than good.
>
>Are Harlequin and Digitool (and what others?) out of the Lisp business
>then? Last thing I heard they were not. Indeed I was reliably
>informed shortly after their recent troubles that their Lisp business
>was profitable and growing (and absolutely nothing todo with the
>troubles: remember that Lisp is rather a small part of what they did).
Tim is right. While Digitool appears moribund, they are promising a new
release shortly. Harlequin is certainly trimmed down quite a bit, but
they are still actively selling Lisp.
Let me throw in a plug for Digitool's Macintosh Common Lisp. MCL is
very well integrated with the Macintosh environment. Steve Strassman
said several years ago that a PowerBook running MCL was the equivalent
of a portable Lisp Machine. And with modern Power Macintosh hardware
and MCL's PowerPC compiler, MCL is as fast as any workstation Lisp --
and quite a bit cheaper.
(Disclaimer: I do not work for Digitool -- I spent my own money for a
copy of MCL!)
>In the grand scheme of things, *I* believe that these kind of
>premature obituaries for Lisp & Lisp companies do quite a lot more
>harm than good.
Agreed. Does the phrase "self-fulfilling prophecy" mean anything to the
people in this newsgroup??
-- Chuck
--
Chuck Fry -- Jack of all trades, master of none
······@chucko.com (text only please) ········@home.com (MIME enabled)
Lisp bigot, mountain biker, car nut, sometime guitarist and photographer
The addresses above are real. All spammers will be reported to their ISPs.
In article <··············@nntp1.ba.best.com>, ······@best.com (Chuck Fry) wrote:
> Tim is right. While Digitool appears moribund,
Atleast they released CLIM 2.0 for MCL this summer.
> Let me throw in a plug for Digitool's Macintosh Common Lisp. MCL is
> very well integrated with the Macintosh environment. Steve Strassman
> said several years ago that a PowerBook running MCL was the equivalent
> of a portable Lisp Machine. And with modern Power Macintosh hardware
> and MCL's PowerPC compiler, MCL is as fast as any workstation Lisp --
> and quite a bit cheaper.
I think a really small Powerbook would be fun (like some of the
laptops from Sony), booting directly into MCL with a finder
replacement written in CLIM. ;-)
From: R. Matthew Emerson
Subject: MCL advocacy [was Re: With friends like Erik, c.l.l doesn't need enemies]
Date:
Message-ID: <87d7v9biqb.fsf_-_@nightfly.apk.net>
······@best.com (Chuck Fry) writes:
> Let me throw in a plug for Digitool's Macintosh Common Lisp. MCL is
> very well integrated with the Macintosh environment. Steve Strassman
> said several years ago that a PowerBook running MCL was the equivalent
> of a portable Lisp Machine. And with modern Power Macintosh hardware
> and MCL's PowerPC compiler, MCL is as fast as any workstation Lisp --
> and quite a bit cheaper.
>
> (Disclaimer: I do not work for Digitool -- I spent my own money for a
> copy of MCL!)
I paid my own money for MCL as well. The only thing I miss in MCL
(compared to Unix lisp compilers like CMUCL or ACL) is that MCL's
compiler doesn't do much type inferencing, which is an inconvenience
when writing number-crunching and bit-bashing code.
Of course, MCL's inspector and other tools are a big win.
--
R. Matthew Emerson
http://www.thoughtstuff.com/rme/
From: Espen Vestre
Subject: Re: MCL advocacy [was Re: With friends like Erik, c.l.l doesn't need enemies]
Date:
Message-ID: <w6g104kdu4.fsf@wallace.nextel.no>
···@nightfly.apk.net (R. Matthew Emerson) writes:
> I paid my own money for MCL as well. The only thing I miss in MCL
> (compared to Unix lisp compilers like CMUCL or ACL) is that MCL's
> compiler doesn't do much type inferencing, which is an inconvenience
> when writing number-crunching and bit-bashing code.
the FP code has always been, and still is, MCL's weak point (last
time I was annoyed by this was some years ago when I tried out
some computational linguistics 'tagging' code from Xerox PARC).
But I'm quite sure *no* other implementation beats its bignums,
and it's also very, very fast running traditional consing-/recursion-
intensive lisp code. Add to that the fact that it compiles *everything*
*always*.
--
(espen)
From: Tord Kallqvist Romstad
Subject: Re: MCL advocacy [was Re: With friends like Erik, c.l.l doesn't need enemies]
Date:
Message-ID: <slrn7un3hj.6tl.romstad@janus.uio.no>
In article <··············@wallace.nextel.no>, Espen Vestre wrote:
>···@nightfly.apk.net (R. Matthew Emerson) writes:
>
>> I paid my own money for MCL as well. The only thing I miss in MCL
>> (compared to Unix lisp compilers like CMUCL or ACL) is that MCL's
>> compiler doesn't do much type inferencing, which is an inconvenience
>> when writing number-crunching and bit-bashing code.
>
>the FP code has always been, and still is, MCL's weak point (last
>time I was annoyed by this was some years ago when I tried out
>some computational linguistics 'tagging' code from Xerox PARC).
>
>But I'm quite sure *no* other implementation beats its bignums,
>and it's also very, very fast running traditional consing-/recursion-
>intensive lisp code. Add to that the fact that it compiles *everything*
>*always*.
This sounds very interesting. I am considering to buy Apple's new iBook
later this autumn, mainly to run MCL. How much RAM is needed for
comfortable use of MCL?
Tord
From: Espen Vestre
Subject: Re: MCL advocacy [was Re: With friends like Erik, c.l.l doesn't need enemies]
Date:
Message-ID: <w6ln9w57hv.fsf@wallace.nextel.no>
·······@janus.uio.no (Tord Kallqvist Romstad) writes:
> This sounds very interesting. I am considering to buy Apple's new iBook
> later this autumn, mainly to run MCL. How much RAM is needed for
> comfortable use of MCL?
depends on the problem, I have used it with 2,5MB RAM :-) (ok, that was
version 1.3.1 in 1989). Even for running memory-hungry systems like
CL-HTTP, you can do fine with 32MB (assign 18-20 of them to MCL), provided
you keep your system folder reasonably small.
--
(espen)
In article <······················@janus.uio.no>, ·······@janus.uio.no (Tord Kallqvist Romstad) wrote:
> >But I'm quite sure *no* other implementation beats its bignums,
> >and it's also very, very fast running traditional consing-/recursion-
> >intensive lisp code. Add to that the fact that it compiles *everything*
> >*always*.
>
> This sounds very interesting. I am considering to buy Apple's new iBook
> later this autumn, mainly to run MCL. How much RAM is needed for
> comfortable use of MCL?
The MacOS has the problem that you usually need to
statically assign the memory size to the applications.
So, more memory is better. Some tools (Ramdoubler?)
try to optimize memory usage - but I don't really
trust them.
You should be able to use MCL with 64MB in the iBook, though.
ou can also use virtual memory - but VM tends to slow down
the GC quite a bit. If you can afford it, put more memory into the iBook
(I think it has 160 MB max). I have 288 MB in my PowerBook
with 50 MB for MCL with lots of stuff loaded in.
From: R. Matthew Emerson
Subject: Re: MCL advocacy [was Re: With friends like Erik, c.l.l doesn't need enemies]
Date:
Message-ID: <87yadw70r2.fsf@nightfly.apk.net>
······@lavielle.com (Rainer Joswig) writes:
> In article <······················@janus.uio.no>, ·······@janus.uio.no (Tord Kallqvist Romstad) wrote:
>
> > This sounds very interesting. I am considering to buy Apple's new iBook
> > later this autumn, mainly to run MCL. How much RAM is needed for
> > comfortable use of MCL?
>
> The MacOS has the problem that you usually need to
> statically assign the memory size to the applications.
[...]
>
> You should be able to use MCL with 64MB in the iBook, though.
> ou can also use virtual memory - but VM tends to slow down
> the GC quite a bit. If you can afford it, put more memory into the iBook
> (I think it has 160 MB max). I have 288 MB in my PowerBook
> with 50 MB for MCL with lots of stuff loaded in.
On my machine, I can comfortably compile and run CL-HTTP in a 15 MB
memory partition. I agree that you'll definitely want 64MB of memory
if you want to run a decent-sized MCL and a browser at the same time.
If you just want to work on small problems, though, MCL will run fine
in a 5 MB memory partition. CL-HTTP won't fit in 5 MB, though (if
you care about that sort of thing).
-matt
From: Tord Kallqvist Romstad
Subject: Re: MCL advocacy [was Re: With friends like Erik, c.l.l doesn't need enemies]
Date:
Message-ID: <slrn7uufvs.q7p.romstad@janus.uio.no>
Thanks to everybody for the answers!
Tord
From: Dobes Vandermeer
Subject: Re: With friends like Erik, c.l.l doesn't need enemies
Date:
Message-ID: <37EDD178.E206D9D0@mindless.com>
Tim Bradshaw wrote:
>
> * Erann Gat wrote:
>
> > Now, it is certainly *not* the case that the sorry state of Lisp (and any
> > product that can support only one vendor world-wide is in a sorry state)
> > is Erik's responsibility, but in the grand scheme of things I
> > believe he does more harm than good.
>
> Are Harlequin and Digitool (and what others?) out of the Lisp business
> then? Last thing I heard they were not. Indeed I was reliably
> informed shortly after their recent troubles that their Lisp business
> was profitable and growing (and absolutely nothing todo with the
> troubles: remember that Lisp is rather a small part of what they did).
>
> In the grand scheme of things, *I* believe that these kind of
> premature obituaries for Lisp & Lisp companies do quite a lot more
> harm than good.
Lots of people develop lots of things... LISP isn't dead, but if are
willing to take the perspective of, say, LISP becoming one of the most
popular programming languages then perhaps you could say "LISP is in a
sorry state". Because the newsgroup medium isn't interactive, it can be
too easy to misinterpret what people are saying, but I'd say its
generally best to take the most optimistic perspective.
What he's saying is, if you walk into a random software firm somewhere,
and say "Hello, how many people here have programmed in LISP", a few
people might say, "I've heard of it ....". The results would not be
terribly exciting. comp.lang.c++ has 10,000 posts where comp.lang.lisp
has 1000 posts (well, in that little list of newsgroups)
This says nothing about that quality of LISP, or the available support,
but the *popularity* of LISP. This is what Erann is probably
complaining about, and I don't blame him. I wish that LISP, Scheme,
Objective-C, Smalltalk, Self, ML, Oberon, E, Prolog, and these other
specialised languages were more popular.. the dominance of C/C++ is a
sad monopoly in the vein of Windows dominating the market. Variety is
prosperity, so if people were to learn more languages they woudl be
better prepared to choose the correct language for the job... which
would sometimes be LISP.
CU
Dobes
From: William Deakin
Subject: Re: With friends like Erik, c.l.l doesn't need enemies
Date:
Message-ID: <37F09C85.C4C4109@pindar.com>
Erik Naggum wrote:
> I don't see popularity as a desirable goal. (hold the jokes, please. ;)
Awww.
> as for newsgroup volume, ever wondered why people who don't like their
> cars or houses or neighborhood or whatever talk a lot about it while
> those who like what they have very much don't talk about it but use the
> comfort to productive ends? ever noticed how people react when you say
> unfounded bad things about that which they really like?
So true. The whole of the news industry is based on "bad things" happending
Also: "It's not when dog bites man that it is news. It is when man bites dog"
(but I cannot remember the attributions).
Cheers,
:) will
From: Dobes Vandermeer
Subject: Re: With friends like Erik, c.l.l doesn't need enemies
Date:
Message-ID: <37F01B07.90C565F0@mindless.com>
Erik Naggum wrote:
>
> * Dobes Vandermeer <·····@mindless.com>
> | LISP isn't dead, but if are willing to take the perspective of, say, LISP
> | becoming one of the most popular programming languages then perhaps you
> | could say "LISP is in a sorry state".
>
> and people who aren't willing to take this stupid perspective are not
> open-minded enough for you, so you consequently discard their opinions?
No... I merely presented the possibility that you could take that
perspective.
> has it occurred to you that it is always possible to look at things in
> such a way as to end up in a sorry state? the question people should ask
> is why you need to do that.
>
> a much more interesting question is which _set_ of perspectives yields a
> positive and upward-looking state and then ponder how to add (or, as may
> be necessary, remove) perspectives from this set. (you could cheat in
> this respect and ask for a perspective like "becoming an unused fringe
> language" and claim that Lisp is doing great, but even this exercise will
> yield a useful psychological message: "Lisp is doing great". ;)
True enough.
> | I wish that LISP, Scheme, Objective-C, Smalltalk, Self, ML, Oberon, E,
> | Prolog, and these other specialised languages were more popular.. the
> | dominance of C/C++ is a sad monopoly in the vein of Windows dominating
> | the market.
>
> but whatever would popularity as such buy you? popularity just happens
> to most things, and they fare extremely badly afterwards. most people
> who became popular get into serious problems. most products that become
> popular change into something that is easier to mass produce, and the
> logistics of easy production take over as the primary quality concern.
I'll have to assume this is just your opinion... In my experience things
benefit from popularity, and the case you describe happens less often.
Take computers as the most obvious example... would you rather you were
still slotting punch cards, because computers never became popular
enough to gain the funding to achieve the price/size/performance we see
today? Of course, computers are a cliche example, but I hope you can
see what I mean. Certainly the result of popularity is that the product
changes in a way to make it *more* popular, which may not be the
direction that individuals (like you or me) would necessarily approve
of, but with an ANSI spec the changes woudl be more in use, not in the
language itself.
> as for newsgroup volume, ever wondered why people who don't like their
> cars or houses or neighborhood or whatever talk a lot about it while
> those who like what they have very much don't talk about it but use the
> comfort to productive ends? ever noticed how people react when you say
> unfounded bad things about that which they really like? (yeah, I guess
> you have, but you label us crazy, instead.) why is comp.lang.lisp about
> bad things _weakly related_ to Lisp, while comp.lang.c++ is all about bad
> things in the language?
Are you arguing that my mesaurement of newsgroups volume was invalid, or
that lisp is in fact popular? I'll be the first to admit that the
amount of traffic on a newsgroup isn't the best measure of popularity.
However, a quick browse onto recent messages on comp.lang.c++ seem to be
discussing fairly sane positive topics. Mostly "How do I do..", "How
does this work...", "Where can I learn..." sorts of questions/answers,
combined with discussions about the construction of useful class
libraries etc. Not much "damn I hate C++" going on at all, nor do I see
any advocacy posts. On what do you base your view that comp.lang.c++ is
all about bad things in the language? If you are referring to the way
that people often run into difficulties using some of the myriad of C++
language features (which I'll admit tend to lead to trouble) then I
would suggest that similar posts happen here, although with less
volume. The messages on comp.lang.lisp are not so different; depending
on your background many of the features of lisp can be surprising and
confusing, even if lisp is more orthogonal.
CU
Dobes
Dobes Vandermeer <·····@mindless.com> wrote in message
······················@mindless.com...
>...
> I'll have to assume this is just your opinion... In my experience things
> benefit from popularity, and the case you describe happens less often.
> Take computers as the most obvious example... would you rather you were
> still slotting punch cards, because computers never became popular
> enough to gain the funding to achieve the price/size/performance we see
> today? Of course, computers are a cliche example, but I hope you can
>...
Going from punch cards to terminal to PCs and workstation as nothing to do
with popularity but with technology and productivity. Even if computers were
not popular, nobody would still use punch cards because it's quite more
expensive and less productive than using a monitor and a keyboard.
It's not popularity that made the transition from hexadecimal program entry
to a language like Lisp.
Don't reverse cause and effect.
Marc Battyani
From: Erik Naggum
Subject: Re: With friends like Erik, c.l.l doesn't need enemies
Date:
Message-ID: <3147499986603090@naggum.no>
* Dobes Vandermeer <·····@mindless.com>
| In my experience things benefit from popularity, and the case you
| describe happens less often.
it's a law in economics (which means just a self-reinforcing opinion)
that high production volume is incompatible with high quality. certain
properties of what we call high quality cost more the higher the volume,
while certrain properties cost less the higher the volume. e.g., any
aspect of the quality that involves human interaction has to go when the
volume becomes high enough.
| Take computers as the most obvious example...
great example! all the really nice CPU's are relegated to fringe
markets, and instead we have Intel all over the place. because of
Intel's popularity, they have had to maintain backward compatibility
with the first 8086 and not only through every step, but globally.
| Of course, computers are a cliche example, but I hope you can see what I
| mean.
of course, you focus on the properties that survive popularity and are
happy with them. I look at what went by the wayside. that's because I
take the quality view, and I like Common Lisp. if we were to take your
view, Lisp would be dead (if you're searching the Net, I'm refuting it)
and we should be happy with whatever is most popular. I don't think this
is a valid argument.
| Are you arguing that my mesaurement of newsgroups volume was invalid, or
| that lisp is in fact popular? I'll be the first to admit that the amount
| of traffic on a newsgroup isn't the best measure of popularity.
newsgroup volume is a measure of discontent.
| On what do you base your view that comp.lang.c++ is all about bad things
| in the language?
because people don't understand the language and need help with even the
simplest things, despite a plethora of literature and courses. (now,
tell me again why lots and lots of C++ _books_ aren't proving that
popularity lowers the quality threshold to entrance to the market...)
| If you are referring to the way that people often run into difficulties
| using some of the myriad of C++ language features (which I'll admit tend
| to lead to trouble) then I would suggest that similar posts happen here,
| although with less volume.
the relevant issue is the relative volume.
| The messages on comp.lang.lisp are not so different; depending on your
| background many of the features of lisp can be surprising and confusing,
| even if lisp is more orthogonal.
you can always find _some_ similarities. the question is whether they
are relevant.
#:Erik
From: Dobes Vandermeer
Subject: Re: The value (?) of popularity (was Re: With friends like Erik, c.l.l doesn't need enemies)
Date:
Message-ID: <37F18342.F720CCD3@mindless.com>
Erik Naggum wrote:
>
> * Dobes Vandermeer <·····@mindless.com>
> | In my experience things benefit from popularity, and the case you
> | describe happens less often.
>
> it's a law in economics (which means just a self-reinforcing opinion)
> that high production volume is incompatible with high quality. certain
> properties of what we call high quality cost more the higher the volume,
> while certrain properties cost less the higher the volume. e.g., any
> aspect of the quality that involves human interaction has to go when the
> volume becomes high enough.
OK, fair enough. But the decrease in quality comes with the apparent
advantages of growth and prosperity. Below, you yourself disparage
about things (CPU architectures, in that case) that have "gone to the
wayside". There was a time when I treasured my Amiga because it was not
only the best PC technology I could find, but it had a plethora of
software and user groups available. Now, the Commodore Amiga company
has gone under, and Amigas are unmaintainable, and nigh unavailable
completely. Gateway technologies hopes to use the Amiga name on a new
series of products, but the real demise of the Amiga was a lack of
marketing and thus a lack of popularity. Without interest there is only
disappearance and death, and this makes popularity seem essential to
me. LISP is by no means on that path (yet), but it seems (to me) to be
almost a general opinion that it is not as popular as we'd like, either.
> | Of course, computers are a cliche example, but I hope you can see what I
> | mean.
>
> of course, you focus on the properties that survive popularity and are
> happy with them. I look at what went by the wayside. that's because I
> take the quality view, and I like Common Lisp. if we were to take your
> view, Lisp would be dead (if you're searching the Net, I'm refuting it)
> and we should be happy with whatever is most popular. I don't think this
> is a valid argument.
I would hesitate to say that I am completely happy with them, but I
prefer that computers are popular, and thus readily available and
growing rapidly, than that they would have "fallen to the wayside"
because they lost a battle with a competing inferior technology... I can
tolerate the lowering of quality on the microscopic scale because of the
increase in quality overall.
The choice in CPU on a machine only seems relevant for assembly-language
proamming and nitpicking; Standards such as CL, CLIM, and CLOS protect
us from the details of the inferior processor we are running on and
allow us to work in a more comfortable programming environment whatever
CPU or operating system lies beneath. Thats part of what attracted me
(and others) to LISP, is its rich library of abstract constructs, and
the powerful ways you can add and extend the library with minimal
effort.
> | Are you arguing that my mesaurement of newsgroups volume was invalid, or
> | that lisp is in fact popular? I'll be the first to admit that the amount
> | of traffic on a newsgroup isn't the best measure of popularity.
>
> newsgroup volume is a measure of discontent.
Ha! Well I cant fight that... although on this newsgroup its not so
much with LISP as between subscribers :)
> | On what do you base your view that comp.lang.c++ is all about bad things
> | in the language?
>
> because people don't understand the language and need help with even the
> simplest things, despite a plethora of literature and courses. (now,
> tell me again why lots and lots of C++ _books_ aren't proving that
> popularity lowers the quality threshold to entrance to the market...)
I doubt that the volume of books available has bearing on the topic
requiring extensive coverage. Many people are buying books at random,
so you just have to get yours on the shelf and someone will buy it.
Also, the books aren't on unique topics, they just have unique drawings
on their covers. There are, for example, many books on introductory
calculus; these books cover the exact same material, and cover a
well-known topic which we have no reason to believe is as flawed as C++.
CU
Dobes
* Dobes Vandermeer <·····@mindless.com>
| But the decrease in quality comes with the apparent advantages of growth
| and prosperity.
yes, that's exactly it: apparent.
| Without interest there is only disappearance and death, and this makes
| popularity seem essential to me.
popularity is essential for the mass market. the sustainability in other
markets, of which most are far more interesting than the mass market, is
damaged by popularity, meaning interest from the general population. for
instance, enormous markets are dependent on company-to-company sales and
would be completely unable to educate enough people to deal with regular
joes as customers. these are the professional markets. I stay clear of
the consumer markets whenever possible, and go through a lot of work to
get professional products. the really sad thing is that they often cost
_less_ than the consumer products, but if they volume went up, so would
the price. for instance, doctors, dentists, and vets use this highly
absorbant material to clean up leaking body liquids of all colors and
contents, and I got a bunch of this material when my cat had an operation
and she did not have bladder control while recovering from anesthesia.
so of course I bought 10 lbs of this stuff from my vet -- it far exceeds
the absorbancy of _any_ of the consumer paper towels on the market and a
box of 10 lbs costs the same as about 4 lbs of consumer paper towels.
now, the reason for the low price and high quality is that people don't
know about it, don't need to buy small units of it that are convenient to
households (it comes in stacks of individual sheets, not rolls) in all
sorts of stores, and there's no marketing for it at all. which means: no
sales force to talk to all the stores or chains that might stock it, no
shipping costs to absord into a retail price (the purchasers pay for the
shipping from the one outlet in the entire country), etc, etc, etc. this
stuff would end up costing more than five times as much as it does today
if it were to hit the consumer market (of course I asked the people who
make it). which probably explains why the paper towels are all low
quality: the cost of producing a roll of paper towels is less than 10% of
the price customers are paying for it.
| LISP is by no means on that path (yet), but it seems (to me) to be almost
| a general opinion that it is not as popular as we'd like, either.
Lisp is a professional product in the professional market. it would be
very seriously harmed by becoming a consumer product.
| I would hesitate to say that I am completely happy with them, but I
| prefer that computers are popular, and thus readily available and
| growing rapidly, than that they would have "fallen to the wayside"
| because they lost a battle with a competing inferior technology...
huh? Intel and Windows _are_ inferior technology and they're winning,
leaving all the quality designs by the wayside.
| I can tolerate the lowering of quality on the microscopic scale because
| of the increase in quality overall.
but we have a decrease in overall quality! 40 years ago, producing a
business letter had a cost relative to company expenditures in general
that was about half of what it is today.
| The choice in CPU on a machine only seems relevant for assembly-language
| programming and nitpicking;
really? ever heard of any of the numerous Intel bugs?
| Standards such as CL, CLIM, and CLOS protect us from the details of the
| inferior processor we are running on and allow us to work in a more
| comfortable programming environment whatever CPU or operating system lies
| beneath.
this is not true. somebody has to care about the CPU to make the
software run on it. making highly optimized code for something so
braindamaged as the Intel instruction set, which isn't even relevant to
optimization, anymore, as the underlying parallelized microcode-like
instructions have everything to do with the pipeline, cache, etc, is so
hard that it takes _years_ of effort to get it optimal. I have seen code
that ran 8 times faster just by reordering the instructions on a Pentium
II. stuff like this matters a lot more than people would like to believe
when they use high-level languages, because the computer doesn't go away
just because we don't _have_ to worry about it all the time. we _should_
worry about it, but not all the time, and not for everything we do.
| Thats part of what attracted me (and others) to LISP, is its rich library
| of abstract constructs, and the powerful ways you can add and extend the
| library with minimal effort.
all fine and dandy, but it has to run on a real CPU, and there's a
dramatic difference in CPU's that make running anything useful on them
easy or hard. this translates to sluggishness of development and
adoption of new instruction sets. look at the SPARC -- it has managed to
upgrade itself 6 or 7 times, and have changed a lot in the meantime,
because the users were professional users who upgraded everything or were
satisfied with software emulation of various instructions. the Intel CPU
can still run 8086 code, because consumers hold on to old software even
when they upgrade the hardware, and the third-party investment in the old
instruction set is so enormous that they couldn't change it dramatically
without risking that nobody would follow them. this leads to CPU's that
are _very_ expensive by today's technological standards. done right, a
new chip could cost a lot less and run a lot faster, and we have it:
Digital Equipment Corporation (rest the blessed soul) produced the first
processor to break the 100MHz barrier, and it's still amazingly fast. of
course, with despicable Compaq buying it all up, it's going to run the #1
sluggish software in the world: NT, so it basically runs just as slowly
as Linux on a computer two Intel generations ago. that's how the world
doesn't win through popularity contests.
#:Erik
From: Christopher R. Barry
Subject: Re: The value (?) of popularity
Date:
Message-ID: <874sgdqnzx.fsf@2xtreme.net>
Erik Naggum <····@naggum.no> writes:
> these are the professional markets. I stay clear of the consumer
> markets whenever possible, and go through a lot of work to get
> professional products. the really sad thing is that they often cost
> _less_ than the consumer products, but if they volume went up, so
> would the price.
[...]
> it far exceeds the absorbancy of _any_ of the consumer paper towels
> on the market and a box of 10 lbs costs the same as about 4 lbs of
> consumer paper towels. now, the reason for the low price and high
> quality is that people don't know about it, don't need to buy small
> units of it that are convenient to households (it comes in stacks of
> individual sheets, not rolls) in all sorts of stores, and there's no
> marketing for it at all.
[...]
> done right, a new chip could cost a lot less and run a lot faster,
> and we have it: Digital Equipment Corporation (rest the blessed
> soul) produced the first processor to break the 100MHz barrier, and
> it's still amazingly fast.
Are you talking about the price that you must pay to purchase
professional products or the cost of manufacturing professional
products? All in all, the full cost of producing an Alpha processor
taking into account everything (particularly R&D and marketing) is
probably less than that of an Intel processor, but the cost of
purchasing a motherboard with a late-model of this processor -- no
matter who you go to -- is _significantly_ greater than going to
http://www.pricewatch.com and buying Intel-compatible processors that
will give you significantly higher system performance for the same
cost. A lot of people say that Alphas offer the best
price/performance, but when I seriously investigated purchasing an
Alpha system, this turned out to not be the case at all.
What I'm saying with all of this is that the situation with the
super-absorbent stuff, which costs less than consumer stuff but offers
better performance, is not really analogous to the situation with the
Alpha processor, which costs a lot more than a consumer (Intel) system
that delivers comparable performance for many applications like Apache
servers, RDBMSs, Beowulf clustering, etc....
You even went with a dual P-II 400MHz system with 512MB for your own
personal development system. [IIRC.]
[Don't hesitate to provide me with a professional contact for cheap
Alpha hardware and prove me wrong! :-) ]
Christopher
······@2xtreme.net (Christopher R. Barry) writes:
> Are you talking about the price that you must pay to purchase
> professional products or the cost of manufacturing professional
> products? All in all, the full cost of producing an Alpha processor
> taking into account everything (particularly R&D and marketing) is
> probably less than that of an Intel processor, but the cost of
> purchasing a motherboard with a late-model of this processor -- no
> matter who you go to -- is _significantly_ greater than going to
> http://www.pricewatch.com and buying Intel-compatible processors that
> will give you significantly higher system performance for the same
> cost. A lot of people say that Alphas offer the best
> price/performance, but when I seriously investigated purchasing an
> Alpha system, this turned out to not be the case at all.
AFAIK the motherboard is the main cost driver here, whereas the chips
themselves can be had for competitive prices. Since the AMD K7/Athlon
chips also use the EV6+ bus now, some hope that this might also drive
down costs for Alpha motherboards, seeing that much of the design and
chips probably could be shared with high-volume K7 boards.
Regs, Pierre.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
"Christopher R. Barry" wrote:
>
> What I'm saying with all of this is that the situation with the
> super-absorbent stuff, which costs less than consumer stuff but offers
> better performance, is not really analogous to the situation with the
> Alpha processor, which costs a lot more than a consumer (Intel) system
> that delivers comparable performance for many applications like Apache
> servers, RDBMSs, Beowulf clustering, etc....
The new PowerPC's (G4s) aren't so expensive.. I think they ring in a
fair bit cheaper than new Pentiums (at the same performance levels), and
lately might even be available with a decent operating system (i.e. Mac
OS X Server).
CU
Dobes
From: Christopher R. Barry
Subject: Re: The value (?) of popularity
Date:
Message-ID: <871zbgrfx8.fsf@2xtreme.net>
Dobes Vandermeer <·····@mindless.com> writes:
> "Christopher R. Barry" wrote:
> >
> > What I'm saying with all of this is that the situation with the
> > super-absorbent stuff, which costs less than consumer stuff but offers
> > better performance, is not really analogous to the situation with the
> > Alpha processor, which costs a lot more than a consumer (Intel) system
> > that delivers comparable performance for many applications like Apache
> > servers, RDBMSs, Beowulf clustering, etc....
>
> The new PowerPC's (G4s) aren't so expensive.. I think they ring in a
> fair bit cheaper than new Pentiums (at the same performance levels), and
> lately might even be available with a decent operating system (i.e. Mac
> OS X Server).
Can you purchase just PowerPC CPUs + motherboards yet? If so, where?
If not, where are they selling G4 systems offering performance for the
dollar similar to Intel stuff at http://www.pricewatch.com or
http://www.shopper.com?
There are good reasons to go for a Mac anyways for certain kinds of
applications (because of the MacOS and all the media-design tools, not
the hardware). They have the nicest on-screen font rendering of any of
the systems I've used; certainly better than awful Unix. (Yeah, I've
got an extra TTF font server installed + a few hundred high-quality
fonts and they still render like crap compared to Windows with the
font-smoother or particularly the Mac.)
Christopher
"Christopher R. Barry" wrote:
>
> Dobes Vandermeer <·····@mindless.com> writes:
>
> > "Christopher R. Barry" wrote:
> > >
> > > What I'm saying with all of this is that the situation with the
> > > super-absorbent stuff, which costs less than consumer stuff but offers
> > > better performance, is not really analogous to the situation with the
> > > Alpha processor, which costs a lot more than a consumer (Intel) system
> > > that delivers comparable performance for many applications like Apache
> > > servers, RDBMSs, Beowulf clustering, etc....
> >
> > The new PowerPC's (G4s) aren't so expensive.. I think they ring in a
> > fair bit cheaper than new Pentiums (at the same performance levels), and
> > lately might even be available with a decent operating system (i.e. Mac
> > OS X Server).
>
> Can you purchase just PowerPC CPUs + motherboards yet? If so, where?
> If not, where are they selling G4 systems offering performance for the
> dollar similar to Intel stuff at http://www.pricewatch.com or
> http://www.shopper.com?
Well you can get them at AppleStore right now:
http://store.apple.com/1-800-795-1000/WebObjects/AppleStore?family=G4
$1,599 - 400MHz G4 with 64M RAM, 10GB HD
$2,499 - 450MHz G4 with 128M RAM, 20GB HD
$3,499 - 500MHz G4 with 256M RAM, 27GB HD
They seem to include a 56k modem, a 10/100BT card, a CDROM and an ATI
RAGE 128, the 450MHz+ ones have a DVD-ROM. It looks like only the
400Mhz version is available now, while the others have increasing
waiting times. I've heard Apple tends to choose high quality hardware
in their systems (although the choice of the ATI rage is a little
disappointing, I'd rather see something else there). It might also be
possible to build your own systems, but Macintosh has traditionally been
against customization and expansion.
CU
Dobes
From: Christopher R. Barry
Subject: Re: The value (?) of popularity
Date:
Message-ID: <873dvvpphj.fsf@2xtreme.net>
Dobes Vandermeer <·····@mindless.com> writes:
> > Can you purchase just PowerPC CPUs + motherboards yet? If so, where?
> > If not, where are they selling G4 systems offering performance for the
> > dollar similar to Intel stuff at http://www.pricewatch.com or
> > http://www.shopper.com?
>
> Well you can get them at AppleStore right now:
>
> http://store.apple.com/1-800-795-1000/WebObjects/AppleStore?family=G4
>
> $1,599 - 400MHz G4 with 64M RAM, 10GB HD
> $2,499 - 450MHz G4 with 128M RAM, 20GB HD
> $3,499 - 500MHz G4 with 256M RAM, 27GB HD
>
> They seem to include a 56k modem, a 10/100BT card, a CDROM and an ATI
> RAGE 128, the 450MHz+ ones have a DVD-ROM.
The hard disks aren't SCSI, the ATI RAGE 128 cards stink (I believe
new NVidia and Matrox cards are made for Macs, so I don't know why
they don't make these with those instead), and the ones you listed
don't include a monitor.
I also searched that site for quite some time to see what software
they bundle with the things. If they give you Photoshop 5.0 and a
bunch of other good stuff with all of them, then it might not be that
bad....
Try pricing an imaginary system at http://www.pricewatch.com. You
could get more memory, a faster processor, and a large UltraWide-2 SCSI
disk and probably even have enough left over for a monitor....
Christopher
* Christopher R. Barry
| You even went with a dual P-II 400MHz system with 512MB for your own
| personal development system. [IIRC.]
that I did, and the reason was that I needed a Linux system that ran on
an Intel for a bunch of other reasons.
#:Erik
Erik Naggum wrote:
>
> * Dobes Vandermeer <·····@mindless.com>
> | But the decrease in quality comes with the apparent advantages of growth
> | and prosperity.
>
> yes, that's exactly it: apparent.
>
> | Without interest there is only disappearance and death, and this makes
> | popularity seem essential to me.
>
> popularity is essential for the mass market.
> which probably explains why the paper towels are all low
> quality: the cost of producing a roll of paper towels is less than 10% of
> the price customers are paying for it.
Hmm... that is disturbingly true.
> | I would hesitate to say that I am completely happy with them, but I
> | prefer that computers are popular, and thus readily available and
> | growing rapidly, than that they would have "fallen to the wayside"
> | because they lost a battle with a competing inferior technology...
>
> huh? Intel and Windows _are_ inferior technology and they're winning,
> leaving all the quality designs by the wayside.
I was referring to computers in general; they are (heavily) market
driven currently, and I think that this is probably what has allowed the
leaps and bounds in computer technology in the last while. The powerful
appeal of fast computers has provided the computing industry with the
funds required to rapidly advance computer technology. A small group of
professionals could still have advanced computing, but not at nearly the
rate; professionals by common definition work for money, so less money
means fewer professionals.
> | LISP is by no means on that path (yet), but it seems (to me) to be almost
> | a general opinion that it is not as popular as we'd like, either.
>
> Lisp is a professional product in the professional market. it would be
> very seriously harmed by becoming a consumer product.
The impression that I have is that LISP (esp. CL) is basically a
de-facto standard for Artificial Intelligence (And Applied AI)
prototyping, especially at eductional and research facilities. This may
be the professional audience to which you refer.
If so, then you are right; Lisp IS a professional product in the
professional (i.e. educational and research) market.
I can only question whether entrance into the mass market is powerful
enough to seriously harm a strongly standardized language like LISP
(well, ANSI CL).
Do you know of similar products (i.e. programming languages) which were
seriously harmed by entering the consumer market?
Languages that are common in the mass market now are C, Java, C++,
Visual Basic, and Pascal (Delphi etc.). These languages, as far as I
can tell, were not changed by the introduction to the mass market at
all; in some cases they were improved somewhat (such as Borlands
additions to Delphi to make it object-oriented). C is also an ANSI
standard, and it is a language I continue to enjoy programming in; I
would gladly choose C over LISP where operations involving table
scanning or string and buffer manipulation were involved, if only
because of the compressed syntax (and possibly increased performance).
> | I can tolerate the lowering of quality on the microscopic scale because
> | of the increase in quality overall.
>
> but we have a decrease in overall quality! 40 years ago, producing a
> business letter had a cost relative to company expenditures in general
> that was about half of what it is today.
Are you certain? This sounds more like a hipshot than a known thing,
considering the reason businesses turn to increases in technology is to
reduce costs.
> | Standards such as CL, CLIM, and CLOS protect us from the details of the
> | inferior processor we are running on and allow us to work in a more
> | comfortable programming environment whatever CPU or operating system lies
> | beneath.
>
> this is not true. somebody has to care about the CPU to make the
> software run on it. making highly optimized code for something so
> braindamaged as the Intel instruction set, which isn't even relevant to
> optimization, anymore, as the underlying parallelized microcode-like
> instructions have everything to do with the pipeline, cache, etc, is so
> hard that it takes _years_ of effort to get it optimal. I have seen code
> that ran 8 times faster just by reordering the instructions on a Pentium
> II. stuff like this matters a lot more than people would like to believe
> when they use high-level languages, because the computer doesn't go away
> just because we don't _have_ to worry about it all the time. we _should_
> worry about it, but not all the time, and not for everything we do.
OK. You are saying that you DO have to worry about the underlying CPU,
because it will affect price and performance ?
> | Thats part of what attracted me (and others) to LISP, is its rich library
> | of abstract constructs, and the powerful ways you can add and extend the
> | library with minimal effort.
>
> all fine and dandy, but it has to run on a real CPU, and there's a
> dramatic difference in CPU's that make running anything useful on them
> easy or hard.
Yes, but thats an issue for the CL implementor to resolve; if it turns
out that performance is too poor on a given platform it is trivial to
move your software to another, provided the same programming environment
is available there. If you wrote your program in Assembly Language (as
people once did) you no longer have that option.
> look at the SPARC -- it has managed to
> upgrade itself 6 or 7 times, and have changed a lot in the meantime,
> because the users were professional users who upgraded everything or were
> satisfied with software emulation of various instructions.
I think Sun's marketing approach probably played a strong roel in this
too, though. AFAIK Sun generally just asks you want you want to do
(i.e. how fast a connection, how many clients) and then arbitrate a
machine and price to you. If you need a faster machine, they take yours
away (maybe) and sell you a new one. Consumer stuff was targetted at
people who are too cheap to upgrade their hardware, and when they
finally do they wont upgrade their software. I suppose that THIS is the
damaging effect that the mass market had on computers; they wanted
backwards compatibility.
> the Intel CPU
> can still run 8086 code, because consumers hold on to old software even
> when they upgrade the hardware, and the third-party investment in the old
> instruction set is so enormous that they couldn't change it dramatically
> without risking that nobody would follow them.
Mainly I think they were worried about losing popularity... just to tie
it back into the thread :)
> done right, a
> new chip could cost a lot less and run a lot faster, and we have it:
> Digital Equipment Corporation (rest the blessed soul) produced the first
> processor to break the 100MHz barrier, and it's still amazingly fast.
100 or 1000 MHz barrier? I didn't know there was a barrier at 100MHz
anymore :)
CU
Dobes
Dobes Vandermeer <·····@mindless.com> writes:
> The impression that I have is that LISP (esp. CL) is basically a
> de-facto standard for Artificial Intelligence (And Applied AI)
> prototyping, especially at eductional and research facilities. This may
> be the professional audience to which you refer.
I'm sure that many people have that same impression, but I think that
Lisp can win in other areas, too. I don't consider myself an AI
person: I'm using Lisp for systems programming, computer graphics,
number crunching, and networking.
> Do you know of similar products (i.e. programming languages) which were
> seriously harmed by entering the consumer market?
I would say that the Java language has been harmed by Sun's efforts to
gain mass-market mindshare by hyping it so much. I don't think that
it had enough time to incubate before Sun pushed it out into the world
as the great alternative to the Microsoft hegemony.
> > [Erik Naggum wrote this paragraph:]
> > this is not true. somebody has to care about the CPU to make the
> > software run on it. making highly optimized code for something so
> > braindamaged as the Intel instruction set, which isn't even relevant to
> > optimization, anymore, as the underlying parallelized microcode-like
> > instructions have everything to do with the pipeline, cache, etc, is so
> > hard that it takes _years_ of effort to get it optimal. I have seen code
> > that ran 8 times faster just by reordering the instructions on a Pentium
> > II. stuff like this matters a lot more than people would like to believe
> > when they use high-level languages, because the computer doesn't go away
> > just because we don't _have_ to worry about it all the time. we _should_
> > worry about it, but not all the time, and not for everything we do.
>
> OK. You are saying that you DO have to worry about the underlying CPU,
> because it will affect price and performance ?
One can say "oh, the processor doesn't matter; the compiler guys will
figure it all out for me," but I've never thought that was a very
strong argument. Compiler guys have limited time, just like the rest
of us. I would bet that for a given amount of time, you'd get less
improvement working on improved x86 code generation than you would
working for an equivalent amount of time on improving code generation
for MIPS or SPARC or something else decent.
It's also a lot easier to read the output of #'disassemble on a MIPS
or SPARC.
And don't even get me started about floating point on the x86.
-matt
"R. Matthew Emerson" wrote:
>
> Dobes Vandermeer <·····@mindless.com> writes:
>
> > The impression that I have is that LISP (esp. CL) is basically a
> > de-facto standard for Artificial Intelligence (And Applied AI)
> > prototyping, especially at eductional and research facilities. This may
> > be the professional audience to which you refer.
>
> I'm sure that many people have that same impression, but I think that
> Lisp can win in other areas, too. I don't consider myself an AI
> person: I'm using Lisp for systems programming, computer graphics,
> number crunching, and networking.
Personally, these are exactly the fields I avoid with LISP, mostly
because I haven't really been able to get my hands on good libraries
that fill these roles. Number crunching is about the only one that
seems to be in the ANSI standard, but computer graphics and networking
might be somewhat of a problem case. Does CLOS have any good
distributed objects protocols? I understand you can use CORBA, but that
doesn't count as a *good* protocol to me so much as one that "works",
because it lacks features like self-describing objects (to eliminate the
need for IDL) and clever namespace tactics.
> > Do you know of similar products (i.e. programming languages) which were
> > seriously harmed by entering the consumer market?
>
> I would say that the Java language has been harmed by Sun's efforts to
> gain mass-market mindshare by hyping it so much. I don't think that
> it had enough time to incubate before Sun pushed it out into the world
> as the great alternative to the Microsoft hegemony.
Yeah, you're right with that one.. perhaps popularity, or more
importantly the things done to achieve popularity, is fairly damaging.
However, Java is better than C++ because it provides a valuable class
library with the language which provides a host of features not
typically included in a language. In fact, no other standard library
for a language that I have seen includes built-in classes for all of
networking, threading, encoding, parsing, etc. The closest to that
level I can think of off the top of my head is OpenStep's Foundation
Framework for Objective-C.
CU
Dobes
Dobes Vandermeer <·····@mindless.com> writes:
> "R. Matthew Emerson" wrote:
> >
> > I'm sure that many people have that same impression, but I think that
> > Lisp can win in other areas, too. I don't consider myself an AI
> > person: I'm using Lisp for systems programming, computer graphics,
> > number crunching, and networking.
>
> Personally, these are exactly the fields I avoid with LISP, mostly
> because I haven't really been able to get my hands on good libraries
> that fill these roles. Number crunching is about the only one that
> seems to be in the ANSI standard, but computer graphics and networking
> might be somewhat of a problem case. Does CLOS have any good
> distributed objects protocols? I understand you can use CORBA, but that
> doesn't count as a *good* protocol to me so much as one that "works",
> because it lacks features like self-describing objects (to eliminate the
> need for IDL) and clever namespace tactics.
Nothing in the CORBA standard prohibits implementations from
generating the IDL automatically from information already present in
the implementation. I'd guess that it would be quite feasible to
implement a meta-class using the MOP that accepts enough information
so that the IDL description can be generated automatically. The
interface description can then be used either in the normal way
(i.e. to generate, compile and link stubs in other languages), and/or
kept in an Interface Repository for use via DII/DSI at run-time.
I don't think you can get much more self-describing than this. Now I
would have been with you if you had accused CORBA of being overly
complex for same language/implementation solutions, which OTOH is to
be expected of an architecture that tries to be cross-language, cross-
platform and cross-network.
I don't know what you mean by clever namespace tactics, but would be
interested to know more. Maybe the Interface/Namespace split that ILU
does in ISL would be interesting to you?
OTOH if you only use CLOS, it should be quite possible to write your
own RPC protocol over a network link, and hide it behind a
meta-class. This has been done a couple of times, though I don't know
of anything that is publically available, IMHO.
> However, Java is better than C++ because it provides a valuable class
> library with the language which provides a host of features not
> typically included in a language. In fact, no other standard library
> for a language that I have seen includes built-in classes for all of
> networking, threading, encoding, parsing, etc. The closest to that
> level I can think of off the top of my head is OpenStep's Foundation
> Framework for Objective-C.
Yes, Java includes much stuff, and the size of this is increasing (it
seems to me) exponentially. While in quantity terms this is useful, I
rather doubt that the quality of much of this is really any good: In
their haste to get to the market, we have now seen at least 3 versions
of their idea of a GUI Toolkit: original AWT, which even compared to
the windows GUI toolkits of the day sucked hugely (can you say
switch?), then a major revision of AWT (IIRC), and now Swing on top of
that, which is the size of my whole CMU CL distribution.
It seems to me that the sole driving force behind Java's growing
library base is to occupy as much of the teritory as possible, so that
the enemy can't get it. Only after we've got all of this, will we
think about the quality, stability and usefullness of our libraries.
The same seems to apply to the core of the language itself, only in
more restrained ways (probably because of the need to provide at least
some backward compatability to older JVMs for the time being, to keep
the slogan write once, run everywhere at least somewhat believable).
Compare that to CL, which at the time also had a huge set of built-in
functionality (we've only fallen behind Jave, Perl, etc. in recent
times in quantity), but at a much higher quality. Most of the things
in CL are both proven by the test of time, and have been analysed
quite well to ensure their stability, versatility and continued
usefullness. Now you might argue that CL is this way, because it
stayed away from controversial "new" areas, like GUI toolkits, so that
this comparisson is unfair. I don't think it is unfair for two
reasons:
a) Some of the things CL tried to tackle were at least as controversial
at the time as (cross-plattform) GUI toolkits were at the time Java
started: The condition system and more so the CLOS are examples of
functionality in CL that could quite easily have been gotten
wrong. But CL didn't, and to my knowledge there exist no major
grievances with both that would need to be adressed in the current
round of standardization/reaffirmation.
b) CL never exhibited this conquer-at-all costs attitude towards
functionality. If some area was not understood well enough to be
standardized, it was rather left out of the standard, than burden
future generations with the crap of the current generation.
Note that these are generalized arguments, and I don't claim that
indeed every little feature in CL is as good as the claims above.
OTOH it should be noted that nearly all of the suggestions for changes
in the standard at the current time are for extensions to the
language into different directions, and not to fix defects in existing
constructs (with pathnames probably being one of the notable
exceptions[1]).
So while I too like to have as many functionality as possible in my
language of choice (or available too it), I also want it to be of high
quality, and highly versatile and stable. Otherwise I'd rather see it
not standardized, so that different third-party vendors can try to
come up with increasingly better ways of doing things, which a
standard would prohibit. In this way I get at least increasing
quality and choice, while sacrificing stability. With the Java way I
get neither quality nor stability.
What I would like to see is an increase in (de-facto) standardized
libraries/layers for Common Lisp, but at a decent speed that didn't
try to exchange quality for quantity.
Just my 2 cents.
Regs, Pierre.
Footnotes:
[1] It is my impression that pathnames were properly understood at
the time (see Symbolics Lisp machines), but that political pressures
to standardize too much Symbolics' stuff kept much of the needed
functionality from being brought in.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
"Pierre R. Mai" wrote:
>
> Dobes Vandermeer <·····@mindless.com> writes:
>
> > "R. Matthew Emerson" wrote:
> > >
> > > I'm sure that many people have that same impression, but I think that
> > > Lisp can win in other areas, too. I don't consider myself an AI
> > > person: I'm using Lisp for systems programming, computer graphics,
> > > number crunching, and networking.
> >
> > Personally, these are exactly the fields I avoid with LISP, mostly
> > because I haven't really been able to get my hands on good libraries
> > that fill these roles. Number crunching is about the only one that
> > seems to be in the ANSI standard, but computer graphics and networking
> > might be somewhat of a problem case. Does CLOS have any good
> > distributed objects protocols? I understand you can use CORBA, but that
> > doesn't count as a *good* protocol to me so much as one that "works",
> > because it lacks features like self-describing objects (to eliminate the
> > need for IDL) and clever namespace tactics.
>
> Nothing in the CORBA standard prohibits implementations from
> generating the IDL automatically from information already present in
> the implementation.
Neither does it recommend you do so, or provide a fundamental mechanism
for doing so. Thus, CORBA lacks the feature, even if it has the ability
to do so. For example, I could just as easily say CORBA lacked the
ability to send email; saying that I could implement an emailer using
CORBA is irrelevant to the point, which is whether the spec itself
provides that feature. CORBA doesnt appear to (provide self-describing
objects), because they have large sections of documentation dedicated to
their IDL, which woudl be completely irrelevant if they provided
self-describing semantics in the first place.
> I don't think you can get much more self-describing than this. Now I
> would have been with you if you had accused CORBA of being overly
> complex for same language/implementation solutions, which OTOH is to
> be expected of an architecture that tries to be cross-language, cross-
> platform and cross-network.
I agree on this point too, although even for inter-language applications
CORBA seems relatively over-complex. For example, interfacing between
dynamically boung message-passing languages like SmallTalk, Java, and
Objective-C should be trivial. CORBA's major weakness might be that it
favors C++, a language where dynamic binding is fairly foreign, and
self-describing objects are a sort of wild fantasy.
> I don't know what you mean by clever namespace tactics, but would be
> interested to know more. Maybe the Interface/Namespace split that ILU
> does in ISL would be interesting to you?
Some distributed systems provide a standardised namespace in which you
can dynamically lookup objects, classes, and so forth; somewhat like
Java's naming scheme, although sometimes more elegant. CORBA seems to
provide a very generic view of namespaces, rather than doing us favors
in this regard. Mind you, I havent read the entire spec or done any
serious CORBA programming, so perhaps I missed the part where I woudl be
amazed by their brilliant scheme of naming objects in an available and
useful manner.
> > However, Java is better than C++ because it provides a valuable class
> > library with the language which provides a host of features not
> > typically included in a language. In fact, no other standard library
> > for a language that I have seen includes built-in classes for all of
> > networking, threading, encoding, parsing, etc. The closest to that
> > level I can think of off the top of my head is OpenStep's Foundation
> > Framework for Objective-C.
>
> Yes, Java includes much stuff, and the size of this is increasing (it
> seems to me) exponentially.
Its a little early to criticize Java's library I think; it is growing
exponentially because it makes no pretense of being set in stone. When
they have sorted out all the issues I'm certain they will be ready to
release a sort of "final" version that provides the most powerful
feature set possible without compromising library size too much.
Java is currently just filling as many roles as possible so that it can
optimise and refine these classes an algorithms into something that
makes more sense later... I hope.
> Compare that to CL, which at the time also had a huge set of built-in
> functionality (we've only fallen behind Jave, Perl, etc. in recent
> times in quantity), but at a much higher quality.
CL is a much older language than Java, and so it faced different issues,
as you mention. You cant expect a baby like Java to be as mature as CL
is. Of course, CL in its maturity may be growing "too old", and will
probably need a new set of extensions and so forth in the next few years
to address the many issues that Java is working on-he-fly to figure
out. The LISP solutions will probably be based on the results of Java,
whether or not the same solutions are chosen.
> What I would like to see is an increase in (de-facto) standardized
> libraries/layers for Common Lisp, but at a decent speed that didn't
> try to exchange quality for quantity.
I'm working on it...
CU
Dobes
Dobes Vandermeer <·····@mindless.com> writes:
> "Pierre R. Mai" wrote:
> >
> > Nothing in the CORBA standard prohibits implementations from
> > generating the IDL automatically from information already present in
> > the implementation.
>
> Neither does it recommend you do so, or provide a fundamental mechanism
> for doing so. Thus, CORBA lacks the feature, even if it has the ability
> to do so. For example, I could just as easily say CORBA lacked the
> ability to send email; saying that I could implement an emailer using
> CORBA is irrelevant to the point, which is whether the spec itself
> provides that feature. CORBA doesnt appear to (provide self-describing
> objects), because they have large sections of documentation dedicated to
> their IDL, which woudl be completely irrelevant if they provided
> self-describing semantics in the first place.
CORBA *does* support self-describing objects, but you have to
go through an "Interface Repository". Via operations on an IR, it is
possible to get complete details on a particular IDL interface,
including application-specific data types and what operations a
particular interface offers. The LISP language binding for CORBA
mentions that the Interface Repository could/should be updated with
information from the IDL parser when an IDL interface is loaded into a
LISP system.
> I agree on this point too, although even for inter-language applications
> CORBA seems relatively over-complex. For example, interfacing between
> dynamically boung message-passing languages like SmallTalk, Java, and
> Objective-C should be trivial. CORBA's major weakness might be that it
> favors C++, a language where dynamic binding is fairly foreign, and
> self-describing objects are a sort of wild fantasy.
CORBA isn't all that complex, although some of the language
bindings are. I don't think it actually favours C++, but IDL has a
C/C++-inspired syntax. This is, IMHO, a mistake, especially since IDL
imposes stronger semantics than C/C++ does (example: the IDL "long"
integer is *exactly* 32 bits, "long long" is *exactly* 64 bits,
etc. Why not use something like Int32, Int64 etc instead? It would
have been much clearer...)
> Its a little early to criticize Java's library I think; it is growing
> exponentially because it makes no pretense of being set in stone. When
> they have sorted out all the issues I'm certain they will be ready to
> release a sort of "final" version that provides the most powerful
> feature set possible without compromising library size too much.
Given that Java's library is growing exponentially: is there
*any* reason to expect that it will ever stabilise :-?
> > Compare that to CL, which at the time also had a huge set of built-in
> > functionality (we've only fallen behind Jave, Perl, etc. in recent
> > times in quantity), but at a much higher quality.
>
> CL is a much older language than Java, and so it faced different issues,
> as you mention. You cant expect a baby like Java to be as mature as CL
> is. Of course, CL in its maturity may be growing "too old", and will
> probably need a new set of extensions and so forth in the next few years
> to address the many issues that Java is working on-he-fly to figure
> out. The LISP solutions will probably be based on the results of Java,
> whether or not the same solutions are chosen.
This process works the other way, too. For an example,
consider the "anonymous functions" in Java - without doubt inspired by
LISP, but it doesn't really fit well into the syntax/semantics of
Java.
> > What I would like to see is an increase in (de-facto) standardized
> > libraries/layers for Common Lisp, but at a decent speed that didn't
> > try to exchange quality for quantity.
Something like CPAN for LISP, perhaps?
--
Raymond Wiker, Orion Systems AS
+47 370 61150
* Raymond Wiker wrote:
> Given that Java's library is growing exponentially: is there
> *any* reason to expect that it will ever stabilise :-?
There are very strong reasons to suppose it will not stabilise. Since
Java is (among other things) an attack on Microsoft by Sun, there is
an ongoing feature arms race between the Java and Microsoft API's. If
either side lets the size of the API stabilise, the other side will
promptly catch up, so both sides must continue to enlarge their
library. At least in case of Microsoft (Sun would do this too but I'm
not sure they are large enough) they also need to continually change
the API in ways such which old versions do not support to force users
to upgrade and ensure a revenue stream.
If the Java library ever stabilises then Microsoft have won and Java
is dead -- if Sun win, then they will probably continue to change the
library because *they* now need to force users to upgrade and ensure a
revenue stream.
This is why you need independent standards bodies.
--tim
Raymond Wiker <·······@orion.no> writes:
> > > What I would like to see is an increase in (de-facto) standardized
> > > libraries/layers for Common Lisp, but at a decent speed that didn't
> > > try to exchange quality for quantity.
>
> Something like CPAN for LISP, perhaps?
Well, IMHO we need something to replace the now defunct CMU Repository,
to pull together all the good packages that are out there, but live on
individual home pages, etc.
Or at least some kind of meta-archive with links, e.g. by enlarging
the Links pages at www.alu.org...
In this way I think that we can get useful libraries into more general
usage, and work towards standardization for certain APIs with the
experience gained.
I'm rather busy at the moment, but I'll try to do something in this
direction in a couple of weeks...
Regs, Pierre.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
Dobes Vandermeer <·····@mindless.com> writes:
> I was referring to computers in general; they are (heavily) market
> driven currently, and I think that this is probably what has allowed the
> leaps and bounds in computer technology in the last while. The powerful
> appeal of fast computers has provided the computing industry with the
> funds required to rapidly advance computer technology. A small group of
> professionals could still have advanced computing, but not at nearly the
> rate; professionals by common definition work for money, so less money
> means fewer professionals.
AFAIK the increase in computing power has followed the same law since
(nearly) it's beginning, and the introducting of the home and personal
computer didn't in any way increase or decrease the rate of change,
IMHO. OTOH I can't find the figures to support this at the moment, so
I might be misremembering.
So I don't think that a _mass_ market is needed to get sustainable
growth, you just need a market that can sustain the investments
needed.
> The impression that I have is that LISP (esp. CL) is basically a
> de-facto standard for Artificial Intelligence (And Applied AI)
> prototyping, especially at eductional and research facilities. This may
> be the professional audience to which you refer.
I don't think that CL's position in the AI fields is nearly as strong
as it was in the past, with C++ and nowadays Java making increasing
inroads since the beginning of the AI winter.
OTOH it seems to me that CL's position in the non-research and non-AI
areas is increasing steadily, in all sorts of business-critical and/or
complex information systems. Fields like knowledge-based engineering
(see www.ktiworld.com with it's ICAD/KBO environments), simulation,
visualization, OODBMS, decision-support systems, planning and
scheduling systems, etc.
The producers of these systems typically have different needs and
different buying habits than the participants of what has come to be
the programmer mass market.
It is this audience (together with the relevant research and education
communities) that most Lisp vendors are increasingly trying to cater
for nowadays, I'd guess.
I think this is a sustainable strategy for the current number of
players. OTOH I could imagine other strategies working well, too,
like Kent's suggestion that serveral CL implementations should try
to leverage their connectivity prowess (especially their very well
integrated-CORBA support) better by incorporating it into their
base products, thereby positioning their products as the business
logic/connectivity language of the future.
> I can only question whether entrance into the mass market is powerful
> enough to seriously harm a strongly standardized language like LISP
> (well, ANSI CL).
>
> Do you know of similar products (i.e. programming languages) which were
> seriously harmed by entering the consumer market?
The purpose of a programming language is to cater to it's user community
and their _perceived_ needs. Especially during standardization rounds,
the user community will be well represented, either directly or through
their respective vendors. If the user community of CL starts to include
large segments of the mass market, the same forces that created the
current products of choice in this market would start to work on future
ANSI CL standards.
Since it seems that the current users of CL seem to have other
perceived needs as do members of the mass markets, it seems to me that
the outcome would be less satisfactory to the current users...
> > but we have a decrease in overall quality! 40 years ago, producing a
> > business letter had a cost relative to company expenditures in general
> > that was about half of what it is today.
>
> Are you certain? This sounds more like a hipshot than a known thing,
> considering the reason businesses turn to increases in technology is to
> reduce costs.
Studies that show either decreased productivity and/or increased costs
for simple business/administration tasks have been around for at least
10-20 years now. Of course, as with every study, it is up to you to
believe in it's validity. But if you are interested I could try to
find the references I have.
> OK. You are saying that you DO have to worry about the underlying CPU,
> because it will affect price and performance ?
Because it will affect price, performance and quality of the things
that run on top of that CPU. It is a well known fact that writing
optimizing compilers for iA32 CPUs is quite a bit more work than
coming up with something good for more sane architectures. The time
spend on this will either affect other areas of the product and/or
increase it's price or it's quality.
Regs, Pierre.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
* Pierre R Mai wrote:
> Studies that show either decreased productivity and/or increased costs
> for simple business/administration tasks have been around for at least
> 10-20 years now. Of course, as with every study, it is up to you to
> believe in it's validity. But if you are interested I could try to
> find the references I have.
There was an interesting article in The Economist a few weeks ago --
which may be available from their web site -- on productivity and
computing. My take on it is this (they didn't quite seem to say this
in so many words):
The standard story is that computerisation has had negligible effects
on productivity, and may in fact have decreased it. The reasons for
this are (they claim) mysterious and (I claim) very obvious.
However, over the last short period (perhaps 2 years) there have been
really noticeable improvements in productivity in the US economy.
The internet/e-commerce people are jumping up and down waving their
hands claiming that the revolution is finally here because it wasn't
computers it was web-browsers that increase productivity (or something
equally incoherent).
But if you look closely at *where* the productivity gains are
happening you find something interesting: most people are seeing only
small-to-no increases in productivity, but *computer manufacturers*
are seeing *very large* increases, and have also become a significant
part of the economy.
So really what is happening is that computerisation is still not
helping, *but* `lock-in' is happening, so that a company *has* to
computerise or lose, even though it doesn't save money by doing so
(my guess is that this is doe to proprietary-format contagion over
the net, and also because large companies are refusing to deal with
people non-electronically). So huge numbers of computers are being
sold, and the computer makers are realising really significant
productivity gains at the same time.
--tim
Tim Bradshaw <···@tfeb.org> writes:
> So really what is happening is that computerisation is still not
> helping, *but* `lock-in' is happening, so that a company *has* to
> computerise or lose, even though it doesn't save money by doing so
> (my guess is that this is doe to proprietary-format contagion over
> the net, and also because large companies are refusing to deal with
> people non-electronically). So huge numbers of computers are being
> sold, and the computer makers are realising really significant
> productivity gains at the same time.
This smacks of "popularity" to me, so, relatively speaking, perhaps we
are only just now on the brink of seeing the age of the poor-quality
computer system...
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
From: Lars Bj�nnes
Subject: Re: The value (?) of popularity
Date:
Message-ID: <m3r9jfgz6n.fsf@gdpm.no>
Duane Rettig <·····@franz.com> writes:
> This smacks of "popularity" to me, so, relatively speaking, perhaps we
> are only just now on the brink of seeing the age of the poor-quality
> computer system...
A quoute from Dilbert:
Salesman: "This communication device conforms to all international standards"
Dilbert: "In other words, it doesn't do anything useful?"
:-)
--
Lars
No more policy statements, no more consultative documents, no more
morale-boosting messages to all staff. This was Hell, but you had to
draw the line somewhere. ("Eric", T. Pratchett)
Tim Bradshaw wrote:
> The standard story is that computerisation has had negligible effects on
> productivity, and may in fact have decreased it.
I find this interesting: What do you mean by computerisation? and how are
you measuring productivity?
For example: when my father was of age to enter the job market, the majority
of accounting and stock control functions in businesses and local
authorities were carried out by large teams of people adding up numbers by
hand (either using mechanical adding machines or ledgers and a pen). This
doesn't happen any more. The payroll and holiday calculations for the large
(~500 person) group of companies I work for, is carried out by one and a
half people. This is possible using stuff like SAGE. In the past took a team
of 20 to do.
More recently (the last 10 years or so), the production of Yellow Pages in
this country was an almost completely manual process. Two sites in this
country employing in excess of 800 people to rearrange film advert and text
items. An experienced person could expect to produce in the order of 23
laid-out pages in a week. The average book took 6 weeks to produce, even
working shifts and weekends. Including amendments, this process now takes
under 4 days and about 10 people.
I have probably missed the point (again) and you were talking about some
other form of computerisation. But I think that standard story is wrong,
that computerisation *has* had an impact on productivity. You can save money
in a lot of processes through the careful use of computerisation.
Best Regards,
:) will
Tom Ivar Helbekkmo wrote:
> William Deakin <·····@pindar.com> writes:
>
> > I find this interesting: What do you mean by computerisation? and
> > how are you measuring productivity?
>
> His papers and articles on the subject are at
> <http://ccs.mit.edu/erik/ITandBusinessvalue.htm>.
Thanks for the reference.
> An oft-quoted explanation is that the productivity gains are lost
> through the non-productive use of the computers: for instance, when
> journalists are given access to large stores of reference material
> on-line, they will spend at least as much time digging through this as
> they would have spent with traditional refernce material, and their
> actual production thus won't increase.
But might they not search through more text and do more research?
This *may* result in a more thought out piece of work. For example: When I
had to write a thesis on Non-Linear Optical research I had access to a
citations database that had access to pretty well all papers after about
1978. Any other references I had would be based on references I found
within these papers. This was patchy at best. I missed some stuff from
after 1965-9 (when the field kicked off which is always referenced at the
start of papers) and 1978. And got a good drubbing in my thesis.
However, when I had straightforward access to the citations index I was
able (with a month of work and access to a large library) to say that I
had looked at, if not read in detail, at least 90% of the papers in this
area after 1978. Covering all the important developments. To do this by
hand would have taken many many months of work.
I would say that this was a major improvement productivity. However, if
all you measured were the number of words I put in my thesis. Or to get
back to the point, the number of words the journalist has printed in the
paper each week. Yes, they may not have more words printed. But to say
that this is not a productivity gain is just plain daft.
> It has been shown that investments in technology often do not by
> themselves pay off, whereas investments in skills and knowledge do.
That is so true.
> Another result of investigations is that in many businesses, there is no
> real productivity gain from the use of IT, but there is a new level of
> responsiveness and adaptability to customer needs, such that it becomes
> impossible for companies not using IT to compete.
OK. But to me this seems like the definition of 'productivity' is pretty
strange. The ability to respond and adapt seems to me a big improvement in
productivity.
Anyway, this is entering the realms of Economics (or Astrology as I heard
JKGalbraith once describe it). At which point these statements are bounded
on as much fact as is usual in comprable field. Such as writing Science
Fiction ;)
I was going to tell you about how technology helped my mum more
effectively run a small Sub-PostOffice in Mid-Wales. But I will save that
for later :)
Best Regards,
:) will
William Deakin <·····@pindar.com> writes:
> Tim Bradshaw wrote:
>
> > The standard story is that computerisation has had negligible effects on
> > productivity, and may in fact have decreased it.
>
> I find this interesting: What do you mean by computerisation? and how are
> you measuring productivity?
What is generally measured is the _overall_ productivity. The
examples you introduced below are areas where computerisation
increased the _specific_ productivity in that area (probably).
OTOH someone has to produce and maintain the programs and computers in
question, and to deal with the problems that computerisation
introduce. No firm had Y2K emergency staff, computer security
experts, a large set of programmers and procurement staff, help-desks,
sysadmins, etc. in the past. Since they all don't contribute directly
to the output of the business in question, they are esentially
overhead, and thereby decrease productivity again.
And then there is the problem of office productivity, where companies
tried to save on the cost of expert sys-admins, by going the windows
way, in the hope that those computers would take care of themselves.
What really happens is that now the office workers (which aren't
trained to do it) have to do their own system administration and
trouble shooting, which can take up a non negligible amount of office
hours. Not to mention the many nice distractions that computer
systems offer, like all the settings to fiddle with, screensavers and
the internet, etc.
Now you may argue that every technology that increases productivity on
the one hand will have some amount of productivity decrease that goes
hand in hand with it, and you would be right. The interesting
question is whether in the large picture this adds up to an increase
or a decrease in overall productivity. And it seems as if computers
haven't _on the whole_ increased productivity.
Another question is of course whether this non-increase in
productivity is due to computers, or due to other circumstances, like
increased bureaucracy, legislative pressures, lacking work-force
motivation, etc.
So how to judge the study results is a difficult call. On the whole
my opinion is that computers can increase productivity, but only if
they are used judiciously in the right environments and for the right
jobs. And we need much higher quality software to do it. What I
think has mostly failed is the idea of a Windows box on every desktop.
This only distributed the work-load of the secretaries onto the office
work-force at large, and led to the increase in company memos and
e-mails that swamp todays office workers, and the many hours spend in
Powerpoint on tinkering on hugely overblown presentations for stupid
ideas... ;)
> I have probably missed the point (again) and you were talking about some
> other form of computerisation. But I think that standard story is wrong,
> that computerisation *has* had an impact on productivity. You can save money
> in a lot of processes through the careful use of computerisation.
Exactly, though it seems we use the wrong computers/software for the
wrong processes, thereby losing most of the productivity gains
again...
Regs, Pierre.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
"Pierre R. Mai" wrote:
> William Deakin <·····@pindar.com> writes:
> What is generally measured is the _overall_ productivity. The examples you
> introduced below are areas where computerisation increased the _specific_
> productivity in that area (probably).
OK. But I would still say the 20 people, including all development staff and
managers, is still much more productive in terms the number of pages produced per
person. It is also vastly cheaper.
Also, in the last 10 years there has been a 8% year-on-year growth in the number
of pages produced. So that potentially, for the manual process to have coped with
this there would have to have (a concervative) 2.5 times increase in the number of
people doing the job.
I should also state (since I have been asked) that Lisp is a key part of this.
[..elided an excellent description of productivity issues..]
> And it seems as if computers haven't _on the whole_ increased productivity.
This may be true. But it has had a large impact, increasing productivity, in
certain industries such as the bulk printing of text or images.
> > I have probably missed the point (again) ...
>
> Exactly,
Thanks ;)
> though it seems we use the wrong computers/software for the wrong processes,
> thereby losing most of the productivity gains again...
This is so true.
I would look at it a bit like this: If you take an axe away from a lumberjack and
give him a chain-saw but without any fuel, I think you would also see a down turn
in his productivity.
Best Regards,
:) will
William Deakin <·····@pindar.com> writes:
> > And it seems as if computers haven't _on the whole_ increased productivity.
>
> This may be true. But it has had a large impact, increasing productivity, in
> certain industries such as the bulk printing of text or images.
I totally agree with all of your points, actually. It's just that it
seems to me the mainstream office/business market is not one were we
currently use computers wisely...
> > > I have probably missed the point (again) ...
> >
> > Exactly,
>
> Thanks ;)
Ooops, I didn't mean it this way, i.e. I was referring to your caveat
on using computers wisely, and was agreeing with that, not with your
assertion that you probably missed the point (again)... Funny how
these misunderstandings can creep in... Thanks for not bashing me over
the head on this one ;)
> > though it seems we use the wrong computers/software for the wrong
> > processes, thereby losing most of the productivity gains again...
>
> This is so true.
>
> I would look at it a bit like this: If you take an axe away from a
> lumberjack and give him a chain-saw but without any fuel, I think
> you would also see a down turn in his productivity.
Or to put it another way: Imagine[1] taking away the axe, and giving
him a modern multi-media personal tree-management device, complete
with mouse, sound system and Internet access. See if this gives him
any more productivity, especially if said device has the additional
tendency of crashing often, going down (or worse spinning-up) on
E-Mail macro viruses, server or network problems, device or hardware
conflicts, and the constant need to upgrade and relearn (Imagine
placing important controls on a chain-saw at different places in
every version, with upgrades every 1-1.5 years).
It seems to me that our current obsessions with the flashy
versatility of the PC is blinding us to the obvious: It is the rare
process that is aided by integrating unrelated and unnecessary
functionality into one device. Most of the time, we need few
(even single) functionality, but that should be streamlined, robust
and reliable.
This is observed in most other fields of tool-making: When have you
last seen a professional using one of the "all-in-one-wonder-tools"
that are punted to consumers? You don't, and there are reasons for
this. Yet in the PC area, we buy multi-media PCs for everything,
running huge kitchen-sinks of OS/Office-Suite amalgams on it. Why?
For years it has been argued that the wave of the future lies not in
the all-integrated multi-media PC/software suite that Intel/Microsoft
are trying to sell us, but rather in highly modular (=> see the
dynamic thread) slimmed down systems providing fewer (but changeable)
funtions, and improved data-sharing via open protocols.
But of course this runs counter to all the current major players hopes
of bringing whole market segments under their control (=> with open
standards and component based software, Microsoft would be dead, and
Intel would be left struggling). A market like this would also favor
smaller players, which currently can only "hope" to be bought by
Microsoft or Sun, and have their software integrated into their
software suites...
Regs, Pierre.
Footnotes:
[1] Any similarities with living or crashing operating systems or
word-processing software are purely accidental, and should in no way
be construed to constitute a value judgement by the author or any of
his affiliates, officers or representatives. The right of the author
to deny and renounce any and all of the above in exchange for a large
sum of money is expressly reserved...
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
I can think of nothing other to say, but than that I completely agree with
you tree-felling analysis.
Best Regards,
:) will
ps:
>Footnotes:
>[1] ... The right of the author
>to deny and renounce any and all of the above in exchange for a large
>sum of money is expressly reserved...
If you do get some money please let me know. I am also happy to publically
renounce all critisisms of certain operating systems in exchange for an
inordaniately large sum of money :)
Also, the career as 'successful buglar' isn't going too well. If you have
any further questions about this, please refer them to my Community Service
area coordinator ;)
* William Deakin wrote:
> I would look at it a bit like this: If you take an axe away from a
> lumberjack and give him a chain-saw but without any fuel, I think
> you would also see a down turn in his productivity.
More to the point, if you give him a very hi-tech chainsaw that breaks
down every two hours and needs about 1 day in 5 spent on maintenance
be a skilled and highly-paid engineer, even when it is *not* breaking
down, it might turn out that the axe was a more productive tool.
--tim
Tim Bradshaw wrote:
>
> * William Deakin wrote:
> > I would look at it a bit like this: If you take an axe away from a
> > lumberjack and give him a chain-saw but without any fuel, I think
> > you would also see a down turn in his productivity.
>
> More to the point, if you give him a very hi-tech chainsaw that breaks
> down every two hours and needs about 1 day in 5 spent on maintenance
> be a skilled and highly-paid engineer, even when it is *not* breaking
> down, it might turn out that the axe was a more productive tool.
Actually, with a chainsaw you can cut down about 20-30 trees per day or
more, but without one you could maybe do 3 or 4 before running out of
time or becoming exhausted. This means that even with only one day in
five beign effective, you will still outperform the axe, esp. if you are
cutting large timber.
CU
Dobes
Dobes Vandermeer wrote:
> Tim Bradshaw wrote:
> >
> > * William Deakin wrote:
> > > I would look at it a bit like this: If you take an axe away from a
> > > lumberjack and give him a chain-saw but without any fuel, I think
> > > you would also see a down turn in his productivity.
> >
> > More to the point, if you give him a very hi-tech chainsaw that breaks
> > down every two hours and needs about 1 day in 5 spent on maintenance
> > be a skilled and highly-paid engineer, even when it is *not* breaking
> > down, it might turn out that the axe was a more productive tool.
>
> Actually, with a chainsaw you can cut down about 20-30 trees per day or
> more,
OK. But I think you have missed the point.
> but without one you could maybe do 3 or 4 before running out of time or
> becoming exhausted.
Is this from personal experience?
> This means that even with only one day in five beign effective, you will
> still outperform the axe, esp. if you are cutting large timber.
Having done a little log-chopping and having lived in an area in which the
major industry was tree felling (albeit "small" timber) I think this is not
as you descibe.
You also need a lot of kit to stop you from chopping your hand and legs off.
A chain-saw requires far more maintenance than an axe. You need to call on
the expertise of a chainsaw maintenance man, and require constant deliveries
from across the world of fuel, oil and spare parts from the chain saw
factory. This all requires some time and effort which hasn't been factored
into your calculations.
As a basic survival tool I would prefer an axe and a file ;)
Best Regards,
:) will
In article <··············@athene.i.eunet.no>,
Tom Ivar Helbekkmo <······@Norway.EU.net> writes:
> ...
> An oft-quoted explanation is that the productivity gains are lost
> through the non-productive use of the computers: for instance, when
> journalists are given access to large stores of reference material
> on-line, they will spend at least as much time digging through this as
> they would have spent with traditional refernce material, and their
> actual production thus won't increase.
imo this is a lousy example: what actually happens in this case is that
the increase in productivity (in this case more thorough research) isn't
measurable in the financial return. there still is a productivity increase
> ...
--
Hartmann Schaffer
It is better to fill your days with life than your life with days
Hartmann Schaffer <··@inferno.nirvananet> wrote in message
····························@tor-nn1.netcom.ca...
> In article <··············@athene.i.eunet.no>,
> Tom Ivar Helbekkmo <······@Norway.EU.net> writes:
> > ...
> > An oft-quoted explanation is that the productivity gains are lost
> > through the non-productive use of the computers: for instance, when
> > journalists are given access to large stores of reference material
> > on-line, they will spend at least as much time digging through this as
> > they would have spent with traditional refernce material, and their
> > actual production thus won't increase.
>
> imo this is a lousy example: what actually happens in this case is that
> the increase in productivity (in this case more thorough research) isn't
> measurable in the financial return. there still is a productivity
increase
Whose to say what the financial return of better-researched articles might
be? Perhaps it will spark ideas or guide thought more productively by the
reader. A poorer article might generate fewer and worse sparks. So that's
a global economic productivity increase for this (somewhat strange) example.
Improved customer service also has clear financial implications. Solving
customer problems may not directly increase the supplier's productivity, but
it sure increases the customer's productivity. So again, global economic
productivity goes up.
Computers also make possible other clear productivity wins for knowledge
workers, like cell phones.
Finally, in manufacturing and accounting, it is indisputable that computers
have revolutionized all processes, with huge sweeping gigantic increases in
productivity across the board.
Productivity, as someone pointed out, is tricky to measure. I think what is
more interesting is that computers have helped generate enormous wealth
which would not otherwise exist. And I'm not just talking about the
magnates of Silicon Valley, Bill Gates, and so on, but increased material
standard of living for the average Joe in industrialized nations.
-- Harley
Harley Davis <·············@nospam.museprime.com> wrote in message
···················@newsreader.alink.net...
> Finally, in manufacturing and accounting, it is indisputable that
computers
> have revolutionized all processes, with huge sweeping gigantic increases
in
> productivity across the board.
Actually I meant the finance industry rather than accounting, although
certainly computers have revolutionized accounting as well.
-- Harley
* Hartmann Schaffer wrote:
> imo this is a lousy example: what actually happens in this case is that
> the increase in productivity (in this case more thorough research) isn't
> measurable in the financial return. there still is a productivity increase
But economics measures financial return (or something that can be
summarised by it), so anything that does not result in a financial
return is defined as not increasing productivity.
Note that this is a significant thing to measure -- if company A makes
more financial return on investment than company B, then (if they are
competing) company A will probably kill company B.
--tim
In article <···············@lostwithiel.tfeb.org>,
Tim Bradshaw <···@tfeb.org> writes:
> * Hartmann Schaffer wrote:
>
>> imo this is a lousy example: what actually happens in this case is that
>> the increase in productivity (in this case more thorough research) isn't
>> measurable in the financial return. there still is a productivity increase
>
> But economics measures financial return (or something that can be
> summarised by it), so anything that does not result in a financial
> return is defined as not increasing productivity.
improved technology lets you either do the same job faster or a better
job in the same time (or some combination: somewhat better in not quite
as fast a time period). imo, either is a productivity improvement,
using the relation of effort input to the outcome. the lack of
financial remuneration for an improved job could be an indication od a
serious flaw in the measurement methodology
> Note that this is a significant thing to measure -- if company A makes
> more financial return on investment than company B, then (if they are
> competing) company A will probably kill company B.
sometimes. franz and a few others survive even in a ms world
--
Hartmann Schaffer
It is better to fill your days with life than your life with days
In article <·······················@tor-nn1.netcom.ca>,
··@inferno.nirvananet (Hartmann Schaffer) writes:
> ...
> improved technology lets you either do the same job faster or a better
> job in the same time (or some combination: somewhat better in not quite
> as fast a time period). imo, either is a productivity improvement,
> using the relation of effort input to the outcome. the lack of
> financial remuneration for an improved job could be an indication od a
> serious flaw in the measurement methodology
maybe i should rephrase it: the increased productivity could well be
wasted.
> ...
--
Hartmann Schaffer
It is better to fill your days with life than your life with days
* Hartmann Schaffer wrote:
> improved technology lets you either do the same job faster or a better
> job in the same time (or some combination: somewhat better in not quite
> as fast a time period). imo, either is a productivity improvement,
> using the relation of effort input to the outcome.
Yes of course it is, and *each of those things makes you more money*.
> the lack of financial remuneration for an improved job could be an
> indication od a serious flaw in the measurement methodology
If you don't get paid more for it then, in strictly economic terms
(rather than terms of something like quality or elegance, orq beauty,
which are *clearly* important issues but outside the realm of
economics), it's not an `improved job'.
>> Note that this is a significant thing to measure -- if company A makes
>> more financial return on investment than company B, then (if they are
>> competing) company A will probably kill company B.
> sometimes. franz and a few others survive even in a ms world
Sorry for my imprecision, I should have added `if they are competing,
and in the absence of a monopoly'. In the case of, say, Franz and MS,
they are not competing, and there probably is a monopoly.
--tim
In article <···············@lostwithiel.tfeb.org>,
Tim Bradshaw <···@tfeb.org> wrote:
>* Hartmann Schaffer wrote:
>
>> improved technology lets you either do the same job faster or a better
>> job in the same time (or some combination: somewhat better in not quite
>> as fast a time period). imo, either is a productivity improvement,
>> using the relation of effort input to the outcome.
>
>Yes of course it is, and *each of those things makes you more money*.
>
Well, that depends. It may be that the quality level necessary to
stay in the market has risen. A few years ago, people made and
sold gigabyte external disk drives. I can't find them any more
at the usual places; instead, I find multi-gig drives for the same
price.
It would seem really odd to me not to consider this an improvement
in productivity: for, say, $300, I can get additional gigabytes.
On the other hand, it isn't making the disk drive companies any more
money, since they're selling it for the same price.
What has happened is that all the disk drive manufacturers are
producing vastly improved drives, so if somebody tried selling
a 1997 design nowadays, they'd be completely unsuccessful.
>> the lack of financial remuneration for an improved job could be an
>> indication od a serious flaw in the measurement methodology
>
>If you don't get paid more for it then, in strictly economic terms
>(rather than terms of something like quality or elegance, orq beauty,
>which are *clearly* important issues but outside the realm of
>economics), it's not an `improved job'.
>
OK, so measure the difference between a 1 gig drive a few years ago and
a 4 gig drive now. They cost the same, and probably gave about the same
profit to the makers. It's not a matter of elegance or beauty (which
are measurable in dollars, just like anything else). You could call
it a matter of quality, I suppose, but you could also call it a matter
of quantity. (If I had a need for 3 gigs of space, I'd spend a whole
lot less money nowadays.)
One thing I tend to see happening is that people are doing things with
computers that they could not do without. Some of this is clearly
non-productive, but not all. I worked with the Ramsey County Welfare
Department, and saw that the financial workers had much greater case
loads than they could have without computers (the difference in
case workers was greater than the cost of the DP department). I saw
a computer system, maintained by one full-time programmer, replace
dozens of workers in the County Attorney's office. What I don't know
is how this would show up in a crude economic analysis. When the
workload goes up, the employee count doesn't need to. There's no
profit to measure here, because this is a government. How would
this show up?
--
David H. Thornley | If you want my opinion, ask.
·····@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
* David Thornley wrote:
> It would seem really odd to me not to consider this an improvement
> in productivity: for, say, $300, I can get additional gigabytes.
> On the other hand, it isn't making the disk drive companies any more
> money, since they're selling it for the same price.
It's an improvement in productivity if it earns *you* more money. In
this specific case, my guess is that the vast majority of these larger
disks are eaten by larger software and bloated data formats which are
offering just negligible productivity increases.
Very similar arguments go for, say, machine performance. I can get a
(I don't know what the current fast machines run at) 500MHz machine
now for the cost of a 250MHz machine a year ago, but I need that extra
performance to run software which has halved in performance over the
same period, or to compile C++ code, where compile times measured in
cycles are doubling every year.
Of course, some people see real gains -- for instance I can compile my
lisp programs now in almost no time at all, while it used to take just
hours and hours to compile stuff.
--tim
From: Christopher R. Barry
Subject: Re: The value (?) of popularity
Date:
Message-ID: <87yadoq14h.fsf@2xtreme.net>
Dobes Vandermeer <·····@mindless.com> writes:
> > new chip could cost a lot less and run a lot faster, and we have it:
> > Digital Equipment Corporation (rest the blessed soul) produced the first
> > processor to break the 100MHz barrier, and it's still amazingly fast.
>
> 100 or 1000 MHz barrier? I didn't know there was a barrier at 100MHz
> anymore :)
Um, maybe Erik was refering to a time about a decade ago when there
was a 100MHz barrier and the DEC Alpha 20064 broke it....
Christopher
From: Gareth McCaughan
Subject: Re: The value (?) of popularity
Date:
Message-ID: <864sgc0zql.fsf@g.local>
Dobes Vandermeer wrote:
> C is also an ANSI
> standard, and it is a language I continue to enjoy programming in; I
> would gladly choose C over LISP where operations involving table
> scanning or string and buffer manipulation were involved, if only
> because of the compressed syntax (and possibly increased performance).
Curious. I like C for some purposes too, but one area where
I repeatedly find myself cursing the language is string processing.
Compare
(concatenate 'string foo bar)
with
{ size_t l1 = strlen(foo);
size_t l2 = strlen(bar)+1;
char * s = xmalloc(l1+l2);
memcpy(s,foo,l1);
memcpy(s,bar,l2);
...
}
for instance. Of course, it's easy to write a C function that
concatenates strings like this. But then what if you want to
concatenate three strings? You can't just say
result = concat(concat(foo),concat(bar,baz))
because that leaks memory (the result of the lexically last
|concat| there). It's niggling things like this (most of which,
in the end, come down to the absence of GC) that make string
manipulation in C really unpleasant. I'll admit that it's
fast, though; but not fast enough to make up for the slowdown
you incur when *writing* the code.
Common Lisp's string handling is certainly verbose, but it's
less verbose than doing the same thing in C.
--
Gareth McCaughan ················@pobox.com
sig under construction
Gareth McCaughan wrote:
>
> Dobes Vandermeer wrote:
>
> > C is also an ANSI
> > standard, and it is a language I continue to enjoy programming in; I
> > would gladly choose C over LISP where operations involving table
> > scanning or string and buffer manipulation were involved, if only
> > because of the compressed syntax (and possibly increased performance).
>
> Curious. I like C for some purposes too, but one area where
> I repeatedly find myself cursing the language is string processing.
> Compare
>
> (concatenate 'string foo bar)
>
> with
>
> { size_t l1 = strlen(foo);
> size_t l2 = strlen(bar)+1;
> char * s = xmalloc(l1+l2);
> memcpy(s,foo,l1);
> memcpy(s,bar,l2);
> ...
> }
>
I think that languages are generally USED differently. For example, in
C allocating memory is fairly expensive, and makes your life difficult
for memory management. Thus:
(concatenate 'string foo bar)
Is not a C-style construct.
When I am talking about string processing, I mean performing several
operations and producing a single string result; the style of lisp woulf
typically produce several intermediate strings in a process like this,
which is less efficient. I also need to be able to extract specific
types of values at arbitrary points in the string. To get an integer
out of a long string like "Here is your number: 5, happy?" is more
difficult in LISP than in C.
With buffer processing, it is often necessary to extract binary types
out of a byte stream of some kind, like for example if you are
communicating via TCP or storing data in a compact form on disk. To be
honest, I dont even know how to encode and decode lisp types into a
binary form, even less extract binary types that may have been written
by other languages...
Try and implement this in LISP:
int i, x=0;
char buf[200] = "xyz,abc,2.3=12";
float foundfloats[20];
for(i=0; i++; i<sizeof(buf))
{
if(buf[i] == 0)
break;
if(buf[i] == ',')
buf[i] = '\n';
if(buf[i] == '.')
{
int j;
for(j=i; j>0; j++)
{
if(buf[j] == 0)
{
foundfloats[x++] = (float) strtod(&(buf[j+1]));
break;
}
}
}
}
Although if this were a real program it woudl need explanatory comments,
its clear that you can easily scan and modify string in-place quite
easily. I suspect an equivalent LISP inplementation would have a number
of #\Newline and #\Comma entries that would make me feel very
unfortable. Not only that, but the (aref buf i) syntax is much more
difficult to type than buf[i], because it has an extra 6 characters, and
all of "aref" goes on the same hand...
</rant>
Dobes
From: Christopher R. Barry
Subject: Re: The value (?) of popularity
Date:
Message-ID: <87zoy3o9tb.fsf@2xtreme.net>
Dobes Vandermeer <·····@mindless.com> writes:
> Try and implement this in LISP:
Why don't implement this is C?
> int i, x=0;
> char buf[200] = "xyz,abc,2.3=12";
> float foundfloats[20];
>
> for(i=0; i++; i<sizeof(buf))
^^^^^^^^^^^^^^
This is a useless statement.
> {
> if(buf[i] == 0)
> break;
> if(buf[i] == ',')
> buf[i] = '\n';
> if(buf[i] == '.')
> {
> int j;
> for(j=i; j>0; j++)
> {
> if(buf[j] == 0)
> {
> foundfloats[x++] = (float) strtod(&(buf[j+1]));
^^^^^^^^^^^
strtod takes 2 arguments.
> break;
> }
> }
> }
> }
Christopher
From: Gareth McCaughan
Subject: Re: The value (?) of popularity
Date:
Message-ID: <86670qzid9.fsf@g.local>
Christopher R. Barry wrote:
[Dobes Vandermeer wrote:]
>> for(i=0; i++; i<sizeof(buf))
> ^^^^^^^^^^^^^^
> This is a useless statement.
Why?
He's |break|ing when he hits a null character, so there's
no problem with running off the end of the string. Obviously
|sizeof(buf)| is constant and doesn't involve computation
every time around the loop, so that's not a problem. I'm
at a loss to see what you object to about it.
(There are plenty of things about Dobes's code that look
wrong to me, but this isn't one of them.)
--
Gareth McCaughan ················@pobox.com
sig under construction
From: Christopher R. Barry
Subject: Re: The value (?) of popularity
Date:
Message-ID: <87ln9m19z6.fsf@2xtreme.net>
Gareth McCaughan <················@pobox.com> writes:
> Christopher R. Barry wrote:
>
> [Dobes Vandermeer wrote:]
> >> for(i=0; i++; i<sizeof(buf))
> > ^^^^^^^^^^^^^^
> > This is a useless statement.
>
> Why?
>
> He's |break|ing when he hits a null character, so there's
> no problem with running off the end of the string. Obviously
> |sizeof(buf)| is constant and doesn't involve computation
> every time around the loop, so that's not a problem. I'm
> at a loss to see what you object to about it.
Firstly, the body of the statement
for(i=0; i++; i<sizeof(buf)) {
...
}
Would never be evaluated, since in the test "i" is incremented _after_
evaluation so "i" will thus evaluate to 0 (FALSE) at the beginning of
the very first iteration.
Secondly, the "i<sizeof(buf)" statement will evaluate to 0 if it is
false or non-0 if it is true. The statement is side-effect free. The
value returned, whether 0 or not, is not used. How is this statement
not useless?
Now I haven't programmed C since 1998, so I could be stupidly
overlooking something. But as far as I can see, what you have said is
wrong. The statement is in fact useless.
To most effectively counter my claim, you could produce a program that
behaves differently when
for (... ; ... ; i<sizeof(buf)) { ... }
is replaced with
for (... ; ... ; /* i<sizeof(buf) */) { ... }
Unless it is possible to crash a program by applying the sizeof
operator to some object, I don't think there is a way to do this.
Christopher
From: Gareth McCaughan
Subject: Re: The value (?) of popularity
Date:
Message-ID: <86ogegrsin.fsf@g.local>
Christopher R. Barry wrote:
[apropose of Dobes's curiously broken C]
> Firstly, the body of the statement
>
> for(i=0; i++; i<sizeof(buf)) {
> ...
> }
>
> Would never be evaluated, since in the test "i" is incremented _after_
> evaluation so "i" will thus evaluate to 0 (FALSE) at the beginning of
> the very first iteration.
oops! I hadn't noticed he had the increment and the test
the wrong way around. It never *occurred* to me that someone
advocating C as a great language for string processing would
make that kind of error. Strange things the mind can do...
> Secondly, the "i<sizeof(buf)" statement will evaluate to 0 if it is
> false or non-0 if it is true. The statement is side-effect free. The
> value returned, whether 0 or not, is not used. How is this statement
> not useless?
As I say, I hadn't noticed the loop was the wrong way around. You're
absolutely right.
--
Gareth McCaughan ················@pobox.com
sig under construction
From: Christopher R. Barry
Subject: Re: The value (?) of popularity
Date:
Message-ID: <87wvt3zv7p.fsf@2xtreme.net>
Gareth McCaughan <················@pobox.com> writes:
> It never *occurred* to me that someone advocating C as a great
> language for string processing would make that kind of error.
It's amazing how many bugs and problems Dobes managed to include in
his "code this in LISP" challenge. How red-faced he must be.... (He
has yet to reply to any of these critiques of his code.)
Christopher
From: Gareth McCaughan
Subject: Re: The value (?) of popularity
Date:
Message-ID: <86d7uusuox.fsf@g.local>
Christopher R. Barry wrote:
> It's amazing how many bugs and problems Dobes managed to include in
> his "code this in LISP" challenge. How red-faced he must be.... (He
> has yet to reply to any of these critiques of his code.)
Well, C is a much easier language to make mistakes in than Lisp
(though I too am amazed at the number of them in this particular
case). I would be more interested to know whether Dobes agrees
with my contention that my Lisp code is (1) not significantly
longer than his C code, (2) much more robust, (3) easier to
understand and (4) more useful; and whether, if he does, he
is considering changing his opinion that C is a much better
language for string processing than Lisp. Probably not; in
which case, it might be interesting to have another example
of a string processing task for which C is good and Lisp is
bad.
--
Gareth McCaughan ················@pobox.com
sig under construction
Gareth McCaughan wrote:
>
> Christopher R. Barry wrote:
>
> > It's amazing how many bugs and problems Dobes managed to include in
> > his "code this in LISP" challenge. How red-faced he must be.... (He
> > has yet to reply to any of these critiques of his code.)
>
> Well, C is a much easier language to make mistakes in than Lisp
> (though I too am amazed at the number of them in this particular
> case). I would be more interested to know whether Dobes agrees
> with my contention that my Lisp code is (1) not significantly
> longer than his C code, (2) much more robust, (3) easier to
> understand and (4) more useful; and whether, if he does, he
> is considering changing his opinion that C is a much better
> language for string processing than Lisp. Probably not; in
> which case, it might be interesting to have another example
> of a string processing task for which C is good and Lisp is
> bad.
Well I hardly stand a chance of disagreeing now...
I suppose it just requires more knowledge about the (loop )
sublanguage...
And obviously I had many typos; I was working fast and not really paying
close attention... I assumed that the intent would be enough, and syntax
was unimportant.. apparently this list is read by syntax-parsers as well
as human beings :->
CU
Dobes
From: Gareth McCaughan
Subject: Re: The value (?) of popularity
Date:
Message-ID: <86btacm55p.fsf@g.local>
Dobes Vandermeer wrote:
> I suppose it just requires more knowledge about the (loop )
> sublanguage...
Actually, I think that's the least important point. (Although
I do think LOOP is great.) It wouldn't be too painful to rewrite
the LOOP form in my code with DO or with an old-style LOOP
(i.e., just meaning "repeat for ever"). I think the important
points that make string processing in Lisp better than you
think are (1) sequence functions like POSITION and NSUBSTITUTE
and (2) the ubiquity of :START and :END keyword arguments.
> And obviously I had many typos; I was working fast and not really paying
> close attention... I assumed that the intent would be enough, and syntax
> was unimportant.. apparently this list is read by syntax-parsers as well
> as human beings :->
Unfortunately, C (at least the sort of C you posted) is hard
to understand without parsing it. That's the price you pay for
making low character count a major design feature of the
language.
--
Gareth McCaughan ················@pobox.com
sig under construction
Gareth McCaughan <················@pobox.com> writes:
> Unfortunately, C (at least the sort of C you posted) is hard
> to understand without parsing it. That's the price you pay for
> making low character count a major design feature of the
> language.
ironically, my lisp programs are generally shorter in total characters
than my equivalent C code. if you count lines, then lisp is a lot
shorter. immagine if the C operations were as long-winded as lisp's.
you'd never finish typing...
--
J o h a n K u l l s t a m
[········@ne.mediaone.net]
Don't Fear the Penguin!
* Gareth McCaughan wrote:
> Christopher R. Barry wrote:
> [Dobes Vandermeer wrote:]
>>> for(i=0; i++; i<sizeof(buf))
>> ^^^^^^^^^^^^^^
>> This is a useless statement.
> Why?
He has the two second clauses in the for loop the wrong way around --
he means for(i = 0; i < sizeof(buf); i++) ...
Saying `this is a useless statement' is a pretty misleading way of
pointing that obvious error out. The followup was even more
misleading, I hope not deliberately.
--tim
From: Gareth McCaughan
Subject: Re: The value (?) of popularity
Date:
Message-ID: <86905mzihp.fsf@g.local>
Dobes Vandermeer wrote:
> I think that languages are generally USED differently. For example, in
> C allocating memory is fairly expensive, and makes your life difficult
> for memory management.
Allocating memory in C needn't be any more expensive than
allocating memory in any other language. You can do a lot
of it on the stack, and a good |malloc| implementation can
make allocation rather cheap.
The real point about allocating memory in C is that you
have to do it explicitly all the time, so that you can
free it explicitly later. That's what makes a lot of
things so painful.
> When I am talking about string processing, I mean performing several
> operations and producing a single string result; the style of lisp woulf
> typically produce several intermediate strings in a process like this,
> which is less efficient.
True, but how often is this sort of string manipulation
actually speed-critical?
> I also need to be able to extract specific
> types of values at arbitrary points in the string. To get an integer
> out of a long string like "Here is your number: 5, happy?" is more
> difficult in LISP than in C.
I'm unconvinced. It's probably more verbose, unless you
define some handy functions to make it easier; but if
you aren't doing it often enough for that to be a win
then you probably don't care that it's more verbose.
> With buffer processing, it is often necessary to extract binary types
> out of a byte stream of some kind, like for example if you are
> communicating via TCP or storing data in a compact form on disk. To be
> honest, I dont even know how to encode and decode lisp types into a
> binary form, even less extract binary types that may have been written
> by other languages...
I wouldn't call that string processing.
> Try and implement this in LISP:
>
> int i, x=0;
> char buf[200] = "xyz,abc,2.3=12";
> float foundfloats[20];
Eeurgh. This will silently cause memory to be overwritten
if there are more than 20 floats embedded in the string.
C encourages this kind of thing.
> for(i=0; i++; i<sizeof(buf))
> {
> if(buf[i] == 0)
> break;
> if(buf[i] == ',')
> buf[i] = '\n';
> if(buf[i] == '.')
> {
> int j;
> for(j=i; j>0; j++)
> {
> if(buf[j] == 0)
> {
> foundfloats[x++] = (float) strtod(&(buf[j+1]));
> break;
> }
> }
> }
> }
What on earth is this supposed to be doing? I'm guessing that
(apart from the mistake with |strtod| that Christopher Barry
pointed out) you meant the |j| loop to go downwards, so that
if it finds a decimal point it will look backwards for the
start of the float. But
- presumably you intended to compare against '\n' instead
of against 0 in the float-finding portion?
- if there's a float before the first comma, or immediately
after a comma at the very start of the string, it won't cope;
- it will not complain if you feed it something like "2.3.4.5";
this will in fact cause three 2.3s to be put into the
|foundfloats| array.
Again, C encourages this kind of thing, because it makes it
easy to do half the job and painful to do the whole job.
I can't imagine any purpose for which I'd be doing exactly
this in Lisp (e.g., how come you don't care about how many
commas separate each pair of floats? or about what's in
the string other than numbers? how come you don't consider
"1e6" to be a float? or indeed "3"? how come you accept "2.3foo"
but not "foo2.3"?) But if I were doing this kind of thing in Lisp
I'd probably write it roughly as follows:
(defun parse-float (string &key start end radix junk-allowed)
;; This would have to be a bit hairy. Why isn't it in
;; the CL standard? I'm too lazy to do it now.
)
(defun string-split-iterate (string split-char function)
(let ((start 0))
(loop for start = 0 then (1+ split-pos)
for split-pos = (position split-char string :start start)
while split-pos
do (funcall function start split-pos)
finally (funcall function start (length string)))))
(defun find-floats (string)
(nsubstitute #\Newline #\, string)
(let ((result nil))
(string-split-iterate string #\Newline
(lambda (start end)
(push (parse-float string :start start :junk-allowed t) result)))
(nreverse result)))
This isn't exactly the same as your float-finder, but it would
be trivial to make its semantics more like yours. I think mine's
more likely to be useful.
In the process of implementing it, I've also produced
STRING-SPLIT-ITERATE, which is likely to be useful elsewhere
if you're doing this kind of work.
Of course, the absence of a PARSE-FLOAT in Common Lisp is a
royal pain if you need to be able to do this. It ought to be
there. But, again, it would only need writing once. (And I'd
bet, in fact, that others have already implemented it.)
> Although if this were a real program it woudl need explanatory comments,
> its clear that you can easily scan and modify string in-place quite
> easily.
It obviously isn't that easy, since your code has some very odd
bugs. (For contrast, my Lisp above ran perfectly first time,
modulo the absence of PARSE-FLOAT; and I am an unusually unreliable
programmer.)
> I suspect an equivalent LISP inplementation would have a number
> of #\Newline and #\Comma entries that would make me feel very
> unfortable. Not only that, but the (aref buf i) syntax is much more
> difficult to type than buf[i], because it has an extra 6 characters, and
> all of "aref" goes on the same hand...
There isn't a single AREF in my code above. (Some might be
needed in PARSE-FLOAT, though CHAR is likely to be more
appropriate.) There are two instances of #\Newline, though
I'm at a loss to see why you think this is intrinsically
worse than '\n'. (It seems much better to me.) And there's
one #\, ; I agree that this is a bit weird, but it's hardly
a major problem.
--
Gareth McCaughan ················@pobox.com
sig under construction
From: Christopher R. Barry
Subject: The value (?) of regular expressions (was Re: The value (?) of popularity)
Date:
Message-ID: <87g0zt1yy5.fsf_-_@2xtreme.net>
Gareth McCaughan <················@pobox.com> writes:
> I'd probably write it roughly as follows:
>
> (defun parse-float (string &key start end radix junk-allowed)
> ;; This would have to be a bit hairy. Why isn't it in
> ;; the CL standard? I'm too lazy to do it now.
[...]
Didn't we already have a huge thread about standardizing PARSE-FLOAT a
number of months ago? I actually don't think it's a good idea. Rather
than have a million PARSE-* functions, it would be better to just have
a good regex facility, because then you could implement all of your
zillion PARSE-* functions yourself. CL could even perhaps provide
special matches or predefined regexs for FLOATs and other printed
representations of objects if there's an elegant way to do it.
Parsing a float, whether 1.0, 3.141592653589793d0, 8.84e+28, or
whatever is not incredibly time-consuming to get right with regular
expressions.
Christopher
From: Jason Trenouth
Subject: Re: The value (?) of regular expressions (was Re: The value (?) of popularity)
Date:
Message-ID: <Lor4NynUO6BweGgPVjNf7LG1tE+N@4ax.com>
On Sat, 02 Oct 1999 16:56:16 GMT, ······@2xtreme.net (Christopher R. Barry)
wrote:
> Gareth McCaughan <················@pobox.com> writes:
>
> > I'd probably write it roughly as follows:
> >
> > (defun parse-float (string &key start end radix junk-allowed)
> > ;; This would have to be a bit hairy. Why isn't it in
> > ;; the CL standard? I'm too lazy to do it now.
>
> [...]
>
> Didn't we already have a huge thread about standardizing PARSE-FLOAT a
> number of months ago? I actually don't think it's a good idea. Rather
> than have a million PARSE-* functions, it would be better to just have
> a good regex facility, because then you could implement all of your
> zillion PARSE-* functions yourself. CL could even perhaps provide
> special matches or predefined regexs for FLOATs and other printed
> representations of objects if there's an elegant way to do it.
>
> Parsing a float, whether 1.0, 3.141592653589793d0, 8.84e+28, or
> whatever is not incredibly time-consuming to get right with regular
> expressions.
NB There is more work to parsing a floating point number than just finding a
string that looks like one. You subsequently have to convert that string into
the language's concept of a float. The hypothetical PARSE-FLOAT function might
often be used on strings found found by a regexp. So regexps aren't, in
general, a generic replacement for PARSE-* functions.
__Jason
Gareth McCaughan wrote:
>
> Dobes Vandermeer wrote:
>
> What on earth is this supposed to be doing?
Obviously I made way too many syntactical errors...
> I can't imagine any purpose for which I'd be doing exactly
> this in Lisp (e.g., how come you don't care about how many
> commas separate each pair of floats? or about what's in
> the string other than numbers? how come you don't consider
> "1e6" to be a float? or indeed "3"? how come you accept "2.3foo"
> but not "foo2.3"?) But if I were doing this kind of thing in Lisp
It might, for example, be in a script or sonfiguration file, or as part
of a streamed IPC communication.
> > With buffer processing, it is often necessary to extract binary types
> > out of a byte stream of some kind, like for example if you are
> > communicating via TCP or storing data in a compact form on disk. To be
> > honest, I dont even know how to encode and decode lisp types into a
> > binary form, even less extract binary types that may have been written
> > by other languages...
>
> I wouldn't call that string processing.
Originally I bundled "string a buffer processing". I wont risk tkaing
this much further, but how do you typically encode and decode LISP
objects into a binary stream?
CU
Dobes
On Wed, 06 Oct 1999 04:21:50 GMT, Dobes Vandermeer <·····@mindless.com>
wrote:
> this much further, but how do you typically encode and decode LISP
> objects into a binary stream?
There's an example in section 4.4 of "Object-Oriented Programming in Common
Lisp - A Programmer's Guide to CLOS" by Sonya Keene (Addison Wesley, 1989).
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
* Gareth McCaughan wrote:
> { size_t l1 = strlen(foo);
> size_t l2 = strlen(bar)+1;
> char * s = xmalloc(l1+l2);
> memcpy(s,foo,l1);
> memcpy(s,bar,l2);
> ...
> }
This is really a little unfair on C:
strcat(strcat(xmalloc(strlen(foo) + strlen(bar) + 1),
foo),
bar);
is a much simpler way of saying this (well, I think so). It's
slightly slower than it might be because the second strcat has to walk
the string you are building (your one has a bug BTW, the second memcpy
needs to be memcpy(s + l1, ...)). I guess C people typically *would*
worry about that kind of inefficiency.
Of course you still get killed by the lack of GC, but you always get
killed by that.
--tim
From: Gareth McCaughan
Subject: Re: The value (?) of popularity
Date:
Message-ID: <86emfezkff.fsf@g.local>
Tim Bradshaw wrote:
> * Gareth McCaughan wrote:
>
>> { size_t l1 = strlen(foo);
>> size_t l2 = strlen(bar)+1;
>> char * s = xmalloc(l1+l2);
>> memcpy(s,foo,l1);
>> memcpy(s,bar,l2);
>> ...
>> }
>
> This is really a little unfair on C:
>
> strcat(strcat(xmalloc(strlen(foo) + strlen(bar) + 1),
> foo),
> bar);
>
> is a much simpler way of saying this (well, I think so). It's
> slightly slower than it might be because the second strcat has to walk
> the string you are building (your one has a bug BTW, the second memcpy
> needs to be memcpy(s + l1, ...)). I guess C people typically *would*
> worry about that kind of inefficiency.
Yes, I forgot to type "+l1". The fact that this is easy to do
is another reason why string handling is annoying in C.
By the way, yours has a bug too: the inner |strcat| should be
|strcpy|.
> Of course you still get killed by the lack of GC, but you always get
> killed by that.
Well, as I said, the lack of GC is ultimately the thing that
makes working with strings in C so unpleasant. It's also
probably the reason why I didn't think of your way to write
the concatenation: I don't tend to think of functional
composition being a viable option with strings in C very
much... :-)
--
Gareth McCaughan ················@pobox.com
sig under construction
* Gareth McCaughan wrote:
> By the way, yours has a bug too: the inner |strcat| should be
> |strcpy|.
No, strcat will work -- the string from xmalloc is (I assume!)
zero-filled, so strcat will do the right thing.
> Well, as I said, the lack of GC is ultimately the thing that
> makes working with strings in C so unpleasant. It's also
> probably the reason why I didn't think of your way to write
> the concatenation: I don't tend to think of functional
> composition being a viable option with strings in C very
> much... :-)
I think that there's also (not in your case) a cultural difference.
When I writ C nowadays, C people look kind of amused at how I write --
which is typically with a lot of functional-ish stuff -- and I think
that's because they have this imperative mindset.
--tim
From: Gareth McCaughan
Subject: Re: The value (?) of popularity
Date:
Message-ID: <86ln9krsdx.fsf@g.local>
Tim Bradshaw wrote:
[I said:]
>> By the way, yours has a bug too: the inner |strcat| should be
>> |strcpy|.
>
> No, strcat will work -- the string from xmalloc is (I assume!)
> zero-filled, so strcat will do the right thing.
Well, of course |xmalloc| is a non-standard function and
everyone writes their own version :-). My |xmalloc|s
generally look like
void * xmalloc(size_t n) {
void * p = malloc(n);
if (!p) lose("Out of memory, trying to allocate %u bytes", n);
return p;
}
(except that actually I tend to pass a string parameter to help
the error message be clearer).
>> Well, as I said, the lack of GC is ultimately the thing that
>> makes working with strings in C so unpleasant. It's also
>> probably the reason why I didn't think of your way to write
>> the concatenation: I don't tend to think of functional
>> composition being a viable option with strings in C very
>> much... :-)
>
> I think that there's also (not in your case) a cultural difference.
> When I writ C nowadays, C people look kind of amused at how I write --
> which is typically with a lot of functional-ish stuff -- and I think
> that's because they have this imperative mindset.
Yes, I do some pretty "functional" things in C too...
--
Gareth McCaughan ················@pobox.com
sig under construction
In article <···············@lostwithiel.tfeb.org>,
Tim Bradshaw <···@tfeb.org> wrote:
>* Gareth McCaughan wrote:
>
>> By the way, yours has a bug too: the inner |strcat| should be
>> |strcpy|.
>
>No, strcat will work -- the string from xmalloc is (I assume!)
>zero-filled, so strcat will do the right thing.
>
Depends on your xmalloc function. It will doubtless be based
on calloc(), which does zero memory, or malloc(), which doesn't.
It may use something like memset() to zero memory.
If it doesn't, then strcat() start at the memory location pointed
to, keep moving on until it hits a zero byte, and then copy the
string. Over whatever happens to be there. (Or, if you're lucky,
it doesn't find one and dies of a segment violation.)
This is one thing I really like about Lisp. In C and C++, I have
to work really hard to make sure I'm not screwing up something in
memory. In Common Lisp, I'd have to work hard to screw something
up.
--
David H. Thornley | If you want my opinion, ask.
·····@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
In article <··············@g.local>,
Gareth McCaughan <················@pobox.com> writes:
> ...
> (concatenate 'string foo bar)
>
> with
>
> { size_t l1 = strlen(foo);
> size_t l2 = strlen(bar)+1;
> char * s = xmalloc(l1+l2);
> memcpy(s,foo,l1);
> memcpy(s,bar,l2);
do you really expect the concatenated string in s? why do you memcpy
foo at all?
> ...
> }
> ...
--
Hartmann Schaffer
It is better to fill your days with life than your life with days
From: Gareth McCaughan
Subject: Re: The value (?) of popularity
Date:
Message-ID: <86btaizkea.fsf@g.local>
Hartmann Schaffer wrote:
> In article <··············@g.local>,
> Gareth McCaughan <················@pobox.com> writes:
>> ...
>> (concatenate 'string foo bar)
>>
>> with
>>
>> { size_t l1 = strlen(foo);
>> size_t l2 = strlen(bar)+1;
>> char * s = xmalloc(l1+l2);
>> memcpy(s,foo,l1);
>> memcpy(s,bar,l2);
>
> do you really expect the concatenated string in s? why do you memcpy
> foo at all?
I made a mistake (in my typing, not my thinking): there should
be a |+l1| in the second |memcpy|.
--
Gareth McCaughan ················@pobox.com
sig under construction
Erik Naggum <····@naggum.no> writes:
> Digital Equipment Corporation (rest the blessed soul) produced the first
> processor to break the 100MHz barrier, and it's still amazingly fast. of
> course, with despicable Compaq buying it all up, it's going to run the #1
> sluggish software in the world: NT, so it basically runs just as slowly
From http://www.digital.com/windows
Compaq will end development for all 32-bit and 64-bit Windows NT
products on the Alpha platform with the delivery of Windows NT 4.0
Service Pack 6 in late 1999. We will continue to provide support
for
current Alpha Windows NT products, and we will offer migration
paths
to other Compaq platforms.
Andras
From: Tim Bradshaw
Subject: Re: The value (?) of popularity (was Re: With friends like Erik, c.l.l doesn't need enemies)
Date:
Message-ID: <ey3zoy67ydm.fsf@lostwithiel.tfeb.org>
* Dobes Vandermeer wrote:
Without interest there is only
> disappearance and death, and this makes popularity seem essential to
> me. LISP is by no means on that path (yet), but it seems (to me) to be
> almost a general opinion that it is not as popular as we'd like, either.
I'd like to propose a definition of `sufficiently popular' which I
think gets away from the problem that popularity is really not a very
interesting measure.
Lisp is `sufficiently popular' if anyone who really wants to make a
living doing Lisp-related work *can* do that.
I think this is much better than the normal `we'd like there to be
more Lisp' because it depends on whether people *want* to do Lisp. If
no one cares any more them no one will do it, and it's still as
popular as it should be. It probably does not work from a vendor's
point of view -- they (I think) should like Lisp to be more than
sufficiently popular because they then make more money.
Whether Lisp *is* in fact sufficiently popular by this measure I don't
know.
--tim
From: Raymond Toy
Subject: Re: With friends like Erik, c.l.l doesn't need enemies
Date:
Message-ID: <4nr9jbfbt4.fsf@rtp.ericsson.se>
>>>>> "Erik" == Erik Naggum <····@naggum.no> writes:
Erik> * Dobes Vandermeer <·····@mindless.com>
Erik> | Take computers as the most obvious example...
Erik> great example! all the really nice CPU's are relegated to fringe
Erik> markets, and instead we have Intel all over the place. because of
Erik> Intel's popularity, they have had to maintain backward compatibility
Erik> with the first 8086 and not only through every step, but globally.
But at the time, *the* processor was the 8080 (or the completely
upward compatible Z80). The 8086 was not binary compatible with the
8080 so Intel could have made a much better architecture if they had
wanted. The impact would have been the same: old binaries wouldn't
run, new assembly code would need to be written.
Once IBM picked the 8088, I guess there was just too much software out
there for Intel to radically change the architecture any more. Too
bad.
Ray
From: Johan Kullstam
Subject: Re: With friends like Erik, c.l.l doesn't need enemies
Date:
Message-ID: <un1tyq1sl.fsf@res.raytheon.com>
Raymond Toy <···@rtp.ericsson.se> writes:
> >>>>> "Erik" == Erik Naggum <····@naggum.no> writes:
>
> Erik> * Dobes Vandermeer <·····@mindless.com>
> Erik> | Take computers as the most obvious example...
>
> Erik> great example! all the really nice CPU's are relegated to fringe
> Erik> markets, and instead we have Intel all over the place. because of
> Erik> Intel's popularity, they have had to maintain backward compatibility
> Erik> with the first 8086 and not only through every step, but globally.
>
> But at the time, *the* processor was the 8080 (or the completely
> upward compatible Z80). The 8086 was not binary compatible with the
> 8080 so Intel could have made a much better architecture if they had
> wanted. The impact would have been the same: old binaries wouldn't
> run, new assembly code would need to be written.
>
> Once IBM picked the 8088, I guess there was just too much software out
> there for Intel to radically change the architecture any more. Too
> bad.
let me throw in a few more items
0) when intel built a 16 bit and 32 bit dual personality processor in
the 80386 backwards compatibility of 32 bit mode with legacy 16 bit
mode was lost *again*. intel could have aritrarly chosen the style
of 32 bit arch portion. there was no reason to duplicate an
already losing design like they did[1].
1) other computer manufacturers have been able to change processor.
examples are sun and apple who moved from m68k (a fine cpu imho) to
sparc and powerpc (also fine cpus). in the case of apple there is
even an emulation mode to run old binaries.
2) it took microsoft 6-7 years to port their software from 16 bit
8088, 80286 to 32 bit modes on 80386, i486, pentium &c.
[1] with the hindsight of microsoft's track record on software
porting, perhaps there was good reason. i suspect intel is very
worried about the introduction of the merced. one can only hope that
it can help break the stranglehold microsoft has on the computer
industry.
--
johan kullstam
In article <··············@rtp.ericsson.se>,
Raymond Toy <···@rtp.ericsson.se> wrote:
>>>>>> "Erik" == Erik Naggum <····@naggum.no> writes:
>
> Erik> * Dobes Vandermeer <·····@mindless.com>
> Erik> | Take computers as the most obvious example...
>
> Erik> great example! all the really nice CPU's are relegated to fringe
> Erik> markets, and instead we have Intel all over the place. because of
> Erik> Intel's popularity, they have had to maintain backward compatibility
> Erik> with the first 8086 and not only through every step, but globally.
>
>But at the time, *the* processor was the 8080 (or the completely
>upward compatible Z80). The 8086 was not binary compatible with the
>8080 so Intel could have made a much better architecture if they had
>wanted.
Not so. The 8086/8088 was not binary compatible with the 8080, but it
was assembly source code compatible. Intel provided a processor that
would take 8080 source and assemble it into 8086 binary. Much of the
software that was available for the IBM PC initially was available
for CP/M on the 8080, just reassembled. It meant that the IBM PC
ran rather slowly at first, but that didn't seem to stop it in
the marketplace.
This is why the 8086/8088 was screwy. I don't know why the Zilog
Z8000 was screwy. The Motorola 68000 was not screwy.
>Once IBM picked the 8088, I guess there was just too much software out
>there for Intel to radically change the architecture any more. Too
>bad.
>
There's always been too much software to radically change the
architecture. I haven't been following Intel architecture even
slightly of late, but in the last Pentium code I glanced at I saw
some clear signs of compatibility with the 8008 (yes, 8008, not
8080).
--
David H. Thornley | If you want my opinion, ask.
·····@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
From: Raymond Toy
Subject: Re: With friends like Erik, c.l.l doesn't need enemies
Date:
Message-ID: <4nk8p1else.fsf@rtp.ericsson.se>
>>>>> "David" == David Thornley <········@visi.com> writes:
David> In article <··············@rtp.ericsson.se>,
David> Raymond Toy <···@rtp.ericsson.se> wrote:
>> But at the time, *the* processor was the 8080 (or the completely
>> upward compatible Z80). The 8086 was not binary compatible with the
>> 8080 so Intel could have made a much better architecture if they had
>> wanted.
David> Not so. The 8086/8088 was not binary compatible with the 8080, but it
David> was assembly source code compatible. Intel provided a processor that
David> would take 8080 source and assemble it into 8086 binary. Much of the
But you had to get a new assembler to assemble your original 8080 code
to the 8086, so the assembler could have really been a
"translator/compiler" that mapped the original code, registers,
etc. into the new (non 8086) architecture.
David> This is why the 8086/8088 was screwy. I don't know why the Zilog
David> Z8000 was screwy. The Motorola 68000 was not screwy.
The only thing "screwy" about the Z8000 that I can remember is the
16-bit segment registers, just like the 8086. Except for that, I
think the Z8000 had a pretty clean architecture. I had always assumed
(perhaps incorrectly) that doing a full 32-bit architecture with
32-bit paths was either too hard or too expensive (in people or
silicon) at the time.
David> There's always been too much software to radically change the
David> architecture. I haven't been following Intel architecture even
David> slightly of late, but in the last Pentium code I glanced at I saw
David> some clear signs of compatibility with the 8008 (yes, 8008, not
David> 8080).
Cool! What was that? I'm not familiar with the 8008.
Ray
From: Dobes Vandermeer
Subject: Re: With friends like Erik, c.l.l doesn't need enemies
Date:
Message-ID: <37EDCD90.C0C78C62@mindless.com>
Erann Gat wrote:
>
> In article <··············@snapdragon.csl.sri.com>, Fred Gilham
> <······@snapdragon.csl.sri.com> wrote:
>
> > The price you pay is that he `doesn't suffer fools gladly.'
>
> I think we pay a higher price than that.
I agree with everything you've said.
Another aspect that you missed, is that whenever someone tries to
criticise LISP's shortcomings, Erik (and others) violently resist, which
turns people off to LISP immediately. Anytime someone refuses to be
open minded you can pretty much discard their opinions offhandedly,
because they are obviously not listening. While poking around at
packages I discovered that any kind of misstep in the direction of "I
dont love EVERYTHING about LISP" is pretty much illegal.
> Everyone around you believes it because everyone around *them*
> believes it. And if you trace things back you will find that everyone
> believes that HIV causes AIDS not because there is actualy good scientific
> evidence for it, but because in 1984 a US government official called a
> news conference to announce that it was so, and no one (except Duesberg)
> ever bothered to seriously question it.
I was under the impression that HIV was just an indicator of AIDS, and
in fact was not the cause... ?
CU
Dobes
From: Dobes Vandermeer
Subject: Re: With friends like Erik, c.l.l doesn't need enemies
Date:
Message-ID: <37EDCDA2.53FD692A@mindless.com>
Erann Gat wrote:
>
> In article <··············@snapdragon.csl.sri.com>, Fred Gilham
> <······@snapdragon.csl.sri.com> wrote:
>
> > The price you pay is that he `doesn't suffer fools gladly.'
>
> I think we pay a higher price than that.
I agree with everything you've said.
Another aspect that you missed, is that whenever someone tries to
criticise LISP's shortcomings, Erik (and others) violently resist, which
turns people off to LISP immediately. Anytime someone refuses to be
open minded you can pretty much discard their opinions offhandedly,
because they are obviously not listening. While poking around at
packages I discovered that any kind of misstep in the direction of "I
dont love EVERYTHING about LISP" is pretty much illegal.
> Everyone around you believes it because everyone around *them*
> believes it. And if you trace things back you will find that everyone
> believes that HIV causes AIDS not because there is actualy good scientific
> evidence for it, but because in 1984 a US government official called a
> news conference to announce that it was so, and no one (except Duesberg)
> ever bothered to seriously question it.
I was under the impression that HIV was just an indicator of AIDS, and
in fact was not the cause... ?
CU
Dobes
In article <·················@mindless.com>, Dobes Vandermeer <·····@mindless.com> wrote:
> I agree with everything you've said.
>
> Another aspect that you missed, is that whenever someone tries to
> criticise LISP's shortcomings, Erik (and others) violently resist, which
> turns people off to LISP immediately. Anytime someone refuses to be
> open minded you can pretty much discard their opinions offhandedly,
> because they are obviously not listening. While poking around at
> packages I discovered that any kind of misstep in the direction of "I
> dont love EVERYTHING about LISP" is pretty much illegal.
No, it isn't. Constructive criticism is highly welcome.
Bold claims are not.
Your posting is again one in a long list of FUD (see below) posted
to comp.lang.lisp. This is really hard to bear. If
people would only apply the same energy to constructively
work advancing Lisp, ...
One of the solutions to this problem surely is to get more
organized.
---------------------------
From the jargon file:
FUD
/fuhd/ n. Defined by Gene Amdahl after he left IBM to found his own company: "FUD is the fear, uncertainty, and doubt that IBM sales people instill in
the minds of potential customers who might be considering [Amdahl] products." The idea, of course, was to persuade them to go with safe IBM gear
rather than with competitors' equipment. This implicit coercion was traditionally accomplished by promising that Good Things would happen to people
who stuck with IBM, but Dark Shadows loomed over the future of competitors' equipment or software. See IBM.
In article <··············@world.std.com>, Tom Breton <···@world.std.com> wrote:
> No, that's not true. Sorry to say it, guys, but I got the same
> impression as Dobes: Cll doesn't like criticism and suggestions.
some of my observations:
- for some people criticizing get's an attitude
- many criticisms fails basic rules (tone, style, backup, will, need, ...)
- others are criticizing what they have never really tried out or used
- the criticism/suggestion/solution process is totally unsystematic,
as a result nobody feels comfortably
- suggestions are less common
- a lot of suggestions are concentrating on the minor and obscure
- a lot of the suggestions are staying in the unspecific
- coded solutions to CL's (perceived or "real") problems are even more rare
But even if you are thinking that your suggestions fail to
get support - that's actually okay - you need to be prepared very good
to convince people that your suggestions are actually an
improvement. This is hard, but to improve things you need to work hard.
Remember how long it take to create the Common Lisp standard,
remember how much work was needed to create CLOS - this
was really only possible because extremely good experts were
working on this for several years - including a well-thought-out
implementation of CLOS.
Let's give a newer example. Regular expressions.
How do we get a commonly accepted implementation that
has the quality (design, implementation, documentation, ...)
people want? So, who is going to work on that? It would take
several months to solve that problem - but then it
is solved for the next years. Actually solutions already
exist - we need to find them and compare them, then come up
with a proposal - this is a lengthy process. So, how does
the process to actually ***solve*** the problems look
like? A lot of this needs to be done ***long*** before
it will influence the Common Lisp standard. We should
preferrably standardize common practice. So this
is what we need most: solutions and reviews of these
solutions - and not general "criticism" and vague "suggestions".
If we want some to change, then ***we*** have to do the work
and we are asked to present our case in a way that it
can be discussed.
It's a common task to organize this in a way,
that we will move forward as a community and people
really have chance to change things - without having
people feeling bad - which will often be the result
when discussing things on a newsgroup, where a discussion
of these topics often moves from the "unspecific" to the
"personal".
······@lavielle.com (Rainer Joswig) writes:
(Good comments)
[Snippage]
>
> But even if you are thinking that your suggestions fail to
> get support - that's actually okay - you need to be prepared very good
> to convince people that your suggestions are actually an
> improvement. This is hard, but to improve things you need to work hard.
> Remember how long it take to create the Common Lisp standard,
> remember how much work was needed to create CLOS - this
> was really only possible because extremely good experts were
> working on this for several years - including a well-thought-out
> implementation of CLOS.
>
Yes, of course, but the Chinese have a saying "the journey of a
thousand miles begins with a single step".
--
Tom Breton, http://world.std.com/~tob
Not using "gh" since 1997. http://world.std.com/~tob/ugh-free.html
In article <··············@world.std.com>, Tom Breton <···@world.std.com> wrote:
> ······@lavielle.com (Rainer Joswig) writes:
>
> (Good comments)
>
> [Snippage]
>
> >
> > But even if you are thinking that your suggestions fail to
> > get support - that's actually okay - you need to be prepared very good
> > to convince people that your suggestions are actually an
> > improvement. This is hard, but to improve things you need to work hard.
> > Remember how long it take to create the Common Lisp standard,
> > remember how much work was needed to create CLOS - this
> > was really only possible because extremely good experts were
> > working on this for several years - including a well-thought-out
> > implementation of CLOS.
> >
>
> Yes, of course, but the Chinese have a saying "the journey of a
> thousand miles begins with a single step".
Well, it begins with an open parentheses. ;-)
In article <··············@nightfly.apk.net>, ···@nightfly.apk.net (R. Matthew Emerson) wrote:
(good comments)
> (I browsed the archives of the presumably defunct LispOS mailing list
> the other day---now there's an example of too much talking and not
> enough hacking.)
It is okay to have an informal discussion about these things.
If there is currently not a mailing list on this specific
topic (Lisp OS, that is), I'd be willing to create one.
But what we need at some point is to move on to a more
structured approach, that as a result will "generate"
code. Nobody had really an idea about that.
We will need to change that also for some other Lisp topics.
This should preferrably happen in the next half year.
······@lavielle.com (Rainer Joswig) writes:
> In article <··············@nightfly.apk.net>, ···@nightfly.apk.net (R. Matthew Emerson) wrote:
>
> (good comments)
No, he wrote a lengthy cheap shot at me, so please don't cheerlead him
for it.
--
Tom Breton, http://world.std.com/~tob
Not using "gh" since 1997. http://world.std.com/~tob/ugh-free.html
In article <··············@world.std.com>, Tom Breton <···@world.std.com> wrote:
> ······@lavielle.com (Rainer Joswig) writes:
>
> > In article <··············@nightfly.apk.net>, ···@nightfly.apk.net (R. Matthew Emerson) wrote:
> >
> > (good comments)
>
> No, he wrote a lengthy cheap shot at me, so please don't cheerlead him
> for it.
No, I didn't write a "lengthy cheap shot at you". I don't
even care about that at all.
For example I think it is an interesting thing to be able
to link comments and annotations to code - though I wouldn't want
to have it like you have described it. Other people have
been thinking about this, too - they provided
not only an idea, but an implementation. It's your
task to convince people of your idea - it's our joint
task to set something up that presenting the idea is getting
easier for you and that it is easier for us to review your idea.
The result should be something usable.
Actually, I'm more interested in talking with people about how to set up
a process to move Common Lisp forward.
You may think you have not been treated fair here are c.l.l - that's just
not the case IMHO. But then, you should not that much care about
it - your idea spawned an interesting discussion and people
learned something.
* Tom Breton wrote:
> No, that's not true. Sorry to say it, guys, but I got the same
> impression as Dobes: Cll doesn't like criticism and suggestions.
Can you give examples? The only one I can see from here that you've
been involved in was the readable-comment saga -- perhaps you felt
that people were unwilling to take suggestions about that, though I
think that would be the wrong impression.
--tim
Tim Bradshaw <···@tfeb.org> writes:
> * Tom Breton wrote:
>
> > No, that's not true. Sorry to say it, guys, but I got the same
> > impression as Dobes: Cll doesn't like criticism and suggestions.
>
> Can you give examples? The only one I can see from here that you've
> been involved in was the readable-comment saga -- perhaps you felt
> that people were unwilling to take suggestions about that, though I
> think that would be the wrong impression.
Another example, and I don't mean to focus on my own stuff but it's
obviously what I know best, was the suggestion that Lisp syntax could
support resynchronization. Comments ranged from relating how a
similar suggestion was previously rejected (by all means a fair
comment) to the dismissal that "it looks like some snails got lost in
his code".
A example that speaks better for cll was when I suggested just-in-time
bindings for local variables (Lisp has cannibalized the word
"declarations" for "proclaim", "declare", etc, but dammit, in every
other language declarations introduce things with names). Some
comments were of the "just write *this* mess every time" variety, but
in the end, Marco Antoniotti (spelling?) wrote one version, I wrote
another, and both my implementation and his were posted on
gnus.emacs.sources (I think here too, but it's been a while)
--
Tom Breton, http://world.std.com/~tob
Not using "gh" since 1997. http://world.std.com/~tob/ugh-free.html
Tom Breton <···@world.std.com>, in various articles, has written:
> Another example, and I don't mean to focus on my own stuff but it's
> obviously what I know best, was the suggestion that Lisp syntax could
> support resynchronization.
...
> A example that speaks better for cll was when I suggested just-in-time
> bindings for local variables
...
> [whole "comments as code" thing]
...
> [whole "posting more elisp to gnu.emacs.sources than anyone else in
> this group" thing]
...
> Not using "gh" since 1997. http://world.std.com/~tob/ugh-free.html
Tom,
You've spoken much about c.l.l's criticisms for your suggestions for
the Lisp programming language. Do you think you could handle a little
constructive criticism yourself?
Do you know what a "nitpicker" is?
nitpicker
One who is concerned with or finds fault
with insignificant details
Now it may be a little cruel and insensitive of me to consider issues
such as "syntax resynchronization" or ""gh"-free spelling" as
insignificant, but if you step back for a minute and look at the big
picture of things; are these things really worth spending your time
and creative energy on?
Are any of your ideas ever going to come to fruition?
They're not if you don't _make_ them. So stop and think for a minute
about how you can realistically get yourself from where you are now to
a position where your ideas have been accepted and implemented. Did
you come up with a solution?
Some of your ideas may be impossible to make happen. (Like
widely-practiced "gh"-free spelling.) If that is the case, are they
really worth your continued investment of time?
And about your gnu.emacs.sources posting comment: the stuff in general
is small hacks probably only of real use to you, just like every
experienced Emacs user has made. I could clean and post all my
Lisp-mode hacks or my .emacs hacks or my hacks that make dealing with
HTML braindamage somewhat tolerably painful for my needs to
gnu.emacs.sources, but the're probably only really useful to me.
Another thing: You haven't convinced me at all how things like "syntax
resynchronization" are really going to give me a good return on the
investment of using them. (And implementing them to use them if need
be.) Here I am, Joe Lisp Programmer. Which need of mine does syntax
resynchronization address? Market your hot technology. Mind you: I
already know how to use the Emacs editor and indentation to make sure
I've always got the right number of parens at the right places.
I think that it would be useful if Emacs understood comments in
buffers as proper objects, as many commands in many modes do not do
the right thing at all with comments in certain contexts. (Like
commenting code that wasn't commented or vice-versa.)
I hope you understand my intent with this post. I'm not trying to
"take a long cheap shot at you" or anything like that.
Christopher
Tim Bradshaw <···@tfeb.org> writes:
> * Tom Breton wrote:
>
> > No, that's not true. Sorry to say it, guys, but I got the same
> > impression as Dobes: Cll doesn't like criticism and suggestions.
>
> The only one I can see from here that you've
> been involved in was the readable-comment saga -- perhaps you felt
> that people were unwilling to take suggestions about that, though I
> think that would be the wrong impression.
To expand on that: you know, what bothered me most about the readable
comment saga was that a short time later I found what seems to me a
much stronger drawback to my suggestion, which no-one had remarked on.
(I posted discussion at the time). The *biggest* drawback got
entirely lost in the noise!
--
Tom Breton, http://world.std.com/~tob
Not using "gh" since 1997. http://world.std.com/~tob/ugh-free.html
* Tom Breton wrote:
> To expand on that: you know, what bothered me most about the readable
> comment saga was that a short time later I found what seems to me a
> much stronger drawback to my suggestion, which no-one had remarked on.
> (I posted discussion at the time). The *biggest* drawback got
> entirely lost in the noise!
I guess I should apologise here if I was rude. It turns out that
articles posted from world.std.com, or at least those posted by you
and KMP in recent history, currently have (at least here!) no
newsgroups: line, which is causing my newsreader to do exciting things
with any followups I make -- in particular throw them silently away.
So I was flaming away at you saying you'd ignored my much earlier
note of the problem and it looks like neither that flame, nor (more
significantly) the earlier note of the issue ever got out.
Anyway, for the record people are aware of the comments-in-structures
problem, Indeed, it was mostly this that stopped my own attempt to
implement this idea 8 or so years ago (following experience with D
machines, which did this thing).
Perhaps people would have seemed less hostile if my original message
had got out, sorry.
--tim
PS you might want to find out what is causing newsgroups: headers to
be not generated like this, the headers as I get them are:
From: Tom Breton <···@world.std.com>
Subject: Re: FUD
Date: Mon, 27 Sep 1999 23:03:01 GMT
Mail-Copies-To: never
Organization: Dis
Path: news.demon.co.uk!demon!dispose.news.demon.net!demon!feed1.news.rcn.net!rcn!howland.erols.net!newsfeed.fast.net!uunet!ffx.uu.net!world!news
Sender: ····@world.std.com (Mr Usenet Himself)
Message-ID: <··············@world.std.com>
References: <························@raffaele.ne.mediaone.net> <··············@erols.com> <············@stic.net> <···············@world.std.com> <··············@snapdragon.csl.sri.com> <····················@milo.jpl.nasa.gov> <·················@mindless.com> <·······················@194.163.195.67> <··············@world.std.com> <···············@lostwithiel.tfeb.org>
X-Newsreader: Gnus v5.6.45/Emacs 20.2
Lines: 21
Xref: lostwithiel.tfeb.org comp.lang.lisp:6945
Kent's articles look similar but are generated by a different version
of gnus so I don't think it's that. It might be my end, but
world.std.com are the only people who have this problem and they have
it consistently.
* I wrote:
> Kent's articles look similar but are generated by a different version
> of gnus so I don't think it's that. It might be my end, but
> world.std.com are the only people who have this problem and they have
> it consistently.
This does appear to be something wrong with either my service provider
or my system. Is anyone else using demon in the UK and could they let
me know (by mail) if there are missing newsgroup headers?
Sorry for off-topicness, it's a bit disturbing when software you trust
slightly suddenly turns out to have been malfuntioning for months.
--tim
Tom Breton <···@world.std.com> writes:
> No, that's not true. Sorry to say it, guys, but I got the same
> impression as Dobes: Cll doesn't like criticism and suggestions.
I don't doubt you have that impression, but it's not so.
We like people to do their research first and not speak off the cuff
about things without saying that's what they are doing.
It's possible to have discussions about how the language is perceived,
which is a problem in itself, without worrying about what the truth
is. We can have that discussion. But we should not have that in the
guise of being a criticism of the language. It works best in this
case if someone says "I don't know what I'm talking about but the
following thing has been a barrier: ...". People who do that are
generally very well-received. Sometimes we have an answer for them, and
sometimes not, but we don't think they are putting forth a simultaneous
credential of knowledge about how things work and a request to find out
how things work because they are clueless, the simultaneous presence of
which in one query is usually symptomatic of a problem.
It's also possible to have a discussion about the language being
deficient itself. That requires research and is not something people
from outside the language should just dive in on without doing serious
homework. Languages are, I believe, political parties. They exist to
serve their constituents, not to serve outsiders. It is appropriate,
therefore, that someone identify that they have done the work to be
part of the community because there is no point to trying to perturb a
very stable thing to satisfy someone with no observed commitment to
the language. In this camp, the community looks to see whether the
person is making claims that are at variance with actually having done
basics like "reading the manual". Lots of people don't read manuals,
and that's an issue. But it's an issue of "acceptance" not of
language competence for purpose. If you haven't read about the
language and want to say it wrong, you get beaten down.
Sometimes people are a little hasty about jumping on others. That's
personality--it comes in all kinds. There are no rules here and we take
whoever comes. All in all, though, in a virtual land where you get what
you pay for, I think comp.lang.lisp delivers uncommonly high value for
that non-dollar paid.
Kent M Pitman <······@world.std.com> writes:
> Tom Breton <···@world.std.com> writes:
>
> > No, that's not true. Sorry to say it, guys, but I got the same
> > impression as Dobes: Cll doesn't like criticism and suggestions.
>
> I don't doubt you have that impression, but it's not so.
Well, I'm basing it on discussions that I'm sure you're aware of, so
we disagree.
> We like people to do their research first and not speak off the cuff
> about things without saying that's what they are doing.
Yes, but the resistance I've seen goes beyond that IMO.
[big snip]
>
> Sometimes people are a little hasty about jumping on others. That's
> personality--it comes in all kinds. There are no rules here and we take
> whoever comes. All in all, though, in a virtual land where you get what
> you pay for, I think comp.lang.lisp delivers uncommonly high value for
> that non-dollar paid.
Perhaps. FWIW I used to be on comp.std.c++ a lot, and IMO the
comparison doesn't favor cll, but we can disagree. Not that csc++ is
a bastion of enlitened rationalism either. But ISTM you are
essentially saying we are better than the ne'er-do-wells next door,
which seems so complacent.
--
Tom Breton, http://world.std.com/~tob
Not using "gh" since 1997. http://world.std.com/~tob/ugh-free.html
>
> Yes, but the resistance I've seen goes beyond that IMO.
>
I think it's just that it's a little weird to be using the hands-down
best language on Earth and then have an outsider using some inferior
language drop by and tell Lispers what we need to do to fix the best
language to be had.
A while ago we had someone come along who was raving about his new
experience with Lisp, but had some doubts about certain aspects. That's
a nice mix (tho to make your point, i think someone did rag on him a
little for one innocent Q).
And if John McCarthy wants to pop in and suggest a tweak or two, that
would be cool.
As for bristliness (?!), you know that commercial where the guy keeps
trying to tell someone a long distance call is, i don't know, 10 cents a
minute "anytime, anywhere, to anybody", and the person keeps popping
back with "any time?" then "anywhere?" until the guy loses it?
That's Lispers...you need to have a little compassion for the
old-timers. I've only been on board five years, and I avoid newsgroups
usually, so I'm not at the edge yet. :)
kt
Was this the Erik bashing thread? Who changed the name and let it pop
out from my killfile?
Anyway, yes - comp.lang.lisp is a tad harsh at times but I doubt threads
like this do anything except decrease the signal to noise. Different
groups have different flavours (and they change over time) and - despite
posting the occasional moan myself - I've learned to live with them all.
My two cents: get a kill file and post stuff in a manner you like
(change them from the inside :-)
Andrew
Sent via Deja.com http://www.deja.com/
Before you buy.
On Tue, 28 Sep 1999 17:43:33 GMT, Andrew Cooke wrote:
>My two cents: get a kill file and post stuff in a manner you like (change
>them from the inside :-)
Bravo. I was one of the people (back a while ago) who said that this NG
was one of the worst to get information from (and I still believe it), but
I've come to believe that I was part of the problem.
I wasn't allowing myself to not-win-arguments any more than the other side
of the argument was.
So I've decided to lose arguments more often here, in hopes that my little
corner of an example will help other people who have trouble losing
arguments, and perhaps improve the group.
'Cause we have a LOT of information to impart. It's scary and wonderful
how much Lisp knows that other languages have discovered in bits and
pieces. I hope that eventually we'll be able to communicate it.
>Andrew
--
-William "Billy" Tanksley
···@nightfly.apk.net (R. Matthew Emerson) writes:
> Tom Breton <···@world.std.com> writes:
>
> > ······@lavielle.com (Rainer Joswig) writes:
> >
> > >
> > > No, it isn't. Constructive criticism is highly welcome.
> >
> > No, that's not true. Sorry to say it, guys, but I got the same
> > impression as Dobes: Cll doesn't like criticism and suggestions.
>
> I get annoyed by armchair commentators who are quick to complain, but
> who are slow to produce running code.
> I looked back at a thread about packages that Dobes Vandermeer
> started. I read many excellent responses, and cannot understand how
> any of them could indicate that it is illegal to criticise Lisp. The
> strongest comment I saw was words to the effect of "go try building a
> system with packages; if you run into trouble then, post again."
> Tom Breton argued at one time for the addition of a "winnowing" stage
> to process comments, which could (if I am remembering the argument
> correctly) then be represented as ordinary sexps (and eliminated at
> this "winnowing" stage before evaluation). The idea was not received
> with much enthusiasm; readers did not see the value of such an
> addition.
...which continues on to attack me and my ideas as a means of
attacking what I said above.
In doing so, you prove my point.
FWIW, you know nothing about me. I've likely posted more lisp to
gnus.emacs.sources than anyone here. But ISTM you wanted to take a
cheap shot, so I doubt that's important to you.
I doubt I'll reply to your answer, but feel free to knock yourself
out saying stuff about me.
--
Tom Breton, http://world.std.com/~tob
Not using "gh" since 1997. http://world.std.com/~tob/ugh-free.html
Tom Breton <···@world.std.com> writes:
> No, that's not true. Sorry to say it, guys, but I got the same
> impression as Dobes: Cll doesn't like criticism and suggestions.
>
One thing you should consider is the history of Lisp as a
language. There is an enormous amount of experience in the "Lisp
civilisation" about what works and what doesn't. This doesn't
necessarily mean the conventional wisdom is always right but there is
a good chance that the criticism is not well founded or that the
suggestion has already been tried and found wanting.
If I remember the thread Dobes started about packages correctly, what
he wanted to do might be useful or not but it wasn't something the
package system was meant for or designed for, and so critising the
package system wasn't reasonable. I have thought about a more fine
grained module system a la Modula-3 or Ada for Lisp myself, but the
fundamental difference between a statically compiled system that these
languages are designed for (in the Ada case as an explicit design
goal) and a dynamically adaptable system like Lisp makes it a tough
problem and I haven't been able to come up with something that
satisfies me. On the other hand, I use the package system as it is and
I've found it very workable in practice.
--
Lieven Marchand <···@bewoner.dma.be>
If there are aliens, they play Go. -- Lasker
"R. Matthew Emerson" wrote:
>
> Tom Breton <···@world.std.com> writes:
>
> > ······@lavielle.com (Rainer Joswig) writes:
> >
> > > In article <·················@mindless.com>, Dobes Vandermeer <·····@mindless.com> wrote:
> > >
> > > > Another aspect that you missed, is that whenever someone tries to
> > > > criticise LISP's shortcomings, Erik (and others) violently resist, which
> > > > turns people off to LISP immediately. Anytime someone refuses to be
> > > > open minded you can pretty much discard their opinions offhandedly,
> > > > because they are obviously not listening. While poking around at
> > > > packages I discovered that any kind of misstep in the direction of "I
> > > > dont love EVERYTHING about LISP" is pretty much illegal.
> > >
> > > No, it isn't. Constructive criticism is highly welcome.
> >
> > No, that's not true. Sorry to say it, guys, but I got the same
> > impression as Dobes: Cll doesn't like criticism and suggestions.
>
> I get annoyed by armchair commentators who are quick to complain, but
> who are slow to produce running code.
You get annoyed quite easily, I guess. If there wasn't a problem, would
people be complaining?
I didn't start this thread, but I continued it to make sure that the
original poster wasn't left feeling alone is his opinion.
CU
Dobes
From: Tom Breton
Subject: Re: With friends like Erik, c.l.l doesn't need enemies
Date:
Message-ID: <m3u2opw1ly.fsf@world.std.com>
Greg <······@erols.com> writes:
>
> Thank you Raffael! That was better said than anything I could come up
> with. I absolutely agree. Posters like Erik [...]
>
> Erik, I also don't appreciate [...]
Look, I haven't always gotten along with Erik, but this is all just
out of line. A whole thread against Erik? Why? And why cheerlead
just because someone attacks him?
--
Tom Breton, http://world.std.com/~tob
Not using "gh" since 1997. http://world.std.com/~tob/ugh-free.html
From: Erik Naggum
Subject: Re: With friends like Erik, c.l.l doesn't need enemies
Date:
Message-ID: <3146818456668748@naggum.no>
* Raffael Cavallaro
| [deletia]
you once wrote that you only responded to what I had done, and that you
weren't to blame for anything you were doing. I didn't have that excuse
since I had started a new thread, in your opinion. you also suggested
that I stick to Lisp in comp.lang.lisp, but you didn't have to, because
of the license to post irrelevant drivel in response to things you found
offensive. I suggest you start taking your own advice, and just shut up.
as for your ability to read things into other people's posts, your
"frankly racist" in response to the fact that the context in which people
normally speak do not include starving and oppressed people in the third
world, was sufficient to tell me that you are quite fanatical and should
be ignored. insofar as you continue to attack me, I respond only to show
that you are off mark. I don't discuss your insane conclusions, and I
have no interest in talking with you at all. confine yourself to what
_you_ experience, what _you_ feel, and state _your_ assumptions and
reactions, and I don't have to say anything. as long as you elevate your
fanatical idiocy to universality, you have to be shot down, every time.
and since you sign off with your degree, I must assume that it is
relevant to why you have to engage in these face-saving exercises where
the other guy must be blamed for everything offensive in the world. I
have seen your kind a lot, Raffael Cavallaro, and since the stuff I'm
being accused of are mutually exclusive, and always the very obvious
"enemy" of whoever is attacking me, such as being a traitor to the white
race when I attack racist idiots, a racist when I don't agree that the
white race is responsible for every ill in the world or I embrace every
race except that I ignore the third world when discussing most topics, a
capitalist pig because I'm not joining the working class, a dangerous
communist when I express my disdain for certain parts of society that
some people think only communists can attack, etc. common to all you
insane fanatics is that I trigger your hate response, not for anything I
do, but for something you need to express your hatred of and which you
find evidence of in just about anything. like, the other day, I was
accused of being a neo-nazi by one idiot who had read my web pages, and
the next day, a neo-nazi said he'd kill me because I collaborate with
Jews and communists and his favorite euphemisms for immigrants and
homosexuals.
you know what I think amidst all this hatred? that it is very useful to
learn how people don't think at all, but instead let their dysfunctional
emotions lead them to extreme destructiveness. if we know who those
people are and we make them expose themselves, the world becomes a safer
place for all.
but what am I actually doing? I refuse to believe most of the drivel
that people take for granted -- instead I seek to understand how such
views could crop up in the first place. in so doing, I do in fact
endanger their views and their beliefs, so there's no problem seeing why
some people respond emotionally. what's puzzling is that a Ph.D is
unable to pull himself together and think. what's puzzling is that
fairly erudite people still protect their silly beliefs with emotional
abandon and nothing else. it's almost as if I catch people red-handed in
the foul act of not thinking, and then they behave as most people do when
caught in an act they would be very ashamed of admitting openly. but
such shame is counter-produtive in the extreme, and when it takes the
shape of projection and false accusations against others to detract
people's attention from the fact that Raffael Cavallaro is so fanatical
that his credibility is exactly zero, it works only to destroy the sender
of such incredible idiocy.
finally, a small but important issue which keeps coming up with alarming
frequency: those who attack me, do so for things I have not actually
done, but they assume I would do, for things they could not know even if
they were true, but necessarily must assume, and they attack me for
holding views and attitudes for which there exists a plethora of evidence
to the contrary. it seems one-dimensional people have to attack me,
because what I do is deny one-dimensional people the right to exist.
and, yeah, of course, I get this "you see the world in black and white"
all the time, because I refuse to see a particular issue in a gray that
would allow others not to make up their mind. I have come to conclude
that one-dimensional people are completely unable to see the image for
all the single-color dots in two-dimensional half-tone images.
if you want me to accuse me of anything, accuse me of having no respect
at all for one-dimensional people, but all you really have to do to
create a new dimension in your life is to learn to be able to appreciate
that context bounds meaning, that no context is wrong, and that only the
act of assuming meaning outside context is wrong.
put another way, especially for Raffael: try to read people to understand
what they have meant, not what you would have meant had you used the same
words.
#:Erik
From: William Deakin
Subject: Re: With friends like Erik, c.l.l doesn't need enemies
Date:
Message-ID: <37E640F1.EE68FD9F@pindar.com>
I find Erik Naggum's postings to be helpful. For his help and advice I thank
him. This personal attack is uncalled for and rude. Please stop.
Best Regards,
:-) will
I think that posts titles like "Re: With friends like Erik, c.l.l doesn't
need enemies"
are inappropriate (as they seems to say in the US) and harmfull.
So please let's stop those personal attacks and go back to LISP/CLOS.
I also find Erik posts generally usefull.
Marc Battyani
BTW I changed the thread title.
William Deakin <·····@pindar.com> wrote in message
······················@pindar.com...
> I find Erik Naggum's postings to be helpful. For his help and advice I
thank
> him. This personal attack is uncalled for and rude. Please stop.
>
> Best Regards,
>
> :-) will
>
Marc Battyani wrote:
> I think that posts titles like "Re: With friends like Erik, c.l.l doesn't
> need enemies"
> are inappropriate (as they seems to say in the US) and harmfull.
> So please let's stop those personal attacks and go back to LISP/CLOS.
>
> I also find Erik posts generally usefull.
>
I hope this will conclude the previous thread. I remember many excellent
posts by Erik. Also, in order to have an argument/flame war, you need two
people,
so it would be wrong to blame everything on Erik.
So let us keep away from witch-hunting (Lisp is about other forms of
""McCarthism"" :-)
Marc
From: Tom Breton
Subject: Re: With friends like Erik, c.l.l doesn't need enemies
Date:
Message-ID: <m3r9jtw1fs.fsf@world.std.com>
·······@mediaone.net (Raffael Cavallaro) writes:
> Erik Naggum wrote:
>
> "on this topic, I might add that I have never quite figured out why
> employees don't interview their employers at least as rigorously as they
> interview them, but I have always been an independent consultant because
> I don't want to work for people who don't realize that they have to give
> me a very solid reason to work for them for at least 8 hours a day in a
> location of their choice, nor do I understand why people individually
> accept so horrible working conditions that they have to form labor unions
> so they don't have to accept them, anymore, but I digress."
>
> and denied that fear of destitution was why:
>
> "no, that is not the explanation, although some would have you believe
> that people can be forced to accept anything under threat of becoming
> destitute if they don't."
>
> Erik, your implication is clear; they are foolish for not standing up for
> themselves in the first place as _you_ do. No matter that you run no risk
> of being beaten, tortured, or murdered, or of starving if you express your
> wants directly to your prospective employers.
>
> You deride people who would forfeit their lives and/or their loved ones'
> lives if they stood up to their employers, for not being independent
> consultants.
How'd beating etc get into it? You're posting from mediaone.net, so
you seem to be in the US like I am, and in case you really don't know,
torturing and murdering one's employees is illegal and uncommon in
this country.
--
Tom Breton, http://world.std.com/~tob
Not using "gh" since 1997. http://world.std.com/~tob/ugh-free.html
In article <··············@world.std.com>, Tom Breton <···@world.std.com> wrote:
>How'd beating etc get into it? You're posting from mediaone.net, so
>you seem to be in the US like I am, and in case you really don't know,
>torturing and murdering one's employees is illegal and uncommon in
>this country.
Erik said "people." Not "Norwegians," or "US citizens," but "people." That
includes the _majority_ of the world's people, who live in what is known
as the Third World. For _most_ people in the world, labor organizing is
risking beating, torture, imprisonment or death.
As regards the good old US of A, you've obviously forgotten the history of
labor organization in the US, or you'd remember that earlier this century,
strikers were fired, beaten, and, on occasion, shot and killed. Things
were not always as they are now.
Raf
--
Raffael Cavallaro, Ph.D.
·······@mediaone.net
From: Andy Freeman
Subject: Re: With friends like Erik, c.l.l doesn't need enemies
Date:
Message-ID: <7saust$f64$1@nnrp1.deja.com>
In article <························@raffaele.ne.mediaone.net>,
·······@mediaone.net (Raffael Cavallaro) wrote:
> Erik said "people." Not "Norwegians," or "US citizens," but "people."
That
> includes the _majority_ of the world's people, who live in what is
known
> as the Third World. For _most_ people in the world, labor organizing
is
> risking beating, torture, imprisonment or death.
We've yet to establish why Cavallaro is chasing evil capitalists
in c.l.l, let alone why chasing Naggum is appropriate.
BTW - One might reasonably look at the premises of "labor
organizing" that has such risks.
Consider the strike. It isn't merely a refusal to work, it is
also a refusal to let someone else work in "your" place. To
accomplish the latter goal, you must "be available" for
confrontation.
It is obviously wrong to force someone to work, but resisting
efforts to employ someone else is different, and that's what's
going on in almost all "labor violence". Strikers don't just
refuse to work.
The evil capitalists in question are providing miserable jobs
which are better than the available alternatives. The "labor
violence" that Cavallero rants about occurs when people who
have those jobs want more AND try to keep the evil capitalists
from employing someone else who will accept the offered terms.
While the evil capitalists aren't justified in using every
tactic to resist the latter, the range of justifiable actions
to impose it is much smaller, and all too often crossed by
the "labor organizing" that Cavallero finds so "noble".
-andy
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
In article <············@nnrp1.deja.com>, Andy Freeman
<······@earthlink.net> wrote:
>Consider the strike. It isn't merely a refusal to work, it is
>also a refusal to let someone else work in "your" place. To
>accomplish the latter goal, you must "be available" for
>confrontation.
No, this is simply untrue. In the US, on only needs to go back to the
recent UPS strike to see this. Lower management drove the delivery trucks
until the strike ended. A strike just means that workers refuse to work,
nothing more. They often picket, but they can't stop other workers from
taking their place. The idea is to make it more expensive for management
to hire a new workforce than to negotiate a settlement.
>The evil capitalists in question are providing miserable jobs
>which are better than the available alternatives.
You miss the fundamental point that the "available alternatives" are
grossly and artificially skewed by the use of violence. If police put on
masks in their off duty hours and kill labor organizers (a common
occurrence in much of this hemisphere), then management feels pretty
secure that workers will accept even the lowest paying, worst condition
"alternatives." The message is clear: Those in power want you to work for
whatever wage is offered under whatever conditions, or else.
>The "labor
>violence" that Cavallero rants about occurs when people who
>have those jobs want more AND try to keep the evil capitalists
>from employing someone else who will accept the offered terms.
You're just so completely out of touch with the realities of most of the
world that it's frankly frightening. In much of the world, simply trying
to get workers to organize (not even strike mind you, just form a union to
negotiate a contract with management) can land you in prison, or get you
killed. The idea that most "labor violence" (why this is in quotes I don't
know, since they're not my words) is committed by workers is simply false.
You have a very biased view because you live in one of the relatively few
countries on earth where labor organizing has been relatively successful.
And strikers in the US don't begin to compare with the violence committed
by management and rogue security forces in much of the world.
>We've yet to establish why Cavallaro is chasing evil capitalists
>in c.l.l, let alone why chasing Naggum is appropriate.
Well conspiracy theorists will not be satisfied, but it really is because
Erik wrote some things that are a fundamental distortion of the way the
world is for _most_ people. You find yourself in the same situation, since
you continue to maintain that unfettered "free markets" will "make the
world a better place." This simply isn't so. Markets need to be
constrained by laws enforcing ordinary decency. Otherwise slavery would be
legal (after all, if there's a market demand for slaves, then in a truly
free market, an entrepreneur should be free to fill it, right?). Before
anyone objects that slavery is economically inefficient, and there's no
market for it, be aware that slavery continues to be practiced in the
Dominican Republic, where rogue Dominican security forces abduct Haitian
boys and enslave them on Dominican sugar plantations.
Raf
--
Raffael Cavallaro, Ph.D.
·······@mediaone.net
In article <························@raffaele.ne.mediaone.net>,
·······@mediaone.net (Raffael Cavallaro) writes:
> In article <············@nnrp1.deja.com>, Andy Freeman
> <······@earthlink.net> wrote:
>
>>Consider the strike. It isn't merely a refusal to work, it is
>>also a refusal to let someone else work in "your" place. To
>>accomplish the latter goal, you must "be available" for
>>confrontation.
>
> No, this is simply untrue. In the US, on only needs to go back to the
> recent UPS strike to see this. Lower management drove the delivery trucks
> until the strike ended. A strike just means that workers refuse to work,
> nothing more. They often picket, but they can't stop other workers from
> taking their place. The idea is to make it more expensive for management
that depends very much on the jurisdiction
> ...
--
Hartmann Schaffer
It is better to fill your days with life than your life with days
From: Andy Freeman
Subject: Re: With friends like Erik, c.l.l doesn't need enemies
Date:
Message-ID: <7t0ssj$s09$1@nnrp1.deja.com>
In article <························@raffaele.ne.mediaone.net>,
·······@mediaone.net (Raffael Cavallaro) wrote:
> In article <············@nnrp1.deja.com>, Andy Freeman
> >Consider the strike. It isn't merely a refusal to work, it is
> >also a refusal to let someone else work in "your" place. To
> >accomplish the latter goal, you must "be available" for
> >confrontation.
>
> No, this is simply untrue. In the US, on only needs to go back to the
> recent UPS strike to see this.
The UPS strike is a good example of my point. The violence by
"strikers" to stop lower managment from working is well documented,
as is the behavior of strikers towards replacement workers, aka
"scabs".
>The idea is to make it more expensive for management
> to hire a new workforce than to negotiate a settlement.
Yup, and the way one does this is....
> You miss the fundamental point that the "available alternatives" are
> grossly and artificially skewed by the use of violence. If police put
on
> masks in their off duty hours and kill labor organizers
No one kills the people who choose another line of work.
> >We've yet to establish why Cavallaro is chasing evil capitalists
> >in c.l.l, let alone why chasing Naggum is appropriate.
>
> Well conspiracy theorists will not be satisfied, but it really is
because
> Erik wrote some things that are a fundamental distortion of the way
the
> world is for _most_ people.
That's nice, but doesn't answer my question.
Maybe an answer prototype would help. Suppose that Cavallaro
believes that his c.l.l posts improve people's lives. An answer
would include a statement of that goalt together with some
argument showing that those posts do have that effect.
BTW - The backhanded accusation of slave-trading was a nice touch.
(Hint - placing two things next to one another in a paragraph
doesn't make them related, and honest people don't confuse "some
Nazis wore pants" with a useful commentary on pants wearers.)
-andy
Sent via Deja.com http://www.deja.com/
Before you buy.
From: Dobes Vandermeer
Subject: Re: With friends like Erik, c.l.l doesn't need enemies
Date:
Message-ID: <37E86F61.65BE56DA@mindless.com>
No no, we just need a FAQ.
Q 1: What do I do if Erik Naggum (or someone else) posts a nasty reponse
to my question?
A 1: Ignoring it is the best policy; you might still receive useful
posts from other people on the group, otherwise he may actually be
presenting a useful response hidden behind an acidic tongue
CU
Dobes
From: Fernando Mato Mira
Subject: Re: With friends like Erik, c.l.l doesn't need enemies
Date:
Message-ID: <37E88F34.1AD8F206@iname.com>
Dobes Vandermeer wrote:
> No no, we just need a FAQ.
Q2: (eq #\Erik #:Erik)
A2: undefined
;-)