Has anyone had any experience with describing CL systems with UML?
I'm not really familiar with UML, but it looks laughably too
restrictive to describe CLOS - I'd like hear any other experiences
though.
--tim
(Who suspects that one reason Lisp hasn't won is just because it is
too expressive to wedge into religious orthodoxies like UML and
therefore must be destroyed as heretical, this being about 1209.)
>>>>> "Tim" == Tim Bradshaw <···@tfeb.org> writes:
Tim> Has anyone had any experience with describing CL systems with UML?
Tim> I'm not really familiar with UML, but it looks laughably too
Tim> restrictive to describe CLOS - I'd like hear any other experiences
Tim> though.
Tim> --tim
Tim> (Who suspects that one reason Lisp hasn't won is just because it is
Tim> too expressive to wedge into religious orthodoxies like UML and
Tim> therefore must be destroyed as heretical, this being about 1209.)
Sorry, can't help with UML and CLOS, but I find it rather interesting
that with Rational Rose (a UML tool), the saved files look very much
like lisp. Don't know if it really is or not.
Ray
Raymond Toy <···@rtp.ericsson.se> writes:
> Sorry, can't help with UML and CLOS, but I find it rather interesting
> that with Rational Rose (a UML tool), the saved files look very much
> like lisp. Don't know if it really is or not.
No it's not. It is just a hierarchical parenthesized data format, that's all,
with some wierd syntactical quirks.
To be really lisp, it needs to be evaluated by a lisp engine.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@infomatch.com The Rhythm has my soul.
Tim Bradshaw <···@tfeb.org> writes:
> Has anyone had any experience with describing CL systems with UML?
> I'm not really familiar with UML, but it looks laughably too
> restrictive to describe CLOS - I'd like hear any other experiences
> though.
>
> --tim
>
> (Who suspects that one reason Lisp hasn't won is just because it is
> too expressive to wedge into religious orthodoxies like UML and
> therefore must be destroyed as heretical, this being about 1209.)
Well, I've avoided UML up to this point, but this little thread
reminded me of a laughable bit of theory mongering on the topic of OO
programming:
http://www.nettime.org/nettime.w3archive/200106/msg00050.html
--
Craig Brozefsky <·····@red-bean.com>
http://www.red-bean.com/~craig
"Indifference is the dead weight of history." -- Antonio Gramsci
>>>>> "tim" == Tim Bradshaw <···@tfeb.org> writes:
tim> Has anyone had any experience with describing CL systems with UML?
tim> I'm not really familiar with UML, but it looks laughably too
tim> restrictive to describe CLOS - I'd like hear any other experiences
tim> though.
I think that if you consider a Corba implementation in CL, such as one
in ACL or LispWorks, then UML is more applicable. Corba development
imposes restrictions on OOP that mesh well with UML, as far as I know.
dave
David Bakhash <·····@alum.mit.edu> writes:
>
> I think that if you consider a Corba implementation in CL, such as one
> in ACL or LispWorks, then UML is more applicable. Corba development
> imposes restrictions on OOP that mesh well with UML, as far as I know.
Yes, that's the problem. I want to be able to use a great deal of
what CLOS offers, not toe the priesthood's line.
--tim
Tim Bradshaw <···@tfeb.org> writes:
> David Bakhash <·····@alum.mit.edu> writes:
> > Corba developmentb
> > imposes restrictions on OOP that mesh well with UML, as far as I know.
>
> Yes, that's the problem. I want to be able to use a great deal of
> what CLOS offers, not toe the priesthood's line.
>
I wonder if UML has a special kind of box for :before
methods? for metaclasses? :-)
Seriously -- why would you want to do this? Are you trapped
in hell (i.e. real life) and need this to justify something
to a pointy haired boss? (I'm not being sarcastic -- that's
the best reason I can think of.)
Long long ago, in a galaxy far far away, I did the whole Rational Rose
thing. Put pictures in the repository, shared them with co-workers,
coded C++ to those interfaces, the lot. Now I think only quickly
drawn pictures, _in pencil_, in no `formal' pictorial language, are
useful, to communicate to others (and my future self) what something
was about. For the rest, "the source code is the design", aided, if
need be, by a 1-2 page technical memo.
Does _anybody_ here actually think UML like tools are _useful_?
If so, how?
--
It would be difficult to construe Larry Wall, in article
this as a feature. <·····················@netlabs.com>
Alain Picard <·······@optushome.com.au> writes:
>
> I wonder if UML has a special kind of box for :before
> methods? for metaclasses? :-)
Multimethods, user-definable method combinations?
>
> Seriously -- why would you want to do this? Are you trapped
> in hell (i.e. real life) and need this to justify something
> to a pointy haired boss? (I'm not being sarcastic -- that's
> the best reason I can think of.)
Not quite. I'm standing on the rim of hell, looking in, and watching
those trapped there hammer nails into their own heads and gouge each
other's eyes out with spoons, all the time insisting that they are in
heaven. Strangely the bosses have remarkably smooth & rounded heads -
it is the programmers themselves who are sharpening them to points, in
the pauses between the nail-hammering and gouging.
> Does _anybody_ here actually think UML like tools are _useful_?
> If so, how?
I think they might be useful if you are stuck with crap, rigid,
non-introspective languages like C++. For the life of me I can't see
why a Lisp system should not document itself - if you want a class
graph ask the system to draw you one, if you want to know what methods
there are for a GF, ask it. Trying to use UML to document a system
which is strictly more powerful than it, with no mechanism to keep the
UML design in sync with the code, is going to result in a huge
document which initially does not describe the system it purports to
model, and which drifts rapidly further away from it over time.
But I'm probably wrong - they won't even lend me a head-sharpener
after all.
--tim
Tim Bradshaw <···@tfeb.org> wrote:
> Alain Picard <·······@optushome.com.au> writes:
>>
>> I wonder if UML has a special kind of box for :before
>> methods? for metaclasses? :-)
> Multimethods, user-definable method combinations?
>>
>> Seriously -- why would you want to do this? Are you trapped
>> in hell (i.e. real life) and need this to justify something
>> to a pointy haired boss? (I'm not being sarcastic -- that's
>> the best reason I can think of.)
>> Does _anybody_ here actually think UML like tools are _useful_?
>> If so, how?
> I think they might be useful if you are stuck with crap, rigid,
> non-introspective languages like C++. For the life of me I can't see
> why a Lisp system should not document itself - if you want a class
> graph ask the system to draw you one, if you want to know what methods
> there are for a GF, ask it.
Fair enough...
> Trying to use UML to document a system
> which is strictly more powerful than it, with no mechanism to keep the
> UML design in sync with the code, is going to result in a huge
> document which initially does not describe the system it purports to
> model, and which drifts rapidly further away from it over time.
Well UML is also for designing the system *before* you've built it.
If you're going to design using OO, you might as well describe that design
in UML. Clearly, the tool needs to be easy to use - the only tool I'd give
the time of day is Popkin System Architect. You can then implement in any
language you damn well like, such as lisp (not CLOS, though you could use
that). (If you really must you can give your functions names like
class::member).
To expand my point about why you might want to use UML - most of my
diagrams that I sketch capture much the same info as UML will, in a similar
kind of way. If an easy tool makes your diagram compliant to some standard
that anyone can grok, all the better. Even better, some one else can come
along design modifications once you've gone off to conquer the world (or
possibly in your case been forced off the team for sins such as actually
producing code before the cows home).
> But I'm probably wrong - they won't even lend me a head-sharpener
> after all.
> --tim
* Marcin Tustin wrote:
> Well UML is also for designing the system *before* you've built it.
> If you're going to design using OO, you might as well describe that design
> in UML. Clearly, the tool needs to be easy to use - the only tool I'd give
> the time of day is Popkin System Architect. You can then implement in any
> language you damn well like, such as lisp (not CLOS, though you could use
> that). (If you really must you can give your functions names like
> class::member).
What is your definition of `OO'? Obviously it's different and more
restrictive than anything a Lisp person would like to use...
--tim
Tim Bradshaw <···@cley.com> wrote:
> * Marcin Tustin wrote:
>> Well UML is also for designing the system *before* you've built it.
>> If you're going to design using OO, you might as well describe that design
>> in UML. Clearly, the tool needs to be easy to use - the only tool I'd give
>> the time of day is Popkin System Architect. You can then implement in any
>> language you damn well like, such as lisp (not CLOS, though you could use
>> that). (If you really must you can give your functions names like
>> class::member).
> What is your definition of `OO'? Obviously it's different and more
> restrictive than anything a Lisp person would like to use...
I don't think that it's restrictive - I mean a design involving
classes and objects, which may do whatsoever you design them to do. My point
is that you can design OO and use a non-oo language if you wish. The design is
(to the extent that it is possible and sensible) language independent.
> --tim
Marcin Tustin <·····@ugnode1.ecs.soton.ac.uk> writes:
>
> I don't think that it's restrictive - I mean a design involving
> classes and objects, which may do whatsoever you design them to do. My point
> is that you can design OO and use a non-oo language if you wish. The design is
> (to the extent that it is possible and sensible) language independent.
But if you can't model some major features that your language provides
(such as multimethods, method combination), your implementation is
likely not to bear much resemblance to the model.
--tim
>>>>> "Tim" == Tim Bradshaw <···@tfeb.org> writes:
Tim> But if you can't model some major features that your language provides
Tim> (such as multimethods, method combination), your implementation is
Tim> likely not to bear much resemblance to the model.
It sort of depends on what you mean by "model". If what you want to do
is to describe the *architecture* of a system, it is not inconceivable
that the modelling will be done a such a high level of abstraction
that specifics of the programming language does not show up in the
diagrams.
------------------------+-----------------------------------------------------
Christian Lynbech | Ericsson Telebit, Skanderborgvej 232, DK-8260 Viby J
Phone: +45 8938 5244 | email: ·················@ted.ericsson.dk
Fax: +45 8938 5101 | web: www.ericsson.com
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
In article <··············@chl.ted.dk.eu.ericsson.se>,
Christian Lynbech <·················@ted.ericsson.dk> wrote:
>>>>>> "Tim" == Tim Bradshaw <···@tfeb.org> writes:
>
>Tim> But if you can't model some major features that your language provides
>Tim> (such as multimethods, method combination), your implementation is
>Tim> likely not to bear much resemblance to the model.
>
>It sort of depends on what you mean by "model". If what you want to do
>is to describe the *architecture* of a system, it is not inconceivable
>that the modelling will be done a such a high level of abstraction
>that specifics of the programming language does not show up in the
>diagrams.
>
Agreed. However, this implies that the architecture is done in
something more abstract than UML, which is closely tied to the
implementation details of C++ and Java.
One problem I had was trying to come up with what sort of picture
I'd draw to express the architecture in the same way that UML
does for C++ or Java. Where do you put the methods? I never
did come up with a good way to draw it.
--
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:
>
> One problem I had was trying to come up with what sort of picture
> I'd draw to express the architecture in the same way that UML
> does for C++ or Java. Where do you put the methods? I never
> did come up with a good way to draw it.
>
It's the multiple-inheritance problem, squared. I once dabbled with
constructing a class and method browser similar to the Interlisp/LOOPS
one for CLOS.
LOOPS is a single-inheritance, single dispatch OO langauge, so all the
class trees are real trees, and all methods are associated with one
owner class, so displaying the class tree and showing methods as menu
lists at each class node works. You can ask the browser questions like
"who implements this method" and get a visually useful answer when the
class nodes blink.
CLOS is a multiple-dispatch, multiple-inheritance OO langauge, so the
class tree is a DAG (at least) and methods are all over the map. I
thought about having a seperate method browser that would show a generic
function at the root of a tree and methods arranged in some inheritance
order beneath it (super-class methods closer to the root, :AROUND
methods above, :BEFORE and :AFTER at the same level as uncombined
methods), but it never really came together.
--
Remove obvious stuff to e-mail me.
Bob Bane
David Thornley <········@visi.com> wrote:
> In article <··············@chl.ted.dk.eu.ericsson.se>,
> Christian Lynbech <·················@ted.ericsson.dk> wrote:
>>>>>>> "Tim" == Tim Bradshaw <···@tfeb.org> writes:
>>
>>Tim> But if you can't model some major features that your language provides
>>Tim> (such as multimethods, method combination), your implementation is
>>Tim> likely not to bear much resemblance to the model.
>>
>>It sort of depends on what you mean by "model". If what you want to do
>>is to describe the *architecture* of a system, it is not inconceivable
>>that the modelling will be done a such a high level of abstraction
>>that specifics of the programming language does not show up in the
>>diagrams.
>>
> Agreed. However, this implies that the architecture is done in
> something more abstract than UML, which is closely tied to the
> implementation details of C++ and Java.
> One problem I had was trying to come up with what sort of picture
> I'd draw to express the architecture in the same way that UML
> does for C++ or Java. Where do you put the methods? I never
> did come up with a good way to draw it.
Presumably "normal" methods would go where they do in UML - you
only need some way to deal with such things as multimethods
(All involved classes would be my choice).
> --
> David H. Thornley | If you want my opinion, ask.
> ·····@thornley.net | If you don't, flee.
> http://www.thornley.net/~thornley/david/ | O-
>>>>> "David" == David Thornley <········@visi.com> writes:
David> In article <··············@chl.ted.dk.eu.ericsson.se>,
David> Christian Lynbech <·················@ted.ericsson.dk> wrote:
>>>>>>> "Tim" == Tim Bradshaw <···@tfeb.org> writes:
>>
Tim> But if you can't model some major features that your language provides
Tim> (such as multimethods, method combination), your implementation is
Tim> likely not to bear much resemblance to the model.
>>
>> It sort of depends on what you mean by "model". If what you want to do
>> is to describe the *architecture* of a system, it is not inconceivable
>> that the modelling will be done a such a high level of abstraction
>> that specifics of the programming language does not show up in the
>> diagrams.
>>
David> Agreed. However, this implies that the architecture is done in
David> something more abstract than UML, which is closely tied to the
David> implementation details of C++ and Java.
I see your point, but I am not quite convinced that can not use UML in
more abstract ways. After all, as I understand it, UML is primarily
just a set of boxes where most of the interpretation/semantics is done
through stereotypes, which one can extend as necessary.
Some constructs will be completely inadequate for Lisp, but I would
expect much of the more generic relationship stuff would be applicable.
David> One problem I had was trying to come up with what sort of picture
David> I'd draw to express the architecture in the same way that UML
David> does for C++ or Java. Where do you put the methods? I never
David> did come up with a good way to draw it.
How about modelling the method as entities in themselves rather than
as part of particular classes (as one would do for java or C++) and
then use a "relates to" arrow with a "dispatches on" stereotype
pointing to the classes the method dispatches on.
One could further have a box for the generic function and have the
methods display some sort of ancestral relation towards the gf.
And before/after methods could then perhaps be displayed as a sort of
decomposition of the gf object.
Anyway, I would not be at all surprised if my enthusiasm would fade
with actual hands-on experience.
------------------------+-----------------------------------------------------
Christian Lynbech | Ericsson Telebit, Skanderborgvej 232, DK-8260 Viby J
Phone: +45 8938 5244 | email: ·················@ted.ericsson.dk
Fax: +45 8938 5101 | web: www.ericsson.com
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
>>>>> "Alain" == Alain Picard <·······@optushome.com.au> writes:
Alain> Tim Bradshaw <···@tfeb.org> writes:
>> David Bakhash <·····@alum.mit.edu> writes:
>> > Corba developmentb
>> > imposes restrictions on OOP that mesh well with UML, as far as I know.
>>
>> Yes, that's the problem. I want to be able to use a great deal of
>> what CLOS offers, not toe the priesthood's line.
>>
I think the main consideration is what to use UML for. UML is after
all to modelling as blank sheets of paper is to writing - just a tool.
Let me first note that I am speaking as a complete novice. I have only
read some of the UML books, so most of what follows will be pure
speculation.
However, I have a distinct feeling that UML could be usefull, at least
to us, as a tool for documenting various aspects of the system.
Alain> I wonder if UML has a special kind of box for :before
Alain> methods? for metaclasses? :-)
The crucial point would be to hit the right level of abstraction. Trying
to rewrite the actual detailed code in diagrams would be pretty pointless.
I do not remember seeing anything that would be directly insufficient
wrt. CLOS. I am for instance pretty sure that multiple inheritance is
explicitly supported, and it should also be remembered that UML is
designed to be extensible.
Alain> Seriously -- why would you want to do this?
For instance, if I wanted to write a tool that could display the class
structure of my lisp application, I would make it draw UML
diagrams. The usefull thing is that a) UML has the concept of
metamodels, so I could to some level of formality define what the
generated diagrams would mean, and b) since UML is (I think) a defacto
standard, it should give other viewers a warm fuzzy feeling when they
see it.
I wouldn't necessary want to use standard UML drawing tools, such as
rational rose. I would probably prefer to use some other (textual)
representration and have the UML diagrams generated from that. In
fact, I would consider to "define" the modelling or documentation
artifact through annotations in the actual code, such that the overall
software architecture would to some degree be embedded within the
program it was meant to document (yes, I think literary programming is
an extremely exiciting methodology).
------------------------+-----------------------------------------------------
Christian Lynbech | Ericsson Telebit, Skanderborgvej 232, DK-8260 Viby J
Phone: +45 8938 5244 | email: ·················@ted.ericsson.dk
Fax: +45 8938 5101 | web: www.ericsson.com
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
Christian Lynbech <·················@ted.ericsson.dk> writes:
> (yes, I think literary programming is an extremely exiciting
> methodology).
I used to be a huge LP enthusiast. Then I wrote a significant Lisp
system without it, then tried to write another with an LP system, and
found it really constraining. So I ditched the LP system (noweb,
which I've found to be the least intrusive). I've found docstrings
and texinfo-generating scripts to be enough. Has anyone had good
experiences with LP and Lisp? I still find LP to be a life-saver with
C++. I'd bet it's because Lisp code tends to be an order of magnitude
more expressive, thus less need for LP. Not really sure, though ...
From: Tim Bradshaw
Subject: Re: Litterate Programming and Lisp (was: CL and UML)
Date:
Message-ID: <nkjzoba98yg.fsf@tfeb.org>
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> I'd bet it's because Lisp code tends to be an order of magnitude
> more expressive, thus less need for LP. Not really sure, though ...
Also, I think that because you can ask a CL system questions about
itself (what methods does this GF have?, what are the subclasses of
this class? and for many systems things like let me edit the
definition of this function) there's less requirement for an external
system which does it for you, except usually statically rather than
dynamically.
--tim
On 14 Jun 2001 11:37:42 -0700, ···@conquest.OCF.Berkeley.EDU (Thomas F.
Burdick) wrote:
> I used to be a huge LP enthusiast. Then I wrote a significant Lisp
> system without it, then tried to write another with an LP system, and
> found it really constraining. So I ditched the LP system (noweb,
Did the literate programming tools you used let you interactively evaluate
Lisp code? If not, how did you deal with that?
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
Paolo Amoroso <·······@mclink.it> writes:
> On 14 Jun 2001 11:37:42 -0700, ···@conquest.OCF.Berkeley.EDU (Thomas F.
> Burdick) wrote:
>
> > I used to be a huge LP enthusiast. Then I wrote a significant Lisp
> > system without it, then tried to write another with an LP system, and
> > found it really constraining. So I ditched the LP system (noweb,
>
> Did the literate programming tools you used let you interactively evaluate
> Lisp code? If not, how did you deal with that?
Well, I pretty much use noweb and emacs with noweb-mode, so I'm in
LaTeX mode in the documentation sections, and ILISP mode in the lisp
sections. So you get the normal emacs support for this (except I had
to re-write the code to evaluate the whole buffer to run it through
notangle first, but that was simple enough).
At Wisdom Systems (ca 1992) we cobbled up an LP system that used macros
to wrap all our defuns, defmethods, etc. to generate a database which
was used by a LaTex generating system. So, i.e.,
(defun foobar (foo bar)
"Foobar does nothing interesting with integer foo and string bar"
&body)
became
(define-function foobar (foo bar)
"Foobar does nothing interesting with integer foo and string bar"
&body)
Which generated, with a generate-document call,
Functions
Name: Foobar
Description: Foobar does nothing interesting with integer foo and
string bar
Arguments: foo bar
(or some such - details are hazy with time/Alzheimer's)
"Thomas F. Burdick" wrote:
>
> Christian Lynbech <·················@ted.ericsson.dk> writes:
>
> > (yes, I think literary programming is an extremely exiciting
> > methodology).
>
> I used to be a huge LP enthusiast. Then I wrote a significant Lisp
> system without it, then tried to write another with an LP system, and
> found it really constraining. So I ditched the LP system (noweb,
> which I've found to be the least intrusive). I've found docstrings
> and texinfo-generating scripts to be enough. Has anyone had good
> experiences with LP and Lisp? I still find LP to be a life-saver with
> C++. I'd bet it's because Lisp code tends to be an order of magnitude
> more expressive, thus less need for LP. Not really sure, though ...
Christian Lynbech <·················@ted.ericsson.dk> writes:
>
> For instance, if I wanted to write a tool that could display the class
> structure of my lisp application, I would make it draw UML
> diagrams. The usefull thing is that a) UML has the concept of
> metamodels, so I could to some level of formality define what the
> generated diagrams would mean, and b) since UML is (I think) a defacto
> standard, it should give other viewers a warm fuzzy feeling when they
> see it.
Well, I'd do this by asking the Lisp system what the class graph was,
and using one of the graphing tools - it's trivial in CLIM, LW comes
with a class grapher (as may Allegro - I use one I wrote in CLIM so
I've never checked), and psgraph will serve at a pinch for
non-graphically-endowed implementations. I guess this fails on the
warm fuzzines (being warm and fuzzy is very importent when your job
consists of hammering nails into your own head).
--tim
Alain Picard <·······@optushome.com.au> writes:
> Long long ago, in a galaxy far far away, I did the whole Rational Rose
> thing. Put pictures in the repository, shared them with co-workers,
> coded C++ to those interfaces, the lot. Now I think only quickly
> drawn pictures, _in pencil_, in no `formal' pictorial language, are
> useful, to communicate to others (and my future self) what something
> was about. For the rest, "the source code is the design", aided, if
> need be, by a 1-2 page technical memo.
Strong agreement here. My experience has been exactly the same in this
regard. Most of the time the UML tools are just a way to waste more time and
resources.
Letting the source code document itself, with only the very high level
architecture/design information in smallish easy-to-read documents lets
software be developed faster and be more maintainable, mainly because there
are less things to go wrong.
Of course, this only works if the source code is actually written in a
readable, maintainable way.
> Does _anybody_ here actually think UML like tools are _useful_?
> If so, how?
On big projects where *everything* needs to be tracked, your diagrams are
viewed by hundreds of people, your diagrams need tool support to verify, etc.
E.g. air traffic control projects.
Even then, I would still make try to make the source code king and use decent
reverse engineering tools to keep the models and code in synch.
Also, a proper UML model can include all sorts of requirements information and
related them to portions of your design, and can also include scenarios and
activity/state diagrams, deployment diagrams, etc. These kinds of things also
need to be decently tracked.
Smallish projects can often get away with not doing this, but the big ones
require tool support at every level.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@infomatch.com The Rhythm has my soul.
Ray Blaak <·····@infomatch.com> writes:
> Alain Picard <·······@optushome.com.au> writes:
>
> > Does _anybody_ here actually think UML like tools are _useful_?
> > If so, how?
>
> On big projects where *everything* needs to be tracked, your diagrams are
> viewed by hundreds of people, your diagrams need tool support to verify, etc.
>
> E.g. air traffic control projects.
>
I believe you are correct. I think on those very large system,
the cost of producing quality software scales almost exponentially
with the size of the problem (and development effort). A colleague
worked on control systems for the F16 aircraft agrees that that
software ends up costing $10,000 per line of code.
Such tools probably _can_ help in those situations. I guess I'm
not saying they're utterly useless; I'm saying they imply a world
in which I have no wish to live. I'll stick with Lisp and small
teams for as long as I can, and work on making small teams more
productive (and able to tackle larger projects through higher
productivity) instead. I've found many of the methods used by
XP useful in this regards. But I wouldn't want my team responsible
for an air traffic or nuclear power plant control system...
I guess that makes me a coward... :-)
--
It would be difficult to construe Larry Wall, in article
this as a feature. <·····················@netlabs.com>
Alain Picard <·······@optushome.com.au> writes:
> Ray Blaak <·····@infomatch.com> writes:
>
> > Alain Picard <·······@optushome.com.au> writes:
> > <snip>
> > On big projects where *everything* needs to be tracked, your diagrams are
> > viewed by hundreds of people, your diagrams need tool support to verify,
> > etc.
> >
> > E.g. air traffic control projects.
> >
>
> I believe you are correct. I think on those very large system,
> the cost of producing quality software scales almost exponentially
> with the size of the problem (and development effort). A colleague
> worked on control systems for the F16 aircraft agrees that that
> software ends up costing $10,000 per line of code.
>
> Such tools probably _can_ help in those situations. I guess I'm
> not saying they're utterly useless; I'm saying they imply a world
> in which I have no wish to live. I'll stick with Lisp and small
> teams for as long as I can, and work on making small teams more
> productive (and able to tackle larger projects through higher
> productivity) instead. I've found many of the methods used by
> XP useful in this regards. But I wouldn't want my team responsible
> for an air traffic or nuclear power plant control system...
>
Here's an article on how NASA gets _one_ error in 420,000 LOC on each of the
last three releases of the shuttle SW. They seem to have spent more on the
order of $3000/LOC (WAG!); their budget is 35M$ per year, very small compared
to the program. They produce about 10 LOC per page of specification.
http://www.fastcompany.com/online/06/writestuff.html
KBK
Alain Picard <·······@optushome.com.au> writes:
> Does _anybody_ here actually think UML like tools are _useful_? If
> so, how?
I personally believe tools like Rational Rose can be damaging if not
used correctly. They can slow development down, constrain the design
such that it fits into the limitations of the tool or UML and endless
hours are spent working around problems with code generation/reverse
engineering. I haven't really worked for a company that has honestly
made effective use of Rose. It is used but it provides little benefit
to the development process other than giving something to the auditors
when they ask for documentation and don't wish to accept hand written
notes or prototype/code as documentation.
I couldn't imagine using these tools for Lisp development without
destroying any chance of getting the productivity gains of Lisp.
Then again, Rational Rose data files seem to be s-expression
based. Write a lisp program to generate your UML models by producing
these data files. Or use the OLE AUtomation interface exposed by Rose
to generate the diagrams from Lisp. Probably work better than their
reverse engineering options anyway...
Rational used to have a tool (might still do) called Soda that
analysed Rose models and generated word reports base on templates. It
was written (I think) in word basic, or VBA, or something, and was
a tad flaky. I wonder if they used Rose to design it. Or if they use
Rose to design Rose.
One way for Lisp to succeed in the Rational universe is for a Lisp app
that uses Ole Automation to analyse rose models and spit out some
decent documentation/reports. Or rewrites the system all in Lisp ;-)
That said, I have had good success with Rose as a diagraming tool - no
code generation, no Rational Unified Process support. Just quick
pictures of the design to use in supporting documents - mainly because
my hand drawings, well, suck.
Anyway, enough ranting from me...you can tell I've been locked in a
Rational Rose/c++ development world for too long lately by the length
of this post.
Chris.
--
http://www.double.co.nz/cl
> I personally believe tools like Rational Rose can be damaging if not
> used correctly. They can slow development down, constrain the design
> such that it fits into the limitations of the tool or UML and endless
> hours are spent working around problems with code generation/reverse
> engineering. I haven't really worked for a company that has honestly
> made effective use of Rose. It is used but it provides little benefit
> to the development process other than giving something to the auditors
> when they ask for documentation and don't wish to accept hand written
> notes or prototype/code as documentation.
A group nearby our lab made a huge investment in Rational Rose
Realtime with a view towards using it as The Development Environment,
and are running into huge problems; pretty much the typical thing,
poor/erratic support from RR, very few people who have done
complicated stuff, a couple somewhat misleading promises made by RR
salespeople.
We went thru their (very expensive, convientently vague) training
class, and the code generation features ook interesting, but I think
are only loosely suited to for really realtime work. The state
machine stuff seems pretty reasonable, but any user code in the state
transitions themselves will cause the Rational Realtime clock to slip,
and varying paths thru the user code will probably cause jitter as
well. Another issue relates to interfacing RR to other systems, it
wants to own everything around it- and its not entirely clear how a RR
program can be integrated as a subsystem that plays nice with
everything else. I think its also an oversimplification to force a
choice of either making all code a state machine or putting it outside
Rose's documentation domain.
>
> That said, I have had good success with Rose as a diagraming tool - no
> code generation, no Rational Unified Process support. Just quick
> pictures of the design to use in supporting documents - mainly because
> my hand drawings, well, suck.
I agree, I think it would make a great documentation tool; but not so
greate as development platform.
Gregm
Chris Double <·····@double.co.nz> writes:
> Then again, Rational Rose data files seem to be s-expression
> based. Write a lisp program to generate your UML models by producing
> these data files.
I wouldn't do this. The data file format has a tendency to change from release
to release.
> Or use the OLE AUtomation interface exposed by Rose to generate the diagrams
> from Lisp. Probably work better than their reverse engineering options
> anyway...
A much more stable way of programmatically talking to Rose.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@infomatch.com The Rhythm has my soul.
Chris Double <·····@double.co.nz> wrote:
: Then again, Rational Rose data files seem to be s-expression
: based. Write a lisp program to generate your UML models by producing
: these data files. Or use the OLE AUtomation interface exposed by Rose
: to generate the diagrams from Lisp. Probably work better than their
: reverse engineering options anyway...
A colleague did that to produce his private CLOS extension classes and
methods, unfortunately not CLOS compatible (autolisp). It was quite useful,
esp for co-workers to get an immediate outline of the classes and for fast
prototyping.
--
Reini Urban
http://xarch.tu-graz.ac.at/acadwiki/AutoLispFaq
Alain Picard wrote:
> Seriously -- why would you want to do this? Are you trapped
> in hell (i.e. real life) and need this to justify something
> to a pointy haired boss? (I'm not being sarcastic -- that's
> the best reason I can think of.)
>
> Long long ago, in a galaxy far far away, I did the whole Rational Rose
> thing. Put pictures in the repository, shared them with co-workers,
> coded C++ to those interfaces, the lot. Now I think only quickly
> drawn pictures, _in pencil_, in no `formal' pictorial language, are
> useful, to communicate to others (and my future self) what something
> was about. For the rest, "the source code is the design", aided, if
> need be, by a 1-2 page technical memo.
>
> Does _anybody_ here actually think UML like tools are _useful_?
> If so, how?
>
Is this the counsel of despair, the wisdom of experience, or the glorification of the inadequate?
I, too, have tried these things at various points of my career and have also found them wanting.
However, if we computer scientists want to be taken seriously as an engineering discipline, we're going to have to find a way to move beyond "the code
is the design" supplemented (if at all) by a few cave paintings that tend to get tossed in the trash by mistake sometime within the first five years
of the code's working life.
No civil engineer would say "the bridge is the design" and tell you (and often distainfully at that) to reconstruct its design girder by girder.
I've seen the other side of it. When I worked in a University many years ago, as a starving student, I ended up with the only surviving documentation
of an important business process I slightly upgraded for them. It somehow disappeared. I was sure I had returned it, but no matter. It was gone.
Over the next ten years, I got occassional letters begging me to look through my possessions to see if I had somehow, accidentally, retained it. Even
though I had, in fact, diligently searched for it twice before I ceased doing so.
Clearly, "the code is the design" was a miserable failure; problems recurred often enough that they wished for that original design doc.
Perhaps for LISP "the code is the design" works, but for COBOL, C, C++, APL, FORTRAN, and other languages I could name, it has been a miserable
failure in my experience of it. At the least, reconstruction from "the code is the design" is not the most productive exercise. At worst, no one has
a real understanding of what the code really does, or one lousy maintainer with a poor understanding wrecks the true intent beyond recognition and it
thereafter survives by kludges, guesses, and patches.
I don't know how to fix this, but after heaping whatever justified scorn on the current tools we care to make, someone, somewhere I hope will be
inspired with a useful and correct answer to this problem.
Larry
Larry Loen <······@rchland.vnet.ibm.com> writes:
> However, if we computer scientists want to be taken seriously as an
> engineering discipline, we're going to have to find a way to move
> beyond "the code is the design" supplemented (if at all) by a few cave
> paintings that tend to get tossed in the trash by mistake sometime
> within the first five years of the code's working life.
>
I'm not sure I want whatever it is I do to "be taken seriously as an
engineering discipline". That's not to say I don't want whatever it
is I do to be taken seriously.
I think terms "software engineer" and "software engineering" are
_dangerous_. What I mean by that is; they are a metaphor, and, as
all metaphors, they may direct your thinking along certain lines and
blind you from reality.
I read in Gabriel's book "Patterns of Software" a passage where he
uses a different metaphor for software: that of a plant, (or a
garden). The point is that the software is viewed as organic, alive,
with a mind of its own. Sure, you "design" your garden, arrange the
plants initially, water them, tend them, but, ultimately, some thrive
and some don't. Your job is to accommodate them. If you succeed, you
end up with a garden which is extremely beautiful, but has only a
passing relationship with what your original "design", though it may
indeed fulfill your original intent.
> No civil engineer would say "the bridge is the design" and tell you
> (and often distainfully at that) to reconstruct its design girder by
> girder.
No civil engineer would be told by their customer "Sorry mate, we just
moved the far bank back 50 metre, you don't mind, patching that up, do
you?" when the bridge is 90% complete. This happens to me in my work
all the time. I accommodate such requests.
How can this be so? Clearly, because software artifacts are
altogether different from engineering artifacts.
If we used the metaphor "Software Authoring", well, the request might be:
"Mind adding a few more chapters, or changing the ending?".
This would be much more in line with what we actually do.
Management types love the engineering metaphor, of course, because
they need to be able to draw up budgets, schedules, etc. Ask an
editor how he schedules his authors to deliver books on time...
>
> [Tale of woe and lost document snipped]
>
If we're going to be "taken seriously", as engineers or on our
own merits, we'll have to do better than that. Our profession,
craft, whatever you wish to call it, is very young. Most of what
we do is lousy. How many software masterpieces do you know about?
How many of us have written one? I sure haven't.
Apologies for ranting, but I think this engineering metaphor is _so_
destructive. I've done the big up-front design bit. Guess what --
all those documents we sweated over for months became obsolete the
moment we started coding. I don't think it's because we were
incompetent---I think it's _inherent_ in what we do that it entails
many small decisions, which have to be taken during the lifetime of
the process. So, when we actually had to fix or change something
months later, did we go to these documents?� Of course not---we went
to the source code. And guess what: it sucked, because it was all
supposedly documented "elsewhere". I would have _much_ preferred a
1/2 page memo about the central ideas of a given subsystem, (the
_why_), and well written and commented code to tell me the _how_.
�Well, some na�ve people, like myself, did look up these documents
first, only to discover how useless they were in the face of harsh
reality.
--
It would be difficult to construe Larry Wall, in article
this as a feature. <·····················@netlabs.com>
Alain Picard wrote:
> If we used the metaphor "Software Authoring", well, the request might be:
> "Mind adding a few more chapters, or changing the ending?".
> This would be much more in line with what we actually do.
Yes - this is a much better metaphor than the ridiculous "Software
Engineering" metaphor. Is this notion actually used somewhere? It sounds
familiar to me but I cannot remember hearing it anywhere else...
>
> Management types love the engineering metaphor, of course, because
> they need to be able to draw up budgets, schedules, etc. Ask an
> editor how he schedules his authors to deliver books on time...
That's exactly the fact!
ciao,
Jochen
"Jochen Schmidt" <···@dataheaven.de> wrote in message
···················@ID-22205.news.dfncis.de...
> Alain Picard wrote:
>
> > If we used the metaphor "Software Authoring", well, the request might
be:
> > "Mind adding a few more chapters, or changing the ending?".
> > This would be much more in line with what we actually do.
>
> Yes - this is a much better metaphor than the ridiculous "Software
> Engineering" metaphor. Is this notion actually used somewhere? It sounds
> familiar to me but I cannot remember hearing it anywhere else...
>
You're probably thinking of Knuth's "Literate Programming" (not necessarily
a model that I'd espouse). I do know that my first requirement, when I look
for a software engineer, is the ability to put two (or more) sentences
together in a natural language. Being able to write in an organized manner
tells me that they'll probably be able to write code in the same.
I do know at least two very experienced programmers who have told me that
they think of writing a program as "telling a story" to the computer and
other programmers. It's always made sense to me.
> > Management types love the engineering metaphor, of course, because
> > they need to be able to draw up budgets, schedules, etc. Ask an
> > editor how he schedules his authors to deliver books on time...
>
> That's exactly the fact!
And the sad part is that anyone who's ever worked on a major project can
tell you just as many horror stories about cost overruns, schedule
slippages, etc. (as can anyone who's ever remodeled a house). I'm beginning
to think that, outside the idea of trying to gather and meet some set of
user requirements, there is no such thing as engineering. There's really
only more or less formalized hacking. Engineering is a myth we tell each
other (and customers) to give everyone the courage to persevere through a
project that is frought with more imponderables than certainties.
faa
"Frank A. Adrian" <·······@uswest.net> writes:
> You're probably thinking of Knuth's "Literate Programming" (not necessarily
> a model that I'd espouse). I do know that my first requirement, when I look
> for a software engineer, is the ability to put two (or more) sentences
> together in a natural language. Being able to write in an organized manner
> tells me that they'll probably be able to write code in the same.
I've not read Knuth's book, but it sounds interesting. I suppose I'll add
it to my "someday" list...
> I do know at least two very experienced programmers who have told me that
> they think of writing a program as "telling a story" to the computer and
> other programmers. It's always made sense to me.
Not only do I believe this, but as someone who sometimes writes
fiction I'm astounded by the impoverished state of tools for
story-writing. I think the fiction writing community could and should
use the nearly identical kinds of tools that programmers do, modified
to suit their domain, of course.
However, while drag-and-drop tools for writing and analysis tools for
assessing story structure/coherency/modularization, etc. might be useful
to the writer, in the end, I think the good writers (in either domain)
are not the ones who need these tools in order to write; they are the ones
who need these tools in order to write more efficiently. Some people
confuse those two concepts.
Drag and drop tends to "box one in" (to abuse a metaphor), because it will
tend to produce the set of things that are spatially nearby. A good fiction
writer, like a good programmer, knows when to use that spatial convenience
and when to complain that things are in the wrong place and to back off to
the use of longhand to express the idea that was there in their head
in any case.
I think the modern tendancy is to assume that the function of drag and drop
is not that, however, but rather it is an assertion that a million monkeys,
given such interfaces instead of typewriters, would produce something of
more sophisticated quality than they would with those million typewriters.
And I'm not so sure that's true.
> > > Management types love the engineering metaphor, of course, because
> > > they need to be able to draw up budgets, schedules, etc. Ask an
> > > editor how he schedules his authors to deliver books on time...
> >
> > That's exactly the fact!
>
> And the sad part is that anyone who's ever worked on a major project can
> tell you just as many horror stories about cost overruns, schedule
> slippages, etc. (as can anyone who's ever remodeled a house). I'm beginning
> to think that, outside the idea of trying to gather and meet some set of
> user requirements, there is no such thing as engineering. There's really
> only more or less formalized hacking. Engineering is a myth we tell each
> other (and customers) to give everyone the courage to persevere through a
> project that is frought with more imponderables than certainties.
In my experience, engineering project schedules divides itself into two parts:
(a) Things they ask you to do that you've done before. For example,
you're building a bridge for the Army or a set for your local
theatre or a chair for your dining room table. You've built one
before. You're trained to do it, so the activity is repeatable
and even something you maybe get better at through practice
effects. Time/Cost projection is therefore a memory exercise.
Building a new house falls into this category because you can level
the foundation and then work from a predictable state.
(b) Things they ask y ou to do that you've never done before. I call
this "research". To the extent I can make an isomorphism to
something that is similar, I try to project cost by analogy, and
sometimes that gets me close. Sometimes it's something that's so
obvious an extension of what I've done before that I can feel
comfortable guessing. Sometimes it's something where you have
someone who's done it as a resource to draw on. But beyond those
lucky cases, for the most, I think it's often a total guess how
long it's going to be. One allocates big chunks of time for the
forseeable obstacles, for the assumption you won't forsee all
obstacles, and for any belief that there might be big problems you
haven't anticipated. I think it's a good plan, where it can be
done, to allocate time to "research a space" with NO expectations
of time schedule before proceeding into it and before making any
external claims of its tractibility. If you fail to factor out
the research, you know it's not going away--it's jsut intertwined
within the engineering space, making all the estimates that could
have been done accurately less accurate.
Remodeling a new house, which I'm doing now, falls into this
category because though the person doing it may be skilled in each
of the required component activities, but they have still never done
your personal house.
I've heard it said you shouuld never take on risk without
corresponding pay. I think a corollary in engineering is that you
should never take on "research" without an acknowledgement of the
associated schedule risk. It bugs some managers when you call it
research because they want to define it, and the associated risk,
away. But so be it. The risk can't be defined away and better you
have a nice on-the-record argument on this BEFORE you go into it that
you can point back to later, than one that just arises out of the blue
because you didn't make a clear enough point about it early enough.
On Sun, 17 Jun 2001 00:41:42 +0200, Jochen Schmidt <···@dataheaven.de>
wrote:
>Alain Picard wrote:
>
>> If we used the metaphor "Software Authoring", well, the request might be:
>> "Mind adding a few more chapters, or changing the ending?".
>> This would be much more in line with what we actually do.
>
>Yes - this is a much better metaphor than the ridiculous "Software
>Engineering" metaphor. Is this notion actually used somewhere? It sounds
>familiar to me but I cannot remember hearing it anywhere else...
I think it is an analogy that is gaining ground. Knuth's "Literate
Programming" is only an initial step -- that still clings rather too
closely in my opinion to the notion of computing as a species of
mathematics. Knuth Literate Programs are like mathematics texts; an
informal mode exposition wrapped around formal statements of proof. In
this case the program code takes the place of a lemma.
I prefer to think of programming as a _rhetorike techne_ -- an art of
rhetoric -- that is a recognition of the power (and attendant dangers)
of literacy and consequently the necessity to acquire both a
practitioner's skill and the aficionado�s critical faculty. Jacqueline
de Romilly has written that the Sophists seemed as essential to
fifth-century Athens as physicists in our atomic age. [le grands
Sohistes dans l�Ath�nes de P�ricl�s 1988]. Well, I would argue that
computing will be even more central to the science of the present
century than it was to physics in the last.
As was public speaking in Ancient Athens, so with the art of
programming. One hopeful benefit of greater public disclosure of code
(whether, 'free', 'open source' or software libre.) is that it may
encourage more public awareness and engagement with this essential
craft of software creation.
Not that the 'software engineering' approach will entirely go away of
course, there will be armies of hack coders in software factories,
just as there are similar opportunities for writers in the popular
press and Hollywood studios: but we should not confuse that with true
art.
--
David Clark
<http://www.orditur-telas.com/>
From: Tim Bradshaw
Subject: Re: Engineering Envy [was: Re: CL and UML]
Date:
Message-ID: <ey3ithukbbp.fsf@cley.com>
* Jochen Schmidt wrote:
> Alain Picard wrote:
>> If we used the metaphor "Software Authoring", well, the request
>> might be: "Mind adding a few more chapters, or changing the
>> ending?". This would be much more in line with what we actually
>> do.
> Yes - this is a much better metaphor than the ridiculous "Software
> Engineering" metaphor. Is this notion actually used somewhere? It
> sounds familiar to me but I cannot remember hearing it anywhere
> else...
I agree that it's a better metaphor, but I think it's better because
we're living in a pre-scientific age as far as software production
goes. There's good reason to beleive that creative writing is not
something that you want to make scientific, but I think that, in the
case of software, it definitely is something that needs more hard
science.
In the same way I want a good deal of confidence that the wings will
not fall off a plane I'm flying in, I want a good deal of confidence
that the control system won't suddenly decide that vertically
downwards is the right way to fly. Mechanical engineering has made
enormous strides in this direction - anyone who thinks otherwise
should look at the kind of seat-of-the-pants awfulness that was the
rule in the 18th and much of the 19th centuries: things just blew up
or fell to bits sometimes, and that was just how it was. Software
development needs to make huge strides too, although I don't think
anyone has a clue how to do this (don't start telling me about formal
proofs of programs or some crap like that: no one is proving aircraft
wing designs formally).
In the meantime I think it would be better to admit that we're doing
magic, and treat us as magicians...
--tim
Tim Bradshaw <···@cley.com> writes:
> I agree that it's a better metaphor, but I think it's better because
> we're living in a pre-scientific age as far as software production
> goes. There's good reason to beleive that creative writing is not
> something that you want to make scientific, but I think that, in the
> case of software, it definitely is something that needs more hard
> science.
Astoundingly well put. Bravo.
It does lead us, however, to the next question: to what extent
is it _possible_ to make softwaremore scientific (or, more like
engineering, if you prefer).
The NASA guys who wrote that shuttle software are obviously at the
extreme end of "engineericity", and the XP folks are at the other
end, let's call it the "craftsmanship" end. The third category
are cowboy coders, who don't study their own processes at all.
There's not doubt the NASA guys do a better job than the XP guys.
There's also no doubt that it's prohibitively expensive.
Evidence also suggest most commercial software is being developed
by the third category. :-)
Perhaps the real question is: can we make it economically feasible to
infuse our craft with science? What if, for instance, software came
with actual warranties? If the companies were liable for damages?
The software for pace-makers is of pretty darn high quality, after all.
>
> In the meantime I think it would be better to admit that we're doing
> magic, and treat us as magicians...
>
Yeah. As in: I'm Mickey Mouse in the sorcerer's apprentice. :-)
Or maybe rather we're alchemists: madly _trying_ to do scientific
things, but lacking the correct theoretical underpinning for our
work, it's just hocus pocus and doomed to failure, until the right
theories come along. People _can_ transmutate elements, now, after all.
Seriously though, the magician image is one of those lovely romantic
notions that I'd defend over a beer, after work, but which wouldn't go
far with my manager during a scheduling meeting (and rightly so).
Someone posted here a while back that all lispers were "Artists and
Philosophers": he should perhaps have added "magicians". I (half-heartedly)
tried to argue the other side to him, but he may well have been right.
--
It would be difficult to construe Larry Wall, in article
this as a feature. <·····················@netlabs.com>
From: Tim Bradshaw
Subject: Re: Engineering Envy [was: Re: CL and UML]
Date:
Message-ID: <nkj1yoikqjn.fsf@tfeb.org>
Alain Picard <·······@optushome.com.au> writes:
>
> It does lead us, however, to the next question: to what extent
> is it _possible_ to make softwaremore scientific (or, more like
> engineering, if you prefer).
I think it's clear that engineering is the right thing to go for. In
my world, science is asking questions like `does this set of equations
model the world?', and it doesn't really matter if it's very expensive
to establish that or anything, so long as it is possible to test the
hypothesis. Engineering is to do with questions like `can we do this
thing for this much cost?' where `this thing' is something like `build
a bridge' or `land a man on the moon'. Engineering is all about costs
and utility and things like that, and so, generally, is software. You
*need* science to do engineering, but engineering is not science.
>
> The NASA guys who wrote that shuttle software are obviously at the
> extreme end of "engineericity", and the XP folks are at the other
> end, let's call it the "craftsmanship" end. The third category
> are cowboy coders, who don't study their own processes at all.
>
> There's not doubt the NASA guys do a better job than the XP guys.
> There's also no doubt that it's prohibitively expensive.
> Evidence also suggest most commercial software is being developed
> by the third category. :-)
Well, by my above definition I'm not sure they do: they produce
something which is, I suppose, higher quality, but at a cost which
would be completely prohibitive for most projects. Of course running
a shuttle is not `most projects', so their approach might well be
appropriate for it.
I think that the thing that is missing from software is some
well-defined notion of risk. We write systems which are terribly
brittle in all sorts of ways: tiny errors can result in massive
failure. There's no useful continuous-in-the-limit map from changes
to the system to changes in behaviour - a tiny change can be a tiny
error which can induce catastrophic failure. Similarly systems are
brittle to their environment changing - if an input overflows an
arbitrary bound by an amount ever so tiny the system wraps, and the
output changes enormously. It's almost impossible to do engineering
with a system like this because it has such terrible characteristics.
Successful engineering structures don't look like this: if they get
slightly too stressed they have shorter lives; they wear out
gradually; parts fail without causing the whole to fail and so on.
I don't really have any good idea about how software could be made
more amenable to engineering. Clearly Lisp (& similar languages) have
some good ideas - it's hard in Lisp to have a tiny error trash random
memory, or to have a numerical overflow cause massive failure because
of wraparound. But these aren't really solving much of the problem, I
think.
--tim
Tim Bradshaw <···@tfeb.org> writes:
> Successful engineering structures don't look like this: if they get
> slightly too stressed they have shorter lives; they wear out
> gradually; parts fail without causing the whole to fail and so on.
But there are many cases where physical engineered systems do not follow
this description. Bridge resonance is one spectacular example of a
failure that in some ways mimics a lot of software failures.
Now one response to that observation is that bridge designers have since
learned that this is a particular problem that needs to be addressed in
the design phase. In a similar vein, experienced software designers
know enough to do sanity checks on input values to make sure that the
assumptions of the following code are being met. This is largely a
matter of design methodology rather than something the language itself
requires, but the same is true of resonance analysis of bridges (except
that the requirement may be more formally codified for bridges).
There are, however, some inherent problems in (a lot of) programming
language design. The silent rollover of integer arithmetic is one of my
least favorite (non-Lisp) language failure. It is too bad that Java
followed the standard route of those languages. I think it would have
been nicer (and certainly more upfront and obvious) to name the type for
which this occurs something like "intMod32" instead of "int" and reserve
the latter for a type which throws exceptions on overflow or underflow.
It would presumably be a bit slower, but having both of these options
would at least make the issue more visible, and give the programmer a
chance at making the speed/risk tradeoff.
I suppose another way that traditional engineering differs from software
writing is that one generally has a good idea of how to make something
stronger, and how to introduce redundancy. It isn't clear how to make a
program stronger (in the sense of less likely to break in a way that is
moderately independent of a careful analysis of the precise mechanism
which will cause it to break). Also, there is precious little language
support for any type of redundant coding styles -- such as voting.
I suppose that part of the problem is that much of the traditional
engineering techniques are designed to deal with the problem of physical
failure of the parts. This is something that normally isn't an issue in
software (although bit rot or hardware errors can occur which affect
software). In any case, it is generally solved by the same redudant
systems approach of traditional engineering -- fail-over systems,
duplicate databases, etc.
Most software failures probably correspond more to things that would be
design failures in traditional engineering. Obviously such things still
happen -- witness certain automotive safety problems and recalls -- but
they seem to be not quite as common. One reason may be that the designs
of most engineered structures are either not as complicated (although,
aircraft may be a counter example) and they are also not as
interdependent, so that a failure in the lavatory of an airliner doesn't
cause the aircraft to fall out of the sky.
Perhaps some (future) development of the agent architecture will allow
more de-coupling of software and reduce the degree of interdependence of
software. The most embarrassing thing about software failures is how
small mistakes in non-mission critical sections of the software can take
down the entire system.
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu
On 18 Jun 2001 10:10:46 -0700, ···@sevak.isi.edu (Thomas A. Russ) wrote:
>Tim Bradshaw <···@tfeb.org> writes:
>
>> Successful engineering structures don't look like this: if they get
>> slightly too stressed they have shorter lives; they wear out
>> gradually; parts fail without causing the whole to fail and so on.
>
>But there are many cases where physical engineered systems do not follow
>this description. Bridge resonance is one spectacular example of a
>failure that in some ways mimics a lot of software failures.
>
>Now one response to that observation is that bridge designers have since
>learned that this is a particular problem that needs to be addressed in
>the design phase. In a similar vein, experienced software designers
>know enough to do sanity checks on input values to make sure that the
>assumptions of the following code are being met. This is largely a
>matter of design methodology rather than something the language itself
>requires, but the same is true of resonance analysis of bridges (except
>that the requirement may be more formally codified for bridges).
Another example is the introduction of welding in shipbuilding in the 30's. A
number of ship hulls cracked severely, and one even split in two while at
harbour. When it was discovered ... . I now correct myself, to stress what I
am getting at.
When _people_ discovered that the welding process caused brittleness in the
steel surrounding the weld, measures were taken. The process was modified -
excuse, I mean that people modified the process, new welding methods were
introduced (read: teachers held courses, experienced welders often had
apprentices etc).
Authorities - no, I mean _people_ employed by various agencies - required
inspection of constructions, eg by X-ray. And so on.
>There are, however, some inherent problems in (a lot of) programming
>language design. The silent rollover of integer arithmetic is one of my
>least favorite (non-Lisp) language failure. It is too bad that Java
>followed the standard route of those languages. I think it would have
>been nicer (and certainly more upfront and obvious) to name the type for
>which this occurs something like "intMod32" instead of "int" and reserve
>the latter for a type which throws exceptions on overflow or underflow.
>It would presumably be a bit slower, but having both of these options
>would at least make the issue more visible, and give the programmer a
>chance at making the speed/risk tradeoff.
>
>I suppose another way that traditional engineering differs from software
>writing is that one generally has a good idea of how to make something
>stronger, and how to introduce redundancy. It isn't clear how to make a
>program stronger (in the sense of less likely to break in a way that is
>moderately independent of a careful analysis of the precise mechanism
>which will cause it to break). Also, there is precious little language
>support for any type of redundant coding styles -- such as voting.
I'd say that your previous paragraph suggests one way of building robustness
into code (integer overflow).
Then why do not programmers use these and other techniques? Is it because
they are unaware of the need, have they done a cost analysis or are they just
lazy and think they can (hopefully) get away with it?
>I suppose that part of the problem is that much of the traditional
>engineering techniques are designed to deal with the problem of physical
>failure of the parts. This is something that normally isn't an issue in
>software (although bit rot or hardware errors can occur which affect
>software). In any case, it is generally solved by the same redudant
>systems approach of traditional engineering -- fail-over systems,
>duplicate databases, etc.
>
>Most software failures probably correspond more to things that would be
>design failures in traditional engineering. Obviously such things still
>happen -- witness certain automotive safety problems and recalls -- but
>they seem to be not quite as common. One reason may be that the designs
>of most engineered structures are either not as complicated (although,
>aircraft may be a counter example) and they are also not as
>interdependent, so that a failure in the lavatory of an airliner doesn't
>cause the aircraft to fall out of the sky.
The most complicated machine is probably a large phone network. Consider the
number of users, the variety and levels of the equipment, in the case of
mobile systems that all terminals move physically and must be tracked, the
services available that must be billed to someone - and all this happens in
real time.
>Perhaps some (future) development of the agent architecture will allow
>more de-coupling of software and reduce the degree of interdependence of
>software. The most embarrassing thing about software failures is how
>small mistakes in non-mission critical sections of the software can take
>down the entire system.
I'd say that software design methodology, for many application domains, is
reasonably well known. But compare the efforts put into building a successful
hockey, football, etc team with the resources used to build a project team
where the people are to design and implement a large, complex and sometimes
_very_ expensive piece of software.
Few responsible manufacturing plant managers would allow ad-hoc design and
implemention of new control systems, simply from bad experience and from not
daring to risk the concequences. Any manager or leader should today _know_
how to start and run a software project, how to write specs and deal with
documentation in the project stages.
Isn't then an embarrassing thing that software is discussed in terms as if
software happens all by itself? Alain quoted Gabriel about software as plant/
garden. Now, a farmer knows how to prepare his fields, and any seasoned
gardener knows how to plant so as _not_ to get weeds in it.
So, do educational institutions (read: people) teach how to build and run
software projects? Assuming that the technique is known of course ...
/Lars
Lars Lundback wrote:
>
[snip]
> >There are, however, some inherent problems in (a lot of) programming
> >language design. The silent rollover of integer arithmetic is one of my
> >least favorite (non-Lisp) language failure. It is too bad that Java
> >followed the standard route of those languages. I think it would have
> >been nicer (and certainly more upfront and obvious) to name the type for
> >which this occurs something like "intMod32" instead of "int" and reserve
> >the latter for a type which throws exceptions on overflow or underflow.
> >It would presumably be a bit slower, but having both of these options
> >would at least make the issue more visible, and give the programmer a
> >chance at making the speed/risk tradeoff.
> >
> >I suppose another way [is voting]
[snip]
>
> I'd say that your previous paragraph suggests one way of building robustness
> into code (integer overflow).
>
> Then why do not programmers use these and other techniques? Is it because
> they are unaware of the need, have they done a cost analysis or are they just
> lazy and think they can (hopefully) get away with it?
>
No, it is trickier than that. Exceptions are not always a good thing to generate. In a surprising number of cases, one can ignore
what (at the micro level) are very catestrophic looking failures somewhere above in the calling sequence. For instance, voting between
three different algorithms is a much higher level way of dealing with this sort of thing and could usually or even typically allow
micro level integer overflows to be successfully ignored. It might also reduce the code volume compared to a single algorithm
instrumented with exceptions to within an inch of its life. This last point is, after all, at the root of many problems in software
"engineering". Economy of code authorship is always the mitigating factor. Otherwise, we'd all write all code to the standards of
manned space flight (something that so far no one is willing to pay for, including individuals just wanting to, say, learn LISP).
Overall, Java introduces more exception formalism into its language than any I know of. It is yet to be seen if this is a true
advantage, but I do like the fact that they recognize very explicitly in their architecture that signalling exceptions is not an
unconditional benefit.
Larry
In article <···············@tfeb.org>, Tim Bradshaw <···@tfeb.org> wrote:
>I think that the thing that is missing from software is some
>well-defined notion of risk. We write systems which are terribly
>brittle in all sorts of ways: tiny errors can result in massive
>failure. There's no useful continuous-in-the-limit map from changes
>to the system to changes in behaviour - a tiny change can be a tiny
>error which can induce catastrophic failure. Similarly systems are
>brittle to their environment changing - if an input overflows an
>arbitrary bound by an amount ever so tiny the system wraps, and the
>output changes enormously. It's almost impossible to do engineering
>with a system like this because it has such terrible characteristics.
>
>Successful engineering structures don't look like this: if they get
>slightly too stressed they have shorter lives; they wear out
>gradually; parts fail without causing the whole to fail and so on.
>
>I don't really have any good idea about how software could be made
>more amenable to engineering. Clearly Lisp (& similar languages) have
>some good ideas - it's hard in Lisp to have a tiny error trash random
>memory, or to have a numerical overflow cause massive failure because
>of wraparound. But these aren't really solving much of the problem, I
>think.
If you look, say, at mechanical engineering, one of their big wins is that
for the most part they use an extraordinarily limited vocabularly of
components, put together in a relatively small number of ways. All of
the above pretty exhaustively tested (there are people out there who
do nothing but break bolts, rivets or welds all day, every day). Stepping
outside that limited vocabulary increases cost by an enormous factor
(10x or more) and is generally understood to carry with it large and largely
uncertain risks. (DC-10, Hyatt Regency KC, and so forth).
So most buildings, cars, airplanes, chairs, tables and so forth don't
use anything like the "state of the art" in materials or construction
techniques. If you want something handcrafted, people will tell you
it can't be done, or they'll tell you a price tag that makes you go away.
Every once in a while, and slowly, the state of construction practice
changes.
Programmers (or their managers, rather) seem perfectly willing to
handcraft new toys out of untested components, put together
in extraordinarily complex, also untested combinations, and then
hang the lives of businesses or people on the correct functioning
of same.
One possibility is that Moore's Law will save us: stuff that needs to
work will run on enormously fast machines and consist of big chunks
of studgy, "inefficient," _bulletproof_ . The functionality available
will be limited, but it will be guaranteed (the really annoying thing
with software today is that giving up function doesn't buy you extra
robustness, except by coincidence). And all of the stuff that doesn't
have to work will still be written by artists.
paul
Paul Wallich wrote:
[snip excellent summary of how mechanical engineering works]
> Programmers (or their managers, rather) seem perfectly willing to
> handcraft new toys out of untested components, put together
> in extraordinarily complex, also untested combinations, and then
> hang the lives of businesses or people on the correct functioning
> of same.
>
Quite true.
> One possibility is that Moore's Law will save us: stuff that needs to
> work will run on enormously fast machines and consist of big chunks
> of studgy, "inefficient," _bulletproof_ . The functionality available
> will be limited, but it will be guaranteed (the really annoying thing
> with software today is that giving up function doesn't buy you extra
> robustness, except by coincidence). And all of the stuff that doesn't
> have to work will still be written by artists.
>
> paul
Oh, how I'd love to agree with you. But, a major issue is the robustness of the Halting Problem and its ally, the Debugging Problem.
There was an initiative I once worked with (as a "client" of the vendor) to see if we could use proof of correctness concepts to at
least informally and manually reduce or eliminate errors. You would do things like break down do loops to various assertions and so on
and manually work these through to "prove" the program didn't have bugs using things like set theory and predicate calculus.
It was a very ambitious effort to bring at least an informal "proof of programming correctness" to reviewed code and design without the
(as yet) unsolved complexity of doing this with a computer.
But, as much as I wanted it to work, I found what I believed to be a serious difficulty. Namely, invoking "superset" function.
Whether I could defend it as a thesis, I don't know, but my reasoning worked like this:
1. Suppose, in the course of a program, you needed to take the sine of a positive number.
2. Sensibly enough, you invoked a general sine routine that takes either positive or negative inputs.
3. Sensible and routine as that is, I convinced myself that the ability to validate the program (especially "defensively" in the sense
of dealing with bad input) basically introduced the Halting Problem into the analysis. Thus, the method, which might have practical
benefit, could not be used to generate the magical and so far mythical subset of "provably correct, useful programs" which is what the
MEs have to build things safely as you described.
In other words, if you invoke a program that can do more than you require to be done, then while you save money (code reuse, whether
C++ or an ordinary math library) you greatly multiply the complexity of verifying the correctness.
My hazy memory says that I doubt of this technology was really asserting it could create this "provably correct, useful program" set,
but it seemed to think it was coming closer, much closer. Because of the Halting Problem issue I uncovered, I had my doubts and, as it
happens, I don't know of anyone using such technology today.
Larry
Alain Picard wrote:
> Perhaps the real question is: can we make it economically feasible to
> infuse our craft with science? What if, for instance, software came
> with actual warranties? If the companies were liable for damages?
> The software for pace-makers is of pretty darn high quality, after all.
Well, if we can't find the so-far mythical "usable, but provably correct" subset of all programs, then I'll have to agree with you. We'll review and
test the heck out of pacemaker code and then warranty it. (In that particular case, ordinary tort liability probably already provides a warranty).
However, I would be more than academically interested if we could produce, regularly and knowingly, programs that are members of "the set of provably
correct, but useful programs" which has so far eluded all our best minds. How much that would cost would become a secondary question. It might even
be prone to a kind of economic bootstrapping; once you have provable correct programs, you could then work on making the more automated in terms of
authorship and so on and (especially when adding in the costs of bugs) would perhaps even become economic competitors to today's state of the art.
A more interesting side-effect of this, I believe, is it would give us something enigeers have that we don't. We can finally tell managers that
adding Highly Desired Feature X would blow up the code irrevocably. In other words, I think that if we knew how to write bug free code, we'd also
very likely be thereby positioned to finally be able to predict the effect of features and thus nip dangerous features in the bud or at least before
final product test. To a large extent, quality ends up being formally defined as "meeting requirements" but those turn out to be more flexible than
meet the eye -- especially if one discerns that unless you pull feature X, you're never gonna get out of final test, an experience many of us have
had. What I think correct programming technology would give us is a much earlier and cheaper window on which requirements can be met and which can't.
Larry
Tim Bradshaw wrote:
> * Jochen Schmidt wrote:
>> Alain Picard wrote:
>>> If we used the metaphor "Software Authoring", well, the request
>>> might be: "Mind adding a few more chapters, or changing the
>>> ending?". This would be much more in line with what we actually
>>> do.
>
>> Yes - this is a much better metaphor than the ridiculous "Software
>> Engineering" metaphor. Is this notion actually used somewhere? It
>> sounds familiar to me but I cannot remember hearing it anywhere
>> else...
>
>
> I agree that it's a better metaphor, but I think it's better because
> we're living in a pre-scientific age as far as software production
> goes. There's good reason to beleive that creative writing is not
> something that you want to make scientific, but I think that, in the
> case of software, it definitely is something that needs more hard
> science.
IMHO it is completely wrong to rule art as the contradiction of science.
If you take a look at composers you'll see that there's a huge amount of
math behind it. If you take authors you'll have to see that e. g.
linguistic is really "hard science". Being an artist does not mean being a
"cowboy" (using the notion as in "cowboy coder")
If you think of people like Goethe or Bach you'll see that art and science
have a *strong* relationship.
It is wrong too to mix "engineering" with "science". "Science" is about
finding _new_ things While "engineering" is more like combining old things
th right way. If we draw this picture further, this means that todays
programming has a rather big amount of "engineering" in it if the task to
be done is simply to build something that is well-understood. The
"engineering" ends if we come to topics that are not well-understood or
that may have better solutions if trying a completely other way. This means
too that there's not only "engineering" when thinking of tasks like
building aircrafts or cars. Building a conventional mainstream aircraft is
mostly "engineering". Trying to build a revolutionary new type of aircraft
goes much in the direction of art *and* science - you'll have to go ways
that simply are not allowed when working in an "engineering" scope.
ciao,
Jochen
From: Tim Bradshaw
Subject: Re: Engineering Envy [was: Re: CL and UML]
Date:
Message-ID: <ey3ithukls2.fsf@cley.com>
* Jochen Schmidt wrote:
> IMHO it is completely wrong to rule art as the contradiction of science.
Something I didn't do.
> If you take a look at composers you'll see that there's a huge amount of
> math behind it. If you take authors you'll have to see that e. g.
> linguistic is really "hard science".
Whether or not it's `hard science', very few authors know anything at
all about linguistics, or need to, any more than they need to know the
chemistry of inks.
--tim
From: Will Deakin
Subject: Re: Engineering Envy [was: Re: CL and UML]
Date:
Message-ID: <3B37022E.9000706@pindar.com>
Jochen Schmidt wrote:
> IMHO it is completely wrong to rule art as the contradiction of science.
Che?
> If you take a look at composers you'll see that there's a huge amount of
> math behind it.
But how much of that maths is maths per se, and how much of that maths is
because the human brain is wired up to enjoy regular structured change --
as opposed to random change aka white noise or not-change aka a rather
annoying hum.
Bach is good examples of a composer who were also good at maths. However,
there are examples of composers who were to a lesser or greater extent
inumerate.
:)will
Tim Bradshaw <···@cley.com> wrote:
> anyone has a clue how to do this (don't start telling me about formal
> proofs of programs or some crap like that: no one is proving aircraft
> wing designs formally).
You seriously contend that no-one uses calculations to show that
the wings of a plane will withstand a certain level of stress in various
modes and directions?
Formal methods in software engineering I can't comment on: I've
yet to write (in my frankly short career of developing software, almost
none of it professionally) a program that it was easier to design with
attention to formal methods. Not that I don't want to try.
> In the meantime I think it would be better to admit that we're doing
> magic, and treat us as magicians...
> --tim
From: Tim Bradshaw
Subject: Re: Engineering Envy [was: Re: CL and UML]
Date:
Message-ID: <ey3vglmesdq.fsf@cley.com>
* Marcin Tustin wrote:
> You seriously contend that no-one uses calculations to show that
> the wings of a plane will withstand a certain level of stress in various
> modes and directions?
Of course not. However I certainly contend that the calculations done
for mechanical engineering structures are *not* formal proofs of
correctness. Even if you aren't a mechanical engineer it's obvious
that this is so: occasionally entirely new behaviours of structures
are discovered, such as in the recent London millennium bridge
foul-up.
--tim
Tim Bradshaw <···@cley.com> writes:
> * Marcin Tustin wrote:
> > You seriously contend that no-one uses calculations to show that
> > the wings of a plane will withstand a certain level of stress in various
> > modes and directions?
>
> Of course not. However I certainly contend that the calculations done
> for mechanical engineering structures are *not* formal proofs of
> correctness. Even if you aren't a mechanical engineer it's obvious
> that this is so: occasionally entirely new behaviours of structures
> are discovered, such as in the recent London millennium bridge
> foul-up.
Moreover, calculations done on an aribtrary system are not ones I
would trust for building a plane. I'd want to know that there was
careful quality control of any system that was doing that number-crunching,
and I'd probably want to see it computed a couple of ways or cross-checked
in some way, just for security.
Jochen Schmidt wrote:
> Alain Picard wrote:
>
> > If we used the metaphor "Software Authoring", well, the request might be:
> > "Mind adding a few more chapters, or changing the ending?".
> > This would be much more in line with what we actually do.
>
> Yes - this is a much better metaphor than the ridiculous "Software
> Engineering" metaphor. Is this notion actually used somewhere? It sounds
> familiar to me but I cannot remember hearing it anywhere else...
>
Many major universities have what are called "Software Engineering" courses. The title appears in textbooks.
There are serious reasons for wanting this as an engineering discipline. Not least is that regular engineers are increasingly turning to software.
As an EE noted maybe 15 years ago to me about the software automation of computer design: "We are reducing the solved problem to the unsolved
problem."
I presume that you don't expect your software to be used to support bridge construction? Well, I do operating systems stuff for a living and I have
no idea what it might be indirectly used for. I'm sure my company's lawyers have some very good disclaimers in the terms and agreements, since we all
agree this problem is currently unsolved.
But, as a provider of code that ends up being used by who knows what application, I would like to see the state of the art improved. I don't care of
my bugs cause the odd hotel booking to go awry. I would not like to learn it caused, through some large comedy of errors, perhaps including the
application as well, that the wrong drug dosage was given. As far as I know, this sort of thing has yet to happen with me or anyone else on my
product, and we do have good, even exemplary quality by today's standards. But, the fact that I have no way to _definitively_ prevent such an
outcome, at least on my side of it, does sometimes bother my waking hours.
Larry -- speaking on his own again
Larry Loen <······@rchland.vnet.ibm.com> writes:
> I presume that you don't expect your software to be used to support
> bridge construction? Well, I do operating systems stuff for a
> living and I have no idea what it might be indirectly used for.
But perfectly stable bridges can be built using design tools that crash.
Perhaps if you're building the controlling computer for the locks of a canal
you need it not to crash, but that's a different matter.
If you DID sell an operating system which promised to to crash, that would
be a useful sales point and I hope you'd sell it for a lot more money than
those of us who can often get by without that guarantee (i.e., all us
Microsoft users) are willing to pay.
Alain Picard wrote:
>
[snip]
> No civil engineer would be told by their customer "Sorry mate, we just
> moved the far bank back 50 metre, you don't mind, patching that up, do
> you?" when the bridge is 90% complete. This happens to me in my work
> all the time. I accommodate such requests.
>
> How can this be so? Clearly, because software artifacts are
> altogether different from engineering artifacts.
>
It is also because we can't give anyone a clue of the consequences.
Whereas, the engineer can say "Do that and the bridge will fall down" or else "add another span." We always think we can add the span
'cause we don't have enough real knowledge to say the former when a "clever manager" pressures us.
[snip]
> Apologies for ranting, but I think this engineering metaphor is _so_
> destructive. I've done the big up-front design bit. Guess what --
> all those documents we sweated over for months became obsolete the
> moment we started coding. I don't think it's because we were
> incompetent---I think it's _inherent_ in what we do that it entails
> many small decisions, which have to be taken during the lifetime of
> the process. So, when we actually had to fix or change something
> months later, did we go to these documents?� Of course not---we went
> to the source code. And guess what: it sucked, because it was all
> supposedly documented "elsewhere". I would have _much_ preferred a
> 1/2 page memo about the central ideas of a given subsystem, (the
> _why_), and well written and commented code to tell me the _how_.
>
> �Well, some na�ve people, like myself, did look up these documents
> first, only to discover how useless they were in the face of harsh
> reality.
But, you've merely described the problem and given up. I'm sure the stone masons in the middle ages thought civil engineering, as a
real discipline, was impossible, too. So, they built flying buttersses, watched some of the bigger cathedral vaults collapse, and
basically muddled on. Then, some chap invented calculus. While that discipline didn't have Turing's Halting Theorum to overcome (nor
had they seen it recurr in so many nontrivial places so that it could not be readily set aside thanks to The Useful Halting Subset of
Programs we still can't find), they none the less have managed to put out a discipline that has enough predictive power that you can
actually sue one of them and have it a rational act.
I was told at a conference that a bill was introduced in Texas to make programmers no less liable than any other engineering
discipline. Never heard if it passed, but we won't forever get to call ourselves "artists" whilst our products cause airplanes to fall
out of the sky.
Larry
Larry Loen <······@us.ibm.com> writes:
> But, you've merely described the problem and given up.
Darn -- you found me out! :-)
> I was told at a conference that a bill was introduced in Texas to
> make programmers no less liable than any other engineering
> discipline. Never heard if it passed, but we won't forever get to
> call ourselves "artists" whilst our products cause airplanes to fall
> out of the sky.
I wonder if that includes suing M$ for the gazillion number of $$$
wasted everytime some idiot releases something like the Melissa virus.
When that hit, I was contracting as a very, very large computer company.
The _entire_ floor was rendered helpless (but for one, happy, linux
using exception) for an entire day. I wonder how much money _that_
cost them? Now multiply by the number of companies...
--
It would be difficult to construe Larry Wall, in article
this as a feature. <·····················@netlabs.com>
Larry Loen <······@us.ibm.com> writes:
> I was told at a conference that a bill was introduced in Texas to
> make programmers no less liable than any other engineering
> discipline. Never heard if it passed, but we won't forever get to
> call ourselves "artists" whilst our products cause airplanes to fall
> out of the sky.
It would be a severe error to do this.
This would be like introducing a bill to suggest that those who speak
should be no less liable for their words than lawyers. After all, we
won't forever get to call ourselves "poets" while our words cause
contracts to fail.
Programming is neither art nor engineering. It is just words with meaning.
When meaning is held to an engineering task, it should perhaps be done with
appropriate legal weight. But such a statement should not be confused with
saying that the only possible use of programming is engineering, without the
loss of other disciplines. Just as human language should not be limited
nerely to lawyering.
It will be a sad day when the inevitabilities you fear come true, because
indeed certain art will have died. And planes might as well have fallen
from the sky to express the gravity of that consequence.
In article <···············@world.std.com>,
Kent M Pitman <······@world.std.com> wrote:
>Larry Loen <······@us.ibm.com> writes:
>
>> I was told at a conference that a bill was introduced in Texas to
>> make programmers no less liable than any other engineering
>> discipline. Never heard if it passed, but we won't forever get to
>> call ourselves "artists" whilst our products cause airplanes to fall
>> out of the sky.
>
>It would be a severe error to do this.
>
From where I sit, any means to make commercial software vendors
accept more responsibility can't be all wrong.
>This would be like introducing a bill to suggest that those who speak
>should be no less liable for their words than lawyers. After all, we
>won't forever get to call ourselves "poets" while our words cause
>contracts to fail.
>
What's the difference between my words and a lawyer's words? If
either of us writes a contract, it's a contract, and the words are
important regardless of who wrote them. The lawyer is much more
likely to get the words right than I am, just as I'm much more
likely to get a program to work than he or she is.
>Programming is neither art nor engineering. It is just words with meaning.
>
A blueprint for a bridge, or a circuit schematic, is lines, symbols,
and words with meaning. These things are often considered part
of engineering. The guy who does the actual rivetting is often
not an engineer.
>When meaning is held to an engineering task, it should perhaps be done with
>appropriate legal weight.
Right.
But such a statement should not be confused with
>saying that the only possible use of programming is engineering, without the
>loss of other disciplines. Just as human language should not be limited
>nerely to lawyering.
>
I think we need to divide programming, here, into cases where there are
serious consequences of program failure (in a general sense) and cases
where there are not.
If there are serious consequences, then somebody needs to be held
responsible. The idea of a world where something can be commissioned
for a task, and that thing can fail and kill somebody, and nobody's
responsible, frightens me. We've moved away from that with the
idea of engineering responsibility in most disciplines, but if I
screw up in programming and kill somebody there's no legal way to
hold me responsible, and I think that's bad.
If there are no serious consequences, then what does it matter whether
we are held responsible or not? Suppose a mechanical engineer
builds a wagon for his son, and the kid is pulling it along the
sidewalk when a wheel falls off. People are going to snicker
and be amused, but what official body is going to go after the
engineer? If I write a game and give it away, and it crashes,
what could I be held responsible for, and what would punishment
or damages be like?
>It will be a sad day when the inevitabilities you fear come true, because
>indeed certain art will have died. And planes might as well have fallen
>from the sky to express the gravity of that consequence.
>
If you're saying it will be a sad day when programmers who make planes
fall from the sky are assigned some measure of responsibility, I
disagree. It would be a tragedy if all program were to be
strictly regulated, but that doesn't sound like it's in the bill.
--
David H. Thornley | If you want my opinion, ask.
·····@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
········@visi.com (David Thornley) writes:
> In article <···············@world.std.com>,
> Kent M Pitman <······@world.std.com> wrote:
> >Larry Loen <······@us.ibm.com> writes:
> >
> >> I was told at a conference that a bill was introduced in Texas to
> >> make programmers no less liable than any other engineering
> >> discipline. Never heard if it passed, but we won't forever get to
> >> call ourselves "artists" whilst our products cause airplanes to fall
> >> out of the sky.
> >
> >It would be a severe error to do this.
> >
>
> From where I sit, any means to make commercial software vendors
> accept more responsibility can't be all wrong.
Rights ceded are never regained. Be careful here.
> >This would be like introducing a bill to suggest that those who speak
> >should be no less liable for their words than lawyers. After all, we
> >won't forever get to call ourselves "poets" while our words cause
> >contracts to fail.
>
> What's the difference between my words and a lawyer's words? If
> either of us writes a contract, it's a contract, and the words are
> important regardless of who wrote them.
But many words are not contracts. And many programs are not products.
> The lawyer is much more
> likely to get the words right than I am, just as I'm much more
> likely to get a program to work than he or she is.
No, a lawyer is more likely to get contract wording right. He is not
likely to write poetry better.
> >Programming is neither art nor engineering. It is just words with meaning.
> >
> A blueprint for a bridge, or a circuit schematic, is lines, symbols,
> and words with meaning. These things are often considered part
> of engineering. The guy who does the actual rivetting is often
> not an engineer.
No, "lines, symbols and words with meaning" are not considered engineering.
"Lines, symbols, and words with meaning" AND "offered with the intent of
being engineering" are engineering. This is not a subtle point. Every
person should be permitted to write things that "look like" engineering
without having that be confused with BEING engineering.
The mere act of programming, even programming about domains that engineering
covers, is not engineering. It might be the way I go about understanding
physics. I might come home and program up simulations just to play out loud
with ideas in my mind until they gel. This should not require a license, and
careless wording such as you are here advocating risks that it will require
a license.
> >When meaning is held to an engineering task, it should perhaps be done with
> >appropriate legal weight.
>
> Right.
But it isn't what you've said above. PLEASE be careful with your wording
since you are presently speaking in a forum where words advocate.
(Be careful, because if you claim to me that the mere fact that your words
look like you are trying to make or advocate law doesn't mean it's lawyerly,
you will have made my case.)
> >But such a statement should not be confused with
> >saying that the only possible use of programming is engineering, without the
> >loss of other disciplines. Just as human language should not be limited
> >nerely to lawyering.
>
> I think we need to divide programming, here, into cases where there are
> serious consequences of program failure (in a general sense) and cases
> where there are not.
Nonsense. The bug here is "implied warranty". People should get in the habit
of saying what their program does and in cases where they have sold the
program, standing by that warranty. But when the program is not sold, no
contract exists and so neither should a warranty. Moreover, if a program is
sold with no warranty, I think it's foolish to assume there's an implied
warranty.
If someone is using a program in a mission-critical situation without an
explicit warranty, it's that person, and not the program author, who has
screwed up!
> If there are serious consequences, then somebody needs to be held
> responsible.
That's a political claim. It's a legitimate position, and not even one
I wholly disagree with, though I utterly disagree with the "who" that you
are pointing to. But I also observe by way of fairness that there exist
people who don't think that the world has to always have someone responsible;
the world would not cease to exist if that were so.
> The idea of a world where something can be commissioned
> for a task, and that thing can fail and kill somebody, and nobody's
> responsible, frightens me.
You have shifted here to add "commissioned" (by which I'll infer $$). In
that case, you're talking about a sale. It's the sale that incurs the
responsibility, not the programming. If I had *found* the program and sold
it to you, rather than programming it, the sale should no less incur whatever
responsibility I attached. If I said "I found it in the street; no warranty"
then it's your problem, not mine. If I said "I programmed this but I'm
a lousy programmer; no warranty" then it's your problem, not mine. If we make
a contact that the money you give me is in exchagne for an item with an
attached contract, then that's fine. But that isn't a statement about
programming. Contract law ALREADY is powerful enough to achieve your end,
without mucking with attaching legal implications to our discipline.
> We've moved away from that with the
> idea of engineering responsibility in most disciplines, but if I
> screw up in programming and kill somebody there's no legal way to
> hold me responsible, and I think that's bad.
You don't screw up in programming and kill someone. You screw up in selling
stuff with excessive claims or too little qa.
If you blame the programmer, who are you going to blame if the programmer
is dead or if a program writes the program? Plainly, the blame has to go
with the sale.
> If there are no serious consequences, then what does it matter whether
> we are held responsible or not?
It matters because it is an obstacle to doing and SHARING things freely.
(That seems to matter more to you than to me, so I'm surprised I'd have
to remind you of that.)
> Suppose a mechanical engineer
> builds a wagon for his son, and the kid is pulling it along the
> sidewalk when a wheel falls off. People are going to snicker
> and be amused, but what official body is going to go after the
> engineer?
But if he shares it with a friend, and the friend is injured, you can be sure
these days that the friend will be suing against the "engineer". I don't
like that. It is not something we should seek to copy.
> If I write a game and give it away, and it crashes,
> what could I be held responsible for, and what would punishment
> or damages be like?
If it writes a data file over an existing system file? If it crashes
the system? If it locks up the system in a tight loop and keeps you
from saving and important file in another program running
simultaneously before the machine is booted? .... You CAN be sued,
but it is stupid. There should not be such liabilities. Saying "how
could it hurt me" is the stupidest reason I ever heard for allowing
someone to go ahead and make liabilities. Laws should not be created
by people who have a "how could this hurt me?" attitude.
> >It will be a sad day when the inevitabilities you fear come true, because
> >indeed certain art will have died. And planes might as well have fallen
> >from the sky to express the gravity of that consequence.
>
> If you're saying it will be a sad day when programmers who make planes
> fall from the sky are assigned some measure of responsibility, I
> disagree. It would be a tragedy if all program were to be
> strictly regulated, but that doesn't sound like it's in the bill.
What I am saying is that the act of making commercial airlines is or should
be a carefully monitored process where for each part and service you can find
a CONTRACT that establishes liability. And that is sufficient. Demonstrating
that "programming" was involved is and ought to be irrelevant.
In article <···············@world.std.com>,
Kent M Pitman <······@world.std.com> wrote:
>········@visi.com (David Thornley) writes:
>
>> In article <···············@world.std.com>,
>> Kent M Pitman <······@world.std.com> wrote:
>> >Larry Loen <······@us.ibm.com> writes:
>> >
>> >> I was told at a conference that a bill was introduced in Texas to
>> >> make programmers no less liable than any other engineering
>> >> discipline. Never heard if it passed, but we won't forever get to
>> >> call ourselves "artists" whilst our products cause airplanes to fall
>> >> out of the sky.
>> >
>> >It would be a severe error to do this.
>> >
>> From where I sit, any means to make commercial software vendors
>> accept more responsibility can't be all wrong.
>
>Rights ceded are never regained. Be careful here.
>
Oh, I am. I'm not saying that any idea would be all right.
I'm saying that the software industry, such as it is, is
disgracefully bad about accepting responsibility.
Nor do I know all that much about the contents of the bill.
It says "any other engineering discipline", and the engineers that
I know don't seem to think that their legal responsibility is
intolerable. (I did casually assume that "no less liable" probably
implied "no more liable", and based my comments on that. If this
is wrong, then the bill would be a serious mistake.)
>> >This would be like introducing a bill to suggest that those who speak
>> >should be no less liable for their words than lawyers. After all, we
>>
>> What's the difference between my words and a lawyer's words? If
>> either of us writes a contract, it's a contract, and the words are
>> important regardless of who wrote them.
>
>But many words are not contracts. And many programs are not products.
>
Bingo. Lawyers aren't liable for what they say at parties (no
more liable than I am, anyway). They are responsible for what
they say in their professional capacities. What I'm saying is
that there's no reason not to hold me legally responsible for
some things in my professional capacities.
I can write software that is defective and kills (the probability
of this depends on various things). When a member of a profession
can do this, there needs to be some sort of legal oversight.
>> >Programming is neither art nor engineering. It is just words with meaning.
>> >
>> A blueprint for a bridge, or a circuit schematic, is lines, symbols,
>> and words with meaning. These things are often considered part
>> of engineering. The guy who does the actual rivetting is often
>> not an engineer.
>
>No, "lines, symbols and words with meaning" are not considered engineering.
>
Right. Neither are words with meaning considered programming.
>"Lines, symbols, and words with meaning" AND "offered with the intent of
>being engineering" are engineering. This is not a subtle point. Every
>person should be permitted to write things that "look like" engineering
>without having that be confused with BEING engineering.
>
On the same principle, I should be able to tinker with my tools
without having this confused with mechanical engineering. It
seems to me that I can do that. As far as I know, my mechanical
engineer friend can do things in his basement that don't count
as engineering until he says they are. If we're talking about
programming being the same as engineering, then presumably the
stuff I write at home will be treated the same way.
>The mere act of programming, even programming about domains that engineering
>covers, is not engineering. It might be the way I go about understanding
>physics. I might come home and program up simulations just to play out loud
>with ideas in my mind until they gel. This should not require a license, and
>careless wording such as you are here advocating risks that it will require
>a license.
>
I am not a mechanical engineer. I own, and use, certain tools. (Well,
mostly I let them lie around collecting dust, to be honest.) I can
make machines with these tools. AFAIK, this is not a problem.
I don't think my mechanical engineer friend is liable for what he does
in his basement unless he calls it engineering, or sells it, or
something like that. Not being an engineer or a lawyer, my
understanding could be wrong; if it is, then I agree that the bill
is dangerous, and would instead propose a limitation to allow
nonprofessional programming, even if that is done by a professional.
(Presumably a mechanical engineer can set something up for his own
use that would be unacceptable as an engineering product, such as
when working on a prototype machine that may not meet safety
standards.)
>> >When meaning is held to an engineering task, it should perhaps be done with
>> >appropriate legal weight.
>>
>> Right.
>
>But it isn't what you've said above. PLEASE be careful with your wording
>since you are presently speaking in a forum where words advocate.
>(Be careful, because if you claim to me that the mere fact that your words
>look like you are trying to make or advocate law doesn't mean it's lawyerly,
>you will have made my case.)
>
What you thought you were reading does not appear to be quite what I
thought I was writing, and apparently I was unclear, and I apologize.
I didn't think I needed to write a disclaimer saying that I was
not giving legal advice, and may well have been wrong in that.
However, I will only have made your case if the proposed bill said
that all programs should be treated as if they were legitimate
engineering products, and in that case I will agree with you that
the bill is bad. If it tries to establish equivalence between
software intended as a product and machines intended as products,
rather than between software of all sorts and machines intended
as products, that violates my assumption (listed above) and then
I am wrong on specifics.
>> >But such a statement should not be confused with
>> >saying that the only possible use of programming is engineering, without the
>> >loss of other disciplines. Just as human language should not be limited
>> >nerely to lawyering.
>>
>> I think we need to divide programming, here, into cases where there are
>> serious consequences of program failure (in a general sense) and cases
>> where there are not.
>
>Nonsense. The bug here is "implied warranty". People should get in the habit
>of saying what their program does and in cases where they have sold the
>program, standing by that warranty.
And accepting responsibility in the legal sense. I agree. The fact
is that they do not, and this is a problem. The problem is going to
provoke legal remedies, and does have the potential to provoke
counterproductive overreactions. If I understand the Texas bill
correctly (which is not guaranteed), I don't consider it one of
those.
But when the program is not sold, no
>contract exists and so neither should a warranty. Moreover, if a program is
>sold with no warranty, I think it's foolish to assume there's an implied
>warranty.
>
Which results in no warranty in the vast majority of cases, except
that the CD-ROM will not turn back into a pumpkin for ninety
days.
>If someone is using a program in a mission-critical situation without an
>explicit warranty, it's that person, and not the program author, who has
>screwed up!
>
If it's in a potentially lethal situation, then I suggest that
voluntary warranties are not necessarily sufficient. Right now,
they aren't. For reasons I consider good, the government sets
its own standards for physically dangerous things. In the
current state of affairs, I don't see the market economy working
well. I generally assume that the market was insufficient to
assure safety in other fields, and that's why we have legally
recognized engineering disciplines.
>> If there are serious consequences, then somebody needs to be held
>> responsible.
>
>That's a political claim. It's a legitimate position, and not even one
>I wholly disagree with, though I utterly disagree with the "who" that you
>are pointing to.
I wasn't pointing at anybody in particular there. What I am saying
is that there has to accountability for the various components.
We don't expect a civil engineer to forge his own bolts, but
rather to put responsibility on somebody else to make those
bolts. There are, I believe, legal practices that can assign
blame.
But I also observe by way of fairness that there exist
>people who don't think that the world has to always have someone responsible;
>the world would not cease to exist if that were so.
>
My apologies, I have again been unclear. It is not necessary that
somebody be held responsible for every death; in some respects,
accidents will simply happen, and the cost of preventing those
accidents may be considered too high. Potentially lethal situations
do demand some sort of responsibility to be assessed. Sometimes
it will be determined to be just one of those things (man on amusement
park ride suffers a heart attack and dies - there may be some
causality there, but no responsibility attaches) or the fault of
the dead person (idiot ignores blizzard warning, decides to
explore wilderness in national park).
>> The idea of a world where something can be commissioned
>> for a task, and that thing can fail and kill somebody, and nobody's
>> responsible, frightens me.
>
>You have shifted here to add "commissioned" (by which I'll infer $$).
I understood that that was the case for engineering disciplines, and
therefore understood it to apply to the programming we were discussing.
This was not a shift so much as a failure to make an assumption clear.
Nor do I know exactly in what cases an engineer will be held liable
for the failure of one of his products; presumably a sale, and
exchange of money, is part of determination. I'm thinking of
some product offered as suitable for a task in some manner.
In
>that case, you're talking about a sale. It's the sale that incurs the
>responsibility, not the programming.
Sounds reasonable. I don't know exactly how this works in conventional
engineering disciplines; what I do know is that it does work, and
that my mechanical engineer friend finds it completely acceptable.
I'm going sailing with him next month; maybe I'll ask him about it
then.
If I had *found* the program and sold
>it to you, rather than programming it, the sale should no less incur whatever
>responsibility I attached.
Right.
If I said "I found it in the street; no warranty"
>then it's your problem, not mine.
Sounds reasonable.
If I said "I programmed this but I'm
>a lousy programmer; no warranty" then it's your problem, not mine.
That may not be, depending on the purpose. There are such things
as implied warranties, such as a warranty that a product is in
some way suitable for the use it is sold for. If you offer the
product as potentially suitable for a purpose, then it is
not necessarily the case, and should not necessarily be the case,
that you can disclaim all responsibility.
If we make
>a contact that the money you give me is in exchagne for an item with an
>attached contract, then that's fine. But that isn't a statement about
>programming. Contract law ALREADY is powerful enough to achieve your end,
>without mucking with attaching legal implications to our discipline.
>
In which case we don't need licensed engineers, do we? We can
do everything with contract law. There are reasons why we don't.
They may be bad reasons, but I'd need to be convinced.
>> We've moved away from that with the
>> idea of engineering responsibility in most disciplines, but if I
>> screw up in programming and kill somebody there's no legal way to
>> hold me responsible, and I think that's bad.
>
>You don't screw up in programming and kill someone. You screw up in selling
>stuff with excessive claims or too little qa.
>
QA can be considered as part of programming.
>If you blame the programmer, who are you going to blame if the programmer
>is dead or if a program writes the program? Plainly, the blame has to go
>with the sale.
>
I don't know, but I assume these are solved problems in engineering.
If I buy a machine from my friend, and he drowns in Lake Superior,
and then it turns out to be defective, well, there have to be
legal precedents.
>> If there are no serious consequences, then what does it matter whether
>> we are held responsible or not?
>
>It matters because it is an obstacle to doing and SHARING things freely.
>(That seems to matter more to you than to me, so I'm surprised I'd have
>to remind you of that.)
>
If the bill interferes with that, then, yes, I am opposed. It is
not clear that that will be the case.
And, yes, I don't understand why commercial enterprises aren't
using warranties as a counter to free software. There may be
companies that legally stand behind their software, but I haven't
dealt with any recently. If a company making operating systems
were willing to provide binding warranties that their operating
system will work, for certain values of work, you'd think that
company would acquire a potentially large competitive advantage
over a free product with no warranty. Right now, as far as I
can tell, Microsoft is as liable for Windows as Sandra Bullock
is for Linux, and Linux is more reliable.
>But if he shares it with a friend, and the friend is injured, you can be sure
>these days that the friend will be suing against the "engineer". I don't
>like that. It is not something we should seek to copy.
>
>> If I write a game and give it away, and it crashes,
>> what could I be held responsible for, and what would punishment
>> or damages be like?
>
>If it writes a data file over an existing system file? If it crashes
>the system? If it locks up the system in a tight loop and keeps you
>from saving and important file in another program running
>simultaneously before the machine is booted? ....
Which will not be the case in a well-designed operating system,
and I think that is important. If the game is misdesigned
and the operating system is lousy (there was a dispute about
a beta program working on MS Windows on the rec.* int-fiction
groups a while ago), then these things can happen.
I think it important to establish some sort of accountability
for operating system quality, and the market simply is not
doing that in most cases.
You CAN be sued,
>but it is stupid. There should not be such liabilities. Saying "how
>could it hurt me" is the stupidest reason I ever heard for allowing
>someone to go ahead and make liabilities. Laws should not be created
>by people who have a "how could this hurt me?" attitude.
>
Laws should be created by people who have a "how could this hurt
various people" attitude. Asking how a bill could hurt me, and
basing my attitude partly on that, is valid. Accepting liabilities
at random because they don't seem to have any immediate effect
is stupid, as you say.
>> If you're saying it will be a sad day when programmers who make planes
>> fall from the sky are assigned some measure of responsibility, I
>> disagree. It would be a tragedy if all program were to be
>> strictly regulated, but that doesn't sound like it's in the bill.
>
>What I am saying is that the act of making commercial airlines is or should
>be a carefully monitored process where for each part and service you can find
>a CONTRACT that establishes liability. And that is sufficient. Demonstrating
>that "programming" was involved is and ought to be irrelevant.
What I am saying is that this does not seem to be sufficient in the
general case, particularly in potentially lethal situations. There
are legal requirements for machines that are used for certain purposes,
no matter what a contract may say. I believe that there are good
reasons for these legal requirements.
Software is now a major component of many such machines, and the
trend will be to make it more and more important. I think it
probable that the same reasons for making requirements for
machines apply for making requirements for software.
It may be that the Texas bill is bad, but I haven't been given
any specific reason to think so, given the assumptions I've made,
which seem reasonable to me and which have not been contradicted.
--
David H. Thornley | If you want my opinion, ask.
·····@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
From: George Neuner
Subject: Re: Engineering Envy [was: Re: CL and UML]
Date:
Message-ID: <3b37c7cf.2250375578@helice>
On Thu, 21 Jun 2001 16:58:34 GMT, ········@visi.com (David Thornley)
wrote:
>Bingo. Lawyers aren't liable for what they say at parties (no
>more liable than I am, anyway). They are responsible for what
>they say in their professional capacities. What I'm saying is
>that there's no reason not to hold me legally responsible for
>some things in my professional capacities.
This is not true [and not simply for lawyers].
The law recognizes the idea of a "conspicuous expert" and gives more
weight to the casual utterances of such a person when remarks having
basis in that person's expert knowledge are made in "mixed" company,
ie. in the company of non-experts.
Most of us here qualify as software "experts" in our little domains.
To a lay person, our utterances about how "foo" is great and "baz" is
crap could be considered "expert" opinions, even if we don't intend
them as such.
> KMP wrote:
>>
>>But when the program is not sold, no
>>contract exists and so neither should a warranty. Moreover, if a program is
>>sold with no warranty, I think it's foolish to assume there's an implied
>>warranty.
>>
>Which results in no warranty in the vast majority of cases, except
>that the CD-ROM will not turn back into a pumpkin for ninety
>days.
>
The problem here is that, for all products, there is implied
"merchantability" which includes the notion that the product performs
as advertised.
Clearly a program which crashes *should* violate that if it were sold.
This is clearly not the case in practice ... if it were Microsoft
would be out of business 8-)
> If we make
>>a contact that the money you give me is in exchagne for an item with an
>>attached contract, then that's fine. But that isn't a statement about
>>programming. Contract law ALREADY is powerful enough to achieve your end,
>>without mucking with attaching legal implications to our discipline.
>>
>In which case we don't need licensed engineers, do we? We can
>do everything with contract law. There are reasons why we don't.
>They may be bad reasons, but I'd need to be convinced.
The reason everything isn't settled by contract law is that people
have inflated opinions of their own worth.
Every time you step on a plane, you contract with the airline to limit
the airline's liability to you in the event of an accident. Do you
think for one minute that your life is worth the paltry sum they
offer? Would that contract you signed stop you (or your family) from
further sueing them if you were injured or killed?
The courts long ago decided that contract made in bad faith and those
whose provisions are 'contrary to "public good"' are not enforcible.
The problems we are left with are twofold - (1) it is very difficult
in general to discover and prove bad faith, and (2) there is no
agreement on the meaning of "public good". Consequently, no one can
determine a priori which contracts will be enforcible.
George
·······@dyn.com (George Neuner) writes:
> The law recognizes the idea of a "conspicuous expert" and gives more
> weight to the casual utterances of such a person when remarks having
> basis in that person's expert knowledge are made in "mixed" company,
> ie. in the company of non-experts.
Laws are written by people. Laws can be changed. I happen to wonder
if this restriction was created not by lawyers in order to cause
lawyers to have to disqualify themselves from giving legal advice and
in order to force others from identifying themselves as charlatans,
with the ultimate end of making it hard to offer
commercially-efficient cut-rate lawyerly advice, something for which I
think the market has a strong need.
And I don't see why it would create a problem for both lawyers and doctors
to do that. The public would quickly learn that a warranty mattered, and
most would seek that. Those who did not would at least have acccess to
SOME service rather than none.
Consider the effect of restaurants which are forced to throw out food becuase
they cannot warranty it to be of safe value. Often that food is safe or
would be trusted in limited modes (especially bread and other such things
that are fairly self-inspectable...)
Upping the quality requirement sometimes just raises the price and has no
other commercial effect.
> Most of us here qualify as software "experts" in our little domains.
> To a lay person, our utterances about how "foo" is great and "baz" is
> crap could be considered "expert" opinions, even if we don't intend
> them as such.
But as long as our domain is "programming" and programming is
unwarrantied, then being an expert is irrelevant. If product-design
is what conveys warranty, then it would be businesspeople who would not
speak at cocktail parties, not programmers. Darned good thing secretaries
aren't revealed to be the main source of wisdom in offices, lest they not
be able to share copier repair advice with one another.
> > KMP wrote:
> >>
> >>But when the program is not sold, no
> >>contract exists and so neither should a warranty. Moreover, if a program is
> >>sold with no warranty, I think it's foolish to assume there's an implied
> >>warranty.
> >>
> >Which results in no warranty in the vast majority of cases, except
> >that the CD-ROM will not turn back into a pumpkin for ninety
> >days.
> >
>
> The problem here is that, for all products, there is implied
> "merchantability" which includes the notion that the product performs
> as advertised.
It's not that I don't underseatnd that. I just think that since we're
talking about changes to society, we should undersatnd that our only
option is not to evolve more of a sense of responsibility. Our other
option is to revisit the whole notion of what is implied and what is
not. I think implied warranties are crap.
> Clearly a program which crashes *should* violate that if it were sold.
NONSENSE. It depends on the price at which it was sold. It could be sold
at far less price without qa. If not being used for mission criticial
purposes, it's not clear. I OFTEN buy things saying "if this is junk, I can
afford to just throw it away". It's no different than buying something at
a yard sale. You don't sue the person if it doesn't work.
> This is clearly not the case in practice ... if it were Microsoft
> would be out of business 8-)
Odd to push me into the case of defending one of their business practices,
but so you've done it....
> >> If we make
> >>a contact that the money you give me is in exchagne for an item with an
> >>attached contract, then that's fine. But that isn't a statement about
> >>programming. Contract law ALREADY is powerful enough to achieve your end,
> >>without mucking with attaching legal implications to our discipline.
> >>
> >In which case we don't need licensed engineers, do we? We can
> >do everything with contract law. There are reasons why we don't.
> >They may be bad reasons, but I'd need to be convinced.
>
> The reason everything isn't settled by contract law is that people
> have inflated opinions of their own worth.
Then let them pay extra to have someone else offer them more advice.
> Every time you step on a plane, you contract with the airline to limit
> the airline's liability to you in the event of an accident. Do you
> think for one minute that your life is worth the paltry sum they
> offer? Would that contract you signed stop you (or your family) from
> further sueing them if you were injured or killed?
I don't stepinto their airline based on the money they offer. I step in
there based on the knowledge that the business would not stay in business
if it lsot many people, and that some errors they make are criminally
prosecutable. But in particular, small fly-by-night planes may offer the
same dollar amount promises and I don't fly those...
> The courts long ago decided that contract made in bad faith and those
> whose provisions are 'contrary to "public good"' are not enforcible.
"public good" is something the public needs to have periodic input on,
and we need to be organizing as a group to make amicus briefs on this
if necessary. I don't doubt that some will say it's good for us to take
responsibility, but my feeling is: no responsibility without pay.
Extra responsibility imposed without extra pay is a(n unwanted)
"gift" (no consideration on both sides). I don't buy that as part of
the "social contract"...
"courts" are not things that run (or should run) on autopilot with no
input from the citizenry.
> The problems we are left with are twofold - (1) it is very difficult
> in general to discover and prove bad faith,
So let's eliminate it as a requirement.
> and (2) there is no
> agreement on the meaning of "public good".
So let's make it irrelevant.
> Consequently, no one can
> determine a priori which contracts will be enforcible.
So let's make contracts not depend on this subjective analysis.
"Kent M Pitman" <······@world.std.com> wrote in message
····················@world.std.com...
> ·······@dyn.com (George Neuner) writes:
>
> > The law recognizes the idea of a "conspicuous expert" and gives more
> > weight to the casual utterances of such a person when remarks having
> > basis in that person's expert knowledge are made in "mixed" company,
> > ie. in the company of non-experts.
>
> Laws are written by people. Laws can be changed.
It isn't quite that simple. An awful lot of tort and contract law is not
written by people in the sense that someone deliberately writes laws to
accomplsih such and such a purpose. The majority of such effective law is
case law. 'The law' is arrived at by a sort of annealing process in which
duiputes are resolved by decisions. And when laws are actually written to
accomplish such and such a purpose, often as not they just change the
economics of existing decisions, setting off a new round of 'annealing',
with results that are somewhat hard to predict.
"mikel evins" <·····@reactivity.com> writes:
> "Kent M Pitman" <······@world.std.com> wrote in message
> ····················@world.std.com...
> > ·······@dyn.com (George Neuner) writes:
> >
> > > The law recognizes the idea of a "conspicuous expert" and gives more
> > > weight to the casual utterances of such a person when remarks having
> > > basis in that person's expert knowledge are made in "mixed" company,
> > > ie. in the company of non-experts.
> >
> > Laws are written by people. Laws can be changed.
>
> It isn't quite that simple. An awful lot of tort and contract law is not
> written by people in the sense that someone deliberately writes laws to
> accomplsih such and such a purpose. The majority of such effective law is
> case law. 'The law' is arrived at by a sort of annealing process in which
> duiputes are resolved by decisions. And when laws are actually written to
> accomplish such and such a purpose, often as not they just change the
> economics of existing decisions, setting off a new round of 'annealing',
> with results that are somewhat hard to predict.
I'm familiar with the case law process, but case law can grandfather in
contracts and their interpretations from before a certain date. Copyright
law was changed substantially with the Copyright Act of 1976 and the world
has more or less accomodated the major shift that it created, even if it
does mean split-by-case reasoning for things that occurred over the
transition.
I recognize the need for stability, but at the point where members of a free
society start saying there's no control over the path they've elected in the
past, even where that path can be called into question for its goodness,
it's gone too far. We need always to begin from the assumption that the
things we need to do collectively as a society can be done if we have the will
to do it. Everything else beyond that is "simple" economics.
"Kent M Pitman" <······@world.std.com> wrote in message
····················@world.std.com...
> "mikel evins" <·····@reactivity.com> writes:
> I'm familiar with the case law process, but case law can grandfather in
> contracts and their interpretations from before a certain date. Copyright
> law was changed substantially with the Copyright Act of 1976 and the world
> has more or less accomodated the major shift that it created, even if it
> does mean split-by-case reasoning for things that occurred over the
> transition.
>
> I recognize the need for stability, but at the point where members of a
free
> society start saying there's no control over the path they've elected in
the
> past, even where that path can be called into question for its goodness,
> it's gone too far. We need always to begin from the assumption that the
> things we need to do collectively as a society can be done if we have the
will
> to do it. Everything else beyond that is "simple" economics.
Sure; my only point was that it's not quite as simple as deciding what the
law ought to be. Deciding that the law ought to say such and such in order
to produce effect so and so does not necessarily mean that effect so and so
will be produced, even if the law does say such and such. It depends on the
economic effect of the law.
From: George Neuner
Subject: Re: Engineering Envy [was: Re: CL and UML]
Date:
Message-ID: <3b3a445e.2413344606@helice>
On Tue, 26 Jun 2001 00:48:31 GMT, Kent M Pitman <······@world.std.com>
wrote:
>·······@dyn.com (George Neuner) writes:
>
>> Most of us here qualify as software "experts" in our little domains.
>> To a lay person, our utterances about how "foo" is great and "baz" is
>> crap could be considered "expert" opinions, even if we don't intend
>> them as such.
>
>But as long as our domain is "programming" and programming is
>unwarrantied, then being an expert is irrelevant. If product-design
>is what conveys warranty, then it would be businesspeople who would not
>speak at cocktail parties, not programmers. Darned good thing secretaries
>aren't revealed to be the main source of wisdom in offices, lest they not
>be able to share copier repair advice with one another.
It doesn't matter that your field of expertise is unwarrantied. The
law says that you may be held liable for harm simply by virtue of
"being an expert". The world is full of people who act on hearsay,
mostly to their own detriment. To their credit, most don't think to
sue.
You're right, the law can be changed.
>
>> > KMP wrote:
>> >>
>> >>But when the program is not sold, no
>> >>contract exists and so neither should a warranty. Moreover, if a program is
>> >>sold with no warranty, I think it's foolish to assume there's an implied
>> >>warranty.
>> >>
>> >Which results in no warranty in the vast majority of cases, except
>> >that the CD-ROM will not turn back into a pumpkin for ninety
>> >days.
>> >
>>
>> The problem here is that, for all products, there is implied
>> "merchantability" which includes the notion that the product performs
>> as advertised.
>
>> Clearly a program which crashes *should* violate that if it were sold.
>
<snip>
>
>NONSENSE. It depends on the price at which it was sold. It could be sold
>at far less price without qa. If not being used for mission criticial
>purposes, it's not clear. I OFTEN buy things saying "if this is junk, I can
>afford to just throw it away". It's no different than buying something at
>a yard sale. You don't sue the person if it doesn't work.
This is a personal value judgement with which others may not agree.
Many people, including me, deplore the throw-away society. There are
many times that I would glady pay more to obtain a quality item and
find that the level of quality I desire doesn't exist.
[Yeah, I know ... see a void - fill it. Well, life isn't long enough
to acquire all the necessary skills. Thus I am forced to depend on
others for certain things.]
There is an issue of trust in any purchase (or barter), the standards
of merchantability were developed so that the public could have a
minimum degree of trust in the conduct and ethics of merchants.
They were developed long ago at a time when the
producer/developer/supplier and the "merchant" were (usually) one and
the same. As the two personalities diverged, the laws have been
interpreted to place most liability with the producer, leaving the
merchant charged only with adequate delivery.
Versions of these laws exist in every modern country and, though
possibly uncodified, the idea is championed almost everywhere. That
these ancient ideas have survived basically unchanged for so long is
somewhat telling ... obviously enough people feel strongly about it to
keep the laws in place.
The empirical evidence seems clear that people don't think "caveat
emptor" is the right attitude for a merchant ... at least when those
people are wearing their "consumer" hats.
>> This is clearly not the case in practice ... if it were Microsoft
>> would be out of business 8-)
>
>Odd to push me into the case of defending one of their business practices,
>but so you've done it....
Wow!
George
·······@dyn.com (George Neuner) writes:
> There is an issue of trust in any purchase (or barter), the standards
> of merchantability were developed so that the public could have a
> minimum degree of trust in the conduct and ethics of merchants.
Programming is not purchasing or bartering. Much software is given
away free, and appares to fall even under this implied warranty of
merchantability, since the disclaimers on much of it imply they are
disclaiming as much as they can of baggage that never should have been
there in the first place.
A core value I'm trying to protect is the right of people to think.
At its core level, programming is not much different from speaking
or thinking. It is just expressing a concise and clear thought about
a process or procedure. That there should be liability incurred in
such an act is deeply wrong, IMO.
Not all acts of creation are acts of exchange, nor are all acts of
exchange purporting to offer an item for the purpose that such implied
warranties might infer. For example, suppose I sell someone the
result of the obfuscated C contest? Probably there is some warranty
that it does *something*, but what if it had a bug and did not run?
Would it make it any less interesting to look at? I don't really
think so. (That it's virus free is maybe another matter.)
On Wed, 27 Jun 2001, Kent M Pitman wrote:
> A core value I'm trying to protect is the right of people to think.
> At its core level, programming is not much different from speaking
> or thinking. It is just expressing a concise and clear thought about
> a process or procedure. That there should be liability incurred in
> such an act is deeply wrong, IMO.
Agreed; it's also deeply wrong that such an act could be patented.
Tim
> > A core value I'm trying to protect is the right of people to think.
> > At its core level, programming is not much different from speaking
> > or thinking. It is just expressing a concise and clear thought about
> > a process or procedure. That there should be liability incurred in
> > such an act is deeply wrong, IMO.
>
> Agreed; it's also deeply wrong that such an act could be patented.
Do you also object to patents that result from someone drawing something,
say a novel fluid pump?
-andy
On 28 Jun 2001, Andy Freeman wrote:
> > > A core value I'm trying to protect is the right of people to think.
> > > At its core level, programming is not much different from speaking
> > > or thinking. It is just expressing a concise and clear thought about
> > > a process or procedure. That there should be liability incurred in
> > > such an act is deeply wrong, IMO.
> >
> > Agreed; it's also deeply wrong that such an act could be patented.
>
> Do you also object to patents that result from someone drawing something,
> say a novel fluid pump?
I'm not a great fan of patents in general, but let's say: No, I don't; as
far as I know, drawing a pump can never be grounds for patent
infringement.
Oh, you mean building a pump after drawing it :) Well, I dunno. My
personal feelings towards it would depend on how novel the pump was and
how vital the patent disclosure was in understanding the design.
But, I'm not a machinist so building a pump doesn't approach, in my mind,
anything like a thought process. Writing software does, so for the same
reasons KMP finds the concept of liability applied to programming
offensive I find restrictions on the process, including patents,
offensive.
Tim, who'd really rather flame about Lisp or something
> > Do you also object to patents that result from someone drawing something,
> > say a novel fluid pump?
>
> I'm not a great fan of patents in general, but let's say: No, I don't; as
> far as I know, drawing a pump can never be grounds for patent
> infringement.
>
> Oh, you mean building a pump after drawing it :) Well, I dunno. My
> personal feelings towards it would depend on how novel the pump was and
> how vital the patent disclosure was in understanding the design.
The first person received a patent after filing a drawing, the second
did a drawing and built it, eventually resulting in infringement.
By definition, the drawing makes it possible for someone skilled in the
art to make use of the novelty. Patent law doesn't reward infringers who
maintain ignorance, so the "did they use the drawing in the patent"
question doesn't come up. (Patent law doesn't do a good enough job
in punishing applicants that maintain ignorance.)
> But, I'm not a machinist so building a pump doesn't approach, in my mind,
> anything like a thought process.
I'm sorry for your loss. Architecting/designing a complex system that happens
to include pumps is, as is designing or figuring out how to build a pump.
Mechanical stuff is a lot like programming. (One difference is that the
folks doing mechanical drudgery, such as most assembly, often use different
tools than people doing non-drudgery. That difference isn't as common
in programming.)
The "I dislike all patents" position makes sense - I'm trying to find a
coherent explanation of why software patents are different than other
patents.
Yes, we execute our "drawings", but no one has suggested that mechanical
inventions described by drawings that can be "automatically" transformed
into objects are somehow less novel because of the that transformation.
-andy
······@earthlink.net (Andy Freeman) writes:
> The "I dislike all patents" position makes sense - I'm trying to find a
> coherent explanation of why software patents are different than other
> patents.
They are different because we live in a "rational" world; that is, you
can't, by some Cantor-like diagonalization end up in a place in the
address space called the "real" world that isn't one of the finitely
enumerable states of the machine. A great deal of the "purpose" of
software, at least at this stage of evolution, is convergent
technology; to enumerate and control those important things that can
be expressed in a small number of bit patterns. The idea of doling out
pieces of that finitely enumerable world like .com names until they
are all gone is what bugs programmers, perhaps more than other artisans
because they haven't honed their craft to the point that they are within
striking distance of an actual, real, mathematical proof that there can
be no other way to achieve a certain end (worse if you add the word
"efficiently"). We are all hyperconscious of just how tiny our world is.
Maybe if engineers had their work reduced to digital formulas, they would
become similarly incensed. Or maybe most of the really good things in
engineering happened so long ago as to no longer be either patentable or to
have a patent applying, such that they don't feel the stranglehold we do
for having had patents applying (and stretching) at the moment of trying
to bring the emergent information industry into life. (It's hard to look
at something as ubiquitous as it is now and remember how brand new it all is.)
Worsee still, the computational aspect of has probably aided in the
escalation of some areas, where filing patents by hand was once expensive
and I bet now there's escalated glut due to automation, extra overhead due
to larger searches required, extra confusion due to ever-smaller gaps between
the edges of one technology and the edges of another, etc.
> They are different because we live in a "rational" world; that is, you
> can't, by some Cantor-like diagonalization end up in a place in the
> address space called the "real" world that isn't one of the finitely
> enumerable states of the machine. A great deal of the "purpose" of
> software, at least at this stage of evolution, is convergent
> technology; to enumerate and control those important things that can
> be expressed in a small number of bit patterns. The idea of doling out
> pieces of that finitely enumerable world like .com names until they
> are all gone is what bugs programmers, perhaps more than other artisans
> because they haven't honed their craft to the point that they are within
> striking distance of an actual, real, mathematical proof that there can
> be no other way to achieve a certain end (worse if you add the word
> "efficiently"). We are all hyperconscious of just how tiny our world is.
Like I said, I don't see what distinguishes software patents. I could
argue that the theoretical ability to enumerate doesn't make the space
usefully small. (The "efficient" constraint does reduce the size of
the result set, but its filter is quite expensive, so I don't think
that it has the effect that KMP claims.) I think that the space is
incredibly large, that the sun will go nova before a google of KMP's
would hit its boundaries.
Instead, I'll point to history, namely an assertion that the patent
office should be shut down because "everything had been invented".
That was a reference to physical artifacts and it happened early this
century.
They got over it.
-andy
······@earthlink.net (Andy Freeman) writes:
> Instead, I'll point to history, namely an assertion that the patent
> office should be shut down because "everything had been invented".
> That was a reference to physical artifacts and it happened early
> this
^
|
bug
> century.
Peter Wood wrote:
>
> ······@earthlink.net (Andy Freeman) writes:
>
> > Instead, I'll point to history, namely an assertion that the patent
> > office should be shut down because "everything had been invented".
> > That was a reference to physical artifacts and it happened early
> > this
> ^
> |
> bug
>
> > century.
That patent office story is bogus, ie not true, ie a myth that has been
circulating for about a century, but it never gets any truer.
Al
On 29 Jun 2001 16:41:28 -0700, ······@earthlink.net (Andy Freeman) wrote:
> incredibly large, that the sun will go nova before a google of KMP's
> would hit its boundaries.
I'm just nitpicking, but this can probably happen only to double stars :)
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
······@earthlink.net (Andy Freeman) writes:
> I could
> argue that the theoretical ability to enumerate doesn't make the space
> usefully small. (The "efficient" constraint does reduce the size of
> the result set, but its filter is quite expensive, so I don't think
> that it has the effect that KMP claims.) I think that the space is
> incredibly large, that the sun will go nova before a google of KMP's
> would hit its boundaries.
Funny you should use the word "useful" in the first sentence and then
eliminate it as a filter. There are huge numbers of ways to draw a
window or a button, but only a relatively few that are at all aesthetic.
And I was speaking only metaphorically anyway, btw. I meant it to give
the mathemeticians some visual imagery, not to give them armament for proofs.
I do think the digital world is smaller and tighter than the real world.
Beyond that, I didn't mean to say anything rigorous.
> > I could
> > argue that the theoretical ability to enumerate doesn't make the space
> > usefully small. (The "efficient" constraint does reduce the size of
> > the result set, but its filter is quite expensive, so I don't think
> > that it has the effect that KMP claims.) I think that the space is
> > incredibly large, that the sun will go nova before a google of KMP's
> > would hit its boundaries.
>
> Funny you should use the word "useful" in the first sentence and then
> eliminate it as a filter.
That reading was unintended. Here's a second try.
"The space is so large that its finiteness doesn't help. There's a subset
which is arguably more interesting, but extracting that subset is so much
work that its existence doesn't necessarily help." I should have also
said that the subset is probably also big enough.
> There are huge numbers of ways to draw a
> window or a button, but only a relatively few that are at all aesthetic.
And the patent protection on them has either expired or is about to.
Suppose that one could patent mathematical axioms. That's pretty much
the worst case for "locking up essential information". However, the
amount of time that they're locked up is inconsequential in the long-term.
How often does geometry get discovered?
Ten years ago, the "essential information" argument was much stronger.
However, now that the lockup might have some real consequences, its
expiring OR no one bothered when the lockup was possible.
We're in the nasty transition now, but it too is passing quickly.
-andy
······@earthlink.net (Andy Freeman) writes:
> Suppose that one could patent mathematical axioms. That's pretty much
> the worst case for "locking up essential information". However, the
> amount of time that they're locked up is inconsequential in the long-term.
> How often does geometry get discovered?
There's been a growing concern that IP protection is lengthening in a way
that gets renewed indefinitely. That would be a subject of major concern.
O(1) is obviously not a concern if 1 stays nice and constant.
Kent M Pitman <······@world.std.com> wrote in message news:<···············@world.std.com>...
> ······@earthlink.net (Andy Freeman) writes:
>
> > Suppose that one could patent mathematical axioms. That's pretty much
> > the worst case for "locking up essential information". However, the
> > amount of time that they're locked up is inconsequential in the long-term.
> > How often does geometry get discovered?
>
> There's been a growing concern that IP protection is lengthening in a way
> that gets renewed indefinitely. That would be a subject of major concern.
> O(1) is obviously not a concern if 1 stays nice and constant.
Copyright protection terms have been increasing, but patent terms are
roughly stable.
For a while now, the clock on patent terms has started when the application
is filed. I don't know when the US made that change, but if it was before
1980, what interesting fundamental patents are worrisome? (Remember, the
broader the fundamental patent, the less that can be claimed in the future.
Consider the original trap-door crypto patents. Thanks to means plus
function claims plus the doctrine of equivalents, RSA looked like a lock.
However, now there's almost nothing left to claim, and the RSA patent has
expired.)
The drug companies are trying a cute hack to get another 20 years after
they've been on the market (which is way less than 20 years because of
approval delays), but it's unclear that they'll succeed and it's unclear
that a trick with similar effects can be used elsewhere.
-andy
Andy Freeman wrote:
[snip]
> > There are huge numbers of ways to draw a
> > window or a button, but only a relatively few that are at all aesthetic.
>
> And the patent protection on them has either expired or is about to.
>
> Suppose that one could patent mathematical axioms. That's pretty much
> the worst case for "locking up essential information". However, the
> amount of time that they're locked up is inconsequential in the long-term.
> How often does geometry get discovered?
>
> Ten years ago, the "essential information" argument was much stronger.
> However, now that the lockup might have some real consequences, its
> expiring OR no one bothered when the lockup was possible.
>
> We're in the nasty transition now, but it too is passing quickly.
>
> -andy
Are we? Didn't congress last year extend some of these deadlines? Or, did that only apply to copyrights? I got the hazy impression
that some bill passed a year or two ago that did things like give (at least) the Doyle estate and Disney extended copyright protection
for their properties. Maybe they left patents out of it, but still. . .you begin to wonder if some of this stuff won't get locked up
in perpetuity -- though a raucous world that includes Europe may save us by not going along.
Larry
Larry Loen <······@us.ibm.com> wrote in message > > Ten years ago, the "essential information" argument was much stronger.
> > However, now that the lockup might have some real consequences, its
> > expiring OR no one bothered when the lockup was possible.
> >
> > We're in the nasty transition now, but it too is passing quickly.
>
> Are we? Didn't congress last year extend some of these deadlines?
I am unaware of any change in patent periods since the US went from
17 years after issue to 20 years after application; that change was
quite a while ago and was for conformance with what most foreign
countries have used for some time.
The US did add a provisional application option recently, maybe last
year, which lets the inventor delay completing the application for one
year, but the 20 year clock starts when the provisional is filed. The
US is also starting to disclose applications after 18 months in certain
circumstances.
I don't keep track of legislation. I thought that the last change in
copyright law was DMCA which didn't change duration, but "modernized"
things like whether encryption schemes were holy artifacts and gave
ISPs a safe harbor.
AFAIK, no Disney copyrights are that close to expiration. (I don't know
who Doyle is/was - if it's Arthur Conan Doyle, I thought that Sherlock
Holmes went public domain some time ago.) When they do come close to
expiration, say 2-5 years from now, I expect that Congress will consider
extending copyright periods, because that coincidence has happened before.
I am a bit confused why trademarks, which last forever, doesn't do what
Disney "needs", namely to stop people from producing new Mickey Mouse
cartoons, but admit that needs and wants are different. AFAIK, in
Disney's case, all that expiration of copyright would do is let people
make and sell copies of old work. Yes, copyright covers derived works,
but I think that trademark restrictions apply even if there's no copying.
I thought that some Disney copyrights had already expired in some other
countries.
-andy
Andy Freeman wrote:
>
>
> AFAIK, no Disney copyrights are that close to expiration. (I don't know
> who Doyle is/was - if it's Arthur Conan Doyle, I thought that Sherlock
> Holmes went public domain some time ago.) When they do come close to
> expiration, say 2-5 years from now, I expect that Congress will consider
> extending copyright periods, because that coincidence has happened before.
>
Yes, it is A C Doyle and no, as far as I know, they have somehow kept their copyrights alive, perhaps even to this day. I remember reading a while
back, in some source that I deemed trustworthy, that circa 1990 or so you should not assume anything copyrighted before some obscenely early date --
late 19th century -- had an expired copyright without a lawyer's advice.
Disney will be an interesting case. They have, for instance, many "variants" of Mickey Mouse -- collectors distinguish the 1930s and 1950s era
Mickeys because of changes in how the character gets drawn. Whether the new ones can somehow preserve/prevent using the older, expired ones is a good
one for the lawyers -- and probably will be someday.
If these have expired in Austria or Ghana, that's interesting as far as it goes. I am parochially interested in US law, since I spend most of my time
here ; ) .
Larry
> Worsee still, the computational aspect of has probably aided in the
> escalation of some areas, where filing patents by hand was once expensive
> and I bet now there's escalated glut due to automation, extra overhead due
> to larger searches required, extra confusion due to ever-smaller gaps between
> the edges of one technology and the edges of another, etc.
There might be some mechanical generation opportunities around the various
genome projects, but the "plus function" restriction should handle them.
Outside of that (and automated searches and word processing), how has
mechanization made patent filing less expensive?
I don't know what search overhead is objectionable - the search overhead
incurred by the patent office, the overhead that should be incurred by
the patent office, what? (If one objects to patents, search overhead
incurred by applicants is good.)
The confusion around the edges just leads to invalid patents (due to overlap)
that die when contested or patents that don't cover useful things. (Presumably,
better drafting could have eliminated the overlap, leaving a valid patent,
so that confusion works in favor of those who object to patents in
crowded fields.)
-andy
From: George Neuner
Subject: Re: Engineering Envy [was: Re: CL and UML]
Date:
Message-ID: <3b3cbead.2575722312@helice>
On 29 Jun 2001 07:07:04 -0700, ······@earthlink.net (Andy Freeman)
wrote:
>By definition, the drawing makes it possible for someone skilled in the
>art to make use of the novelty. Patent law doesn't reward infringers who
>maintain ignorance, so the "did they use the drawing in the patent"
>question doesn't come up. (Patent law doesn't do a good enough job
>in punishing applicants that maintain ignorance.)
Patent law deliberately *protects* those who "maintain ignorance".
Both the so-called "clean room" design in which the competing product
is designed from scratch without reference to the patented one, and
the "black box design" in which the competitor uses the patented
product as a functional model (but does not take it apart) ARE LEGAL
and, if done correctly, non-infringing.
Patent law has been abused to create monopoly, but its original intent
was to foster innovation and competition by encouraging inventors to
make their inventions public rather than hide them.
George
------------------------------------------------------------
Disclaimer: I am not a patent attorney. My father, sister,
and a dozen or so family friends are.
> Patent law deliberately *protects* those who "maintain ignorance".
> Both the so-called "clean room" design in which the competing product
> is designed from scratch without reference to the patented one, and
> the "black box design" in which the competitor uses the patented
> product as a functional model (but does not take it apart) ARE LEGAL
> and, if done correctly, non-infringing.
Patent infringement is rarely a criminal matter, so "ARE LEGAL" is ....
Regardless of one's development process or knowledge, if the subsequent
result matches the claims, it's infringing. (The definition of "match" is
subtle and changing, Festo v SHOKETSU KINZOKU KOGYO KABUSHIKI CO., LTD.
is a prime example.) That's why infringment defenses go to "it's not
novel", "it's not valid", "we were first", "there's no match", and so on.
And from a later message
> I have contacts for about 30 patent attorneys if you'd like to talk to
> one.
I'd love to see a list of patent attorneys who believe that development
process trumps claim matching. Better yet, can you provide a list of
clients who have relied/acted on this advice, preferably clients with money?
You might want to check with them before attributing this position to them.
(While there may be some altruistic appearance to that suggestion, I'm
actually looking for some confirmation that the implied market niche
actually exists.)
-andy
From: George Neuner
Subject: Re: Engineering Envy [was: Re: CL and UML]
Date:
Message-ID: <3b409f41.248609601@helice>
On 29 Jun 2001 17:10:41 -0700, ······@earthlink.net (Andy Freeman)
wrote:
>> Patent law deliberately *protects* those who "maintain ignorance".
>> Both the so-called "clean room" design in which the competing product
>> is designed from scratch without reference to the patented one, and
>> the "black box design" in which the competitor uses the patented
>> product as a functional model (but does not take it apart) ARE LEGAL
>> and, if done correctly, non-infringing.
>
>Patent infringement is rarely a criminal matter, so "ARE LEGAL" is ....
"Legal" as they are permissible under the law passed by Congress and
enforced by the courts.
>Regardless of one's development process or knowledge, if the subsequent
>result matches the claims, it's infringing.
It can be technically infringing and yet be allowed. Proof of clean
or black box development is a valid defense. As the plaintiff in such
a case, the best outcome you can hope for is a cross licensing
agreement - you aren't likely to get either restraint or damages.
Technically, you won ... the court upheld your patent ... but you also
lost because your competitor was allowed to continue selling, you
expended resources pursuing your claim and you got little or no
compensation for your perceived damages.
>I'd love to see a list of patent attorneys who believe that development
>process trumps claim matching. Better yet, can you provide a list of
>clients who have relied/acted on this advice, preferably clients with money?
Check the business section in the newspaper.
It happens more frequently than you imagine. Widgits are reverse
engineered and functionally cloned in industry all the time ... you
have the right to take your legally obtained and owned widgit apart to
see how it works (unless you have contracted with the manufacturer not
to). You do not have the right to copy the widgit, but you do have
the right to design something similar. The original designer has the
right to sue you if she thinks yours is too similar.
Disputes between manufacturers are more often settled by cross
licensing than by trial because the plaintiff can't make the burden of
proof for a trial and arbitration is ordered to resolve the issue.
Only blatant copying is prohibited and that is frequently difficult to
prove ... experienced manufacturers know just how much they have to
change to meet the difference requirements.
As a developer, I have never been a fan of patent or copyright
protection for software. Patents were designed for manufacturing
industry and copyrights for publishing books ... I don't happen to
think software is a particularly good match for either.
But not liking the law doesn't make it go away. Like most everything
else Congress does, IP law is written with lots of input from
potential monopolizers and little from the process experts. That
results in attrocities like the current DMCA, parts of which can be
interpreted as making simply viewing a copyrighted work an
infringment.
I don't condone copying other people's work without their permission.
I don't do it, and I would not like to have my work copied in such a
fashion. But I am aware that it could happen under circumstances
about which I may be able to do absolutely nothing.
I am all in favor of promoting ethical behavior, but the law is not
synonymous with ethics and I think holier-than-thou positions which
stifle discussion of the realities of the law are not a solution to
the problems we face.
George
===============================================================
Disclaimer: I am not an IP attorney, my father and sister are.
George Neuner <·······@dyn.com> wrote:
+---------------
| >Regardless of one's development process or knowledge, if the subsequent
| >result matches the claims, it's infringing.
|
| It can be technically infringing and yet be allowed. Proof of clean
| or black box development is a valid defense.
+---------------
Sorry, it is *NOT*, at least not for patents in the U.S. I think you're
confusing it with copyright. A patent is an exclusive right to manufacture
and sell. Independent reinvention is no defense. (Neither is "obviousness",
at least, once the patent has been granted.)
Many companies (including one I worked for back in the early 80's) who
made CRT display terminals were surprised to get a little letter one day
from RCA because it turned out that RCA had a patent on (roughly) storing
fonts in ROM, and they wanted a cut from every terminal you shipped.
We had good patent attorneys. We still paid... :-{
-Rob
-----
Rob Warnock, 31-2-510 <····@sgi.com>
SGI Network Engineering <http://reality.sgi.com/rpw3/> [until 8/15]
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
[Note: ·········@sgi.com and ········@sgi.com aren't for humans ]
····@rigden.engr.sgi.com (Rob Warnock) writes:
>
> Sorry, it is *NOT*, at least not for patents in the U.S. I think you're
> confusing it with copyright. A patent is an exclusive right to manufacture
> and sell. Independent reinvention is no defense. (Neither is "obviousness",
> at least, once the patent has been granted.)
>
> Many companies (including one I worked for back in the early 80's) who
> made CRT display terminals were surprised to get a little letter one day
> from RCA because it turned out that RCA had a patent on (roughly) storing
> fonts in ROM, and they wanted a cut from every terminal you shipped.
> We had good patent attorneys. We still paid... :-{
This is OT, but I gotta ask: Do you think there is anything that Apple could
have done to protect their GUI from MS copying it? (Yes, it was derivative from
Xerox PARC's but really quite a bit better, look at Squeak to see something
close to the original)
In other words, if I devise a user interface with certain functionality and
appearance, how do I protect it?
Regards, KBK
·······@dyn.com (George Neuner) wrote in message news:<··················@helice>...
> On 29 Jun 2001 17:10:41 -0700, ······@earthlink.net (Andy Freeman) wrote:
> >Regardless of one's development process or knowledge, if the subsequent
> >result matches the claims, it's infringing.
>
> It can be technically infringing and yet be allowed. Proof of clean
> or black box development is a valid defense.
Like the man wrote, pay for advice from a competent attorney before acting
on what he writes.
> >I'd love to see a list of patent attorneys who believe that development
> >process trumps claim matching. Better yet, can you provide a list of
> >clients who have relied/acted on this advice, preferably clients with money?
>
> Check the business section in the newspaper.
Neuner pre-emptively offered a specific list of 30 attorneys who (he claims)
believe that development process trumps claim matching. Perhaps I was supposed
to be so impressed that, well, I don't know, because it didn't work. Instead,
I accepted his offer - I want the list that he offered. Will he duck this
request as well?
> It happens more frequently than you imagine. Widgits are reverse
> engineered and functionally cloned in industry all the time ... you
> have the right to take your legally obtained and owned widgit apart to
> see how it works (unless you have contracted with the manufacturer not
> to). You do not have the right to copy the widgit, but you do have
> the right to design something similar. The original designer has the
> right to sue you if she thinks yours is too similar.
Yup, and if the claims match what you've developed, no matter how you
developed it, you're infringing. At that point, you can try to get
the patent invalidated, or you can look at the patent-owners stuff to
find things that infringe one or more of your patents. However, if
you fail, you're going to be paying royalties (best case) or you're
going to lose that biz (ask Kodak about their instant photography biz).
Like all litigation, there are no guarantees, and lots more money helps,
but there are only a few cases where there's a statutory (or common
law) reason why the patent owner doesn't get to choose the royalty
rate or to simply block the infringer from further use.
Few patents are so broadly written that any mechanism for the function
is covered. (Remember, patents are ownership of the use of specified
artifact for specific purpose.) Therefore, it's usually possible to
design a widget with a particular function without infringing a
specific patent. However, that's no guarantee that you'll be happy
with the resulting widget. (Whether it is possible to design said
function without infringing every patent depends on lots of things.
However, it's okay to infringe invalid or obsolete patents.)
Yes, the definition of "match" is important. It's also changing.
For those who care, I cited an important recent case - I hope that's
more useful than claiming to be related to or know people who have
certain qualifications. (Not that I lack such connections - I just
don't see how they bolster my argument.)
-andy
In article <··················@helice>, George Neuner <·······@dyn.com> wrote:
>As a developer, I have never been a fan of patent or copyright
>protection for software. Patents were designed for manufacturing
>industry and copyrights for publishing books ... I don't happen to
>think software is a particularly good match for either.
>
Not really, but there does have to be some sort of IP protection.
I'm not totally against patents, but I think there are severe
problems with the software patent practice (for one thing, the
definitions of "obvious" appropriate for an electric or mechanical
system are not appropriate for a software system). Copyright
seems like a reasonable match.
The US Constitution gives Congress the right to make these laws
for the purpose of promoting the advancement of the useful arts.
The best general way I know of to promote something is to make
it possible to make lots and lots of money off it (although not
necessarily likely). People will invest great effort in something
that might possibly make them wealthy (not all people, but enough),
and will not necessarily work nearly as hard for something that
might give them a comfortable retirement at age 62.
The way to make lots and lots of money off something is to come up
with some method whereby you do something once that is valuable to
many people. In software, you make millions (when you do) by
writing software and selling it over and over again to lots of
people. You can't make millions by selling services, and technical
books simply don't sell like Tom Clancy's books do (unless, I
guess, Clancy writes them, and I'd suspect that his fiction
outsells his nonfiction by a large margin).
The only way you can sell a software product to large numbers of
people at a large profit is to have some sort of restriction
on copying and resale. Copyright is adequate for this.
(Consider the business I work for. We make a very large and
complicated product that is very useful, partly from its
comprehensiveness, and so we sell it for large amounts of
money. The ability to charge hundreds of thousands, or even
millions, of dollars for a short stack of CD-ROMs is what
makes it possible to make this product.)
(Disclaimer: I am an open-source advocate, but not a fanatic.
I do believe that there have got to be better ways to finance
the making of high-quality software, but I haven't found any
compatible with the way the economy works today. I make no
promises about the future.)
--
David H. Thornley | If you want my opinion, ask.
·····@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
On Thu, 05 Jul 2001 21:18:12 GMT, ········@visi.com (David Thornley)
wrote:
>The US Constitution gives Congress the right to make these laws
>for the purpose of promoting the advancement of the useful arts.
>The best general way I know of to promote something is to make
>it possible to make lots and lots of money off it (although not
>necessarily likely). People will invest great effort in something
>that might possibly make them wealthy (not all people, but enough),
>and will not necessarily work nearly as hard for something that
>might give them a comfortable retirement at age 62.
But, even if this does promote 'the useful arts', is it a good thing
for a society in general to promote a 'win a lottery', 'get rich
quick' mindset? What is so desirable about a frezied pursuit of
innovation and novelty at any cost?
>The only way you can sell a software product to large numbers of
>people at a large profit is to have some sort of restriction
>on copying and resale. Copyright is adequate for this.
But this restriction takes two forms: a legal sanction and the cost
and difficulty of copying. THe second no longer applies to book etc
and never was in the case of software. So you have a law that is
unenforceble.
·····@lostcause.co.uk (DJC) writes:
> On Thu, 05 Jul 2001 21:18:12 GMT, ········@visi.com (David Thornley)
> wrote:
>
> >The US Constitution gives Congress the right to make these laws
> >for the purpose of promoting the advancement of the useful arts.
> >The best general way I know of to promote something is to make
> >it possible to make lots and lots of money off it (although not
> >necessarily likely). People will invest great effort in something
> >that might possibly make them wealthy (not all people, but enough),
> >and will not necessarily work nearly as hard for something that
> >might give them a comfortable retirement at age 62.
>
> But, even if this does promote 'the useful arts', is it a good thing
> for a society in general to promote a 'win a lottery', 'get rich
> quick' mindset? What is so desirable about a frezied pursuit of
> innovation and novelty at any cost?
Actually, it's not as clear as you'd think. There as an article in
the LA Times sometime in the early 90's which explained a phenomenon
I'd not heard of before, and which I've found continuously explanatory
of bizarre behaviors hence. You might not like this theory, but
that's not the same as saying it's not true:
In the era of the global corporation, companies make decisions about
where they will home themselves and where they will build factories.
Countries are now, though not quite in the way yet predicted by the
old (and soon to be remade) SciFi movie Rollerball, subordinate to
Companies as a controlling force for decision-making in the world.
As with an animal doing a mating ritual, a country shows off its best
plumage in order to attract the jobs and taxes that come with a
company locating itself in their bounds. No international force
exists to tell a company it shouldn't ask for the moon.
When a country makes laws that offer big profits, big companies make
their nest there. It's good for the country (not the thing that
attracted the company per se, but having the company) and it's good
for the company.
You might wish you could wish these large corporate animals attracted
each other by reasoned discussions of erudite issues like Shakespeare
and Plato, but "sex" among such entities of such a global nature is
just not constructed that way.
> >The only way you can sell a software product to large numbers of
> >people at a large profit is to have some sort of restriction
> >on copying and resale. Copyright is adequate for this.
>
> But this restriction takes two forms: a legal sanction and the cost
> and difficulty of copying. THe second no longer applies to book etc
> and never was in the case of software. So you have a law that is
> unenforceble.
Have you looked at how expensive it is to make a statutory violation of
copyright? It will put even big companies out of business quite fast.
So that they are unenforceable is questionable. If you're very tiny,
you can sneak under the wires, but you can't build something like
Napster without being at enormous daily risk of losing your entire
business.
Napster may have done something interesting by making ALL of its value
be investment in infringement. If sued, you lose only the illegal
parts, which is all of it. I'm not sure it can be bought by someone
with legal assets, though, without putting those assets at risk. Has
anyone seen an analysis on that?
I think copyright is safe for now. And, because copyright mostly defends
the "little guy", I hope it remains safe a long time.
Kent M Pitman <······@world.std.com> writes:
> In the era of the global corporation, companies make decisions about
> where they will home themselves and where they will build factories.
> Countries are now, though not quite in the way yet predicted by the
> old (and soon to be remade) SciFi movie Rollerball, subordinate to
> Companies as a controlling force for decision-making in the world.
Yah, that kind of control is reserved for the financial institutions
which control fiscal policy, public debt, and the central banks of
these countries.
> When a country makes laws that offer big profits, big companies make
> their nest there. It's good for the country (not the thing that
> attracted the company per se, but having the company) and it's good
> for the company.
It's arguable wether it's good for the country, state or township.
That largely depends on which operations are situated in which
country, and the flow of capital into or out of the company via those
oeprations. In third-world countries the usual result is a minor
influx of wage capital, with considerable outflow of profits to other
countries and depletion of natural resources. The infrastructure
needed to support these foreign ventures is paid for thru loans. The
loans are given on the condition that internal reforms are taken to
allow maximum extraction of profit from the venture. They are net
exporters of capital, that is, they are getting poorer, with a few
notable exceptions.
> You might wish you could wish these large corporate animals
> attracted each other by reasoned discussions of erudite issues like
> Shakespeare and Plato, but "sex" among such entities of such a
> global nature is just not constructed that way.
I think the article only covers one part of the process of moving
capital from the periphery to the center, the globalization of
production. The other part is the globalization of finance, not a new
feature in our global economy, but it's changed in power and scope
considerably since the establishment of the Bretton-Woods
institutions.
> I think copyright is safe for now. And, because copyright mostly
> defends the "little guy", I hope it remains safe a long time.
I don't think it defends the little guy more than it defends the big
guy, but I agree with you that it's safe for the short term. The
current trends are towards extensions and expansion of copyright and
other I.P. protection. This is mostly driven by first-world nations
whose economies are largely driven by intellectual production.
--
Craig Brozefsky <·····@red-bean.com>
http://www.red-bean.com/~craig
"Indifference is the dead weight of history." -- Antonio Gramsci
Craig Brozefsky <·····@red-bean.com> writes:
> > When a country makes laws that offer big profits, big companies make
> > their nest there. It's good for the country (not the thing that
> > attracted the company per se, but having the company) and it's good
> > for the company.
>
> It's arguable wether it's good for the country, state or township.
> That largely depends on [...]
>
> > You might wish you could wish these large corporate animals
> > attracted each other by reasoned discussions of erudite issues like
> > Shakespeare and Plato, but "sex" among such entities of such a
> > global nature is just not constructed that way.
>
> I think the article only covers one part of the process of moving
> capital from the periphery to the center, [...]
You misunderstand my meaning of "good" here.
I was not making a moral analysis or a philosophical analysis.
I was saying the very definition of "good" in an environment of living
things is "what attracts mates". All else is secondary. I was not
talking about whether it gives them artereosclerosis in the process.
I was simply observing that there are mating entities and these are
the kinds of characteristics they choose for finding a good mate.
That's why I qualified it with "You might wish..."; it's not relevant.
I wasn't even saying I agreed with it. I was just making an observation
about what happens and why. Companies DO perceive that certain countries
have attractive modes of doing business. Countries that offer "better
upper bound on profits" are attractive.
> > I think copyright is safe for now. And, because copyright mostly
> > defends the "little guy", I hope it remains safe a long time.
>
> I don't think it defends the little guy more than it defends the big
> guy,
It allows me to feel comfortable publishing copyrighted works on the
net and not fear that a megabillion dollar corporation like Microsoft
will appropriate those works for their own purpose without asking me.
It is powerful enough to implement the GPL which Microsoft has so
recently railed against.
That's pretty darned powerful.
That it is even-handed in its protection, and doesn't merely redistribute
wealth downward does not make it less powerful or good. I didn't say
it didn't defend all fairly. I don't care about the size of the wallet of
other IP holders--they created their property and are entitled to its
defense, regardless of their pocketbook size. I said it defended ME,
and it does.
> but I agree with you that it's safe for the short term.
Weird use of the connective "but", to conjoin two unrelated statements.
Reminds me of one of my favorite weird quotes:
"The sun, though larger than the moon, is much farther away."
> The
> current trends are towards extensions and expansion of copyright and
> other I.P. protection. This is mostly driven by first-world nations
> whose economies are largely driven by intellectual production.
I will decline to expand the debate on this. We've been through this before.
Kent M Pitman <······@world.std.com> writes:
> You misunderstand my meaning of "good" here.
>
> I was not making a moral analysis or a philosophical analysis.
>
> I was saying the very definition of "good" in an environment of
> living things is "what attracts mates". All else is secondary. I
> was not talking about whether it gives them artereosclerosis in the
> process. I was simply observing that there are mating entities and
> these are the kinds of characteristics they choose for finding a
> good mate. That's why I qualified it with "You might wish..."; it's
> not relevant. I wasn't even saying I agreed with it. I was just
> making an observation about what happens and why. Companies DO
> perceive that certain countries have attractive modes of doing
> business. Countries that offer "better upper bound on profits" are
> attractive.
Yah, I did misunderstand your use of the term "good". I understood
"good" as meaning "beneficial to the general population of the
country". I was making an observation about what happens to the
economic situation of the people in certain of those countries, living
things that are trying to attract mates. I agree with your
observation.
The purpose of my mentioning the globalization of finance is that it's
becoming a major vector for the enforcement of intellectual property
law. In order to qualify for loans, countries are pressured to make
domestic changes, one of which is bringing their local IP law in line
with WIPO and other reccomendations. Also, the amount of direct
foreign investment in technology and other markets is influenced by
the IP regime at hand. In many ways, these influences on IP law are
more direct and powerful than the evolutionary force of "mating",
particularly when the issue for IP is predominantly opening and
safegaurding new markets. I was attempting to make the over-simplified
analogy of the article a little more useful for a discussion of
copyright and other IP regimes in our present condition.
> > I don't think it defends the little guy more than it defends the big
> > guy,
> That it is even-handed in its protection, and doesn't merely redistribute
> wealth downward does not make it less powerful or good.
Ok, I read the "mostly defends the little guy" in a way that implied
the amount it could defend was limited, so if it mostly defended the
little guy, it defended the big guy less. In retrospect, my reading
was predetermined by the questions I've been asking myself about
copyright and is not a very good understanding of the way copyright
"defends" authors.
> > but I agree with you that it's safe for the short term.
>
> Weird use of the connective "but", to conjoin two unrelated statements.
That conjuction was "conversational" in the way one might address
their disagreement with a minor point made by another person, and then
return to agree with their main point. It did not mean to imply a
logical connection.
> I will decline to expand the debate on this. We've been through this before.
Me too. I'm happy for the clarification.
--
Craig Brozefsky <·····@red-bean.com>
http://www.red-bean.com/~craig
"Indifference is the dead weight of history." -- Antonio Gramsci
Craig Brozefsky <·····@red-bean.com> writes:
> The purpose of my mentioning the globalization of finance is that it's
> becoming a major vector for the enforcement of intellectual property
> law. In order to qualify for loans, countries are pressured to make
> domestic changes, one of which is bringing their local IP law in line
> with WIPO and other reccomendations.
Well, I'm quite concerned about WIPO. I don't see that it really has
accountability to anyone. By the time it does something, even the countries
that are accountable to their people have little power to undo what might
have been done. If the decisions get reviewed at all.
So I guess I'd chalk this up under "life forms outside of country-level
control", too.
It's a curious thing that "life/intelligence" seems to be able to
occupy spaces at various meta-levels and yet not be able to
communicate across meta-levels. We think of people as intelligent,
but countries really are not... or to the extent they are, they are
not an obvious function of the intelligence of the populace making
them up. (In particular, the intelligence does not seem to grow with
the size of the population, nor even the size of the government.)
> Also, the amount of direct foreign investment in technology and
> other markets is influenced by the IP regime at hand. In many ways,
> these influences on IP law are more direct and powerful than the
> evolutionary force of "mating", particularly when the issue for IP
> is predominantly opening and safegaurding new markets.
Yes, that could be.
> I was attempting to make the over-simplified analogy of the article
> a little more useful for a discussion of copyright and other IP
> regimes in our present condition.
(The article was pretty extensive, and was discussed quite a lot
publicly at the time. I think I picked it up on Late Night with
Charlie Rose on CBS, before he moved to PBS. I was fascinated and
wrote the LA TIMES for a copy, something I've done only a couple of
times in my life. I could probably get a proper cite if you or anyone
cared. I hate to not do justice to someone else's thoughts.)
> them up. (In particular, the intelligence does not seem to grow with
> the size of the population, nor even the size of the government.)
How are you measuring and observing the former and why would you expect
the latter?
Populations consist of largely independent beings. However, increasing
the odds that <thing 1> occurs at least once by increasing the number of
opportunities for it to happen (that is, more people makes it more likely
that someone will stumble upon it through dumb luck or smarts) also makes
it harder to see when/where it happens. (If <thing 1> catches on, it
will become observable.)
However, govts are not largely independent beings. They grow in size
by getting more spheres of control and by doing more within a given
sphere. In the latter case, the odds that the smart person in the
organization is in the right place can go down as the size of
the organization increases. Since their spheres tend not to overlap,
and tend to push out other sources of influence, the net effect is that
you're less likely to get the right person on the job. The only
hope of counter-acting this is if the selection process somehow works.
Since success at problem isn't decisive in that process....
Yes, other monopolies have the same effect.
-andy
> It's arguable wether it's good for the country, state or township.
> That largely depends on which operations are situated in which
> country, and the flow of capital into or out of the company via those
> oeprations. In third-world countries the usual result is a minor
> influx of wage capital, with considerable outflow of profits to other
> countries and depletion of natural resources.
"Depletion of natural resources" is fairly industrial age. Today,
it tends to divert "noble savage" labor into something that we'd
call sweatshops, something that the "savages" strongly prefer to
THEIR alternatives.
When Nike comes to town, it doesn't enslave people who would otherwise
be going to Harvard Law. Unlike their previous trade, Nike sweatshops
put them on the industrialization track so that their great-grandchildren
have a hope of attending either Harvard Law or the local equivalent
that will spring up. (That is, after all, how Harvard Law came to be.)
Yes, Nike makes a lot of money. If that offends, feel free to set up
your own company, pay more, and sell for less. You'll do good, drive
out evil, and have some spare nickles to do more good. That's as close
as you'll find to a moral obligation. (Or, maybe you'll find that the
economics don't work the way the end-price vs labor comparisons suggest.)
Also, one might reasonably argue that it's better to pick berries than
negotiate merger deals. However, it's better still to have the choice.
(Picking berries is a lot more fun when it isn't the only thing between
you and starvation, and picking berries doesn't get you to that position.)
-andy's done farm labor and is grateful for the chance to do otherwise
······@earthlink.net (Andy Freeman) writes:
> > It's arguable wether it's good for the country, state or township.
> > That largely depends on which operations are situated in which
> > country, and the flow of capital into or out of the company via those
> > oeprations. In third-world countries the usual result is a minor
> > influx of wage capital, with considerable outflow of profits to other
> > countries and depletion of natural resources.
>
> "Depletion of natural resources" is fairly industrial age.
Yes it is. However, what we have in these situations is a colonial
exploitation of the natural resources of a country with the cost of
infrastructure for that exploitation being put onto the public's head,
and the profits being almost entirely taken out of the country.
Indeed this has gone on for quite some time, as it is a basic function
of imperialism.
> Today, it tends to divert "noble savage" labor into something that
> we'd call sweatshops, something that the "savages" strongly prefer
> to THEIR alternatives.
This is a very common argument, but I have never seen anything but
anecdotal evidence to "support" it. For one, everyone outside the
first-world is not a subsistence farmer. There is not this decision
between borderline starvation thru farming and scavenging and working
in a sweatshop where suddenly starvation is not a problem. Secondly,
the 10k that get the sweatshop jobs may appreciate their increased
earnings over their countrymen (money works that way, it's how much
you have in RELATION to others in the market that determines it's
value) but that doesn't address the effects it has on the population
as a whole. Lastly, why should they, or anyone for that matter, be
satisfied with subsistence labor?
We're getting quite off-topic now.
--
Craig Brozefsky <·····@red-bean.com>
http://www.red-bean.com/~craig
"Indifference is the dead weight of history." -- Antonio Gramsci
>>>>> "Craig" == Craig Brozefsky <·····@red-bean.com> writes:
>> Today, it tends to divert "noble savage" labor into something that
>> we'd call sweatshops, something that the "savages" strongly prefer
>> to THEIR alternatives.
Craig> This is a very common argument, but I have never seen anything
Craig> but anecdotal evidence to "support" it. For one, everyone
Craig> outside the first-world is not a subsistence farmer. There is
Craig> not this decision between borderline starvation thru farming
Craig> and scavenging and working in a sweatshop where suddenly
Craig> starvation is not a problem.
As I understand it, one common source of cheap labor comes from
forcing open agricultural commodity markets in developing countries
and then flooding the local markets with cheaper imports. This
destroys the local agricultural markets and turns people who were
doing okay farming into lots of unskilled labor which can be hired
cheaply. Whatever the benefits of global trade, I think food and
agricultural productive capacity are important enough to allow each
country to protect and stabilize their local agricultural economies,
something the rich industrialized nations have never really stopped
doing.
--
Russell Senior ``The two chiefs turned to each other.
·······@aracnet.com Bellison uncorked a flood of horrible
profanity, which, translated meant, `This is
extremely unusual.' ''
> As I understand it, one common source of cheap labor comes from
> forcing open agricultural commodity markets in developing countries
> and then flooding the local markets with cheaper imports.
Yup, evil Nike imports cheap food.
> This
> destroys the local agricultural markets and turns people who were
> doing okay farming into lots of unskilled labor which can be hired
> cheaply.
That can't be true after the food imports fall below the level required
by the population. When the local sweatshop pays more than raising
food, they show up. When it doesn't, they go back to whatever. Clever
devils - they don't stay with inferior options.
> Whatever the benefits of global trade, I think food and
> agricultural productive capacity are important enough to allow each
> country to protect and stabilize their local agricultural economies,
> something the rich industrialized nations have never really stopped
> doing.
If this sentiment had ever done poor people any good, that would be
one thing. However, since the policies that have resulted from this
sentiment have generally been a horror, I think that it's repugnant.
No, the consequences haven't been as fatal in rich countries, but "we
hose our people this way" has never gotten much credit with me, especially
if the results are worse for the person being sold out. Your mileage
may vary.
-andy
Andy Freeman <······@earthlink.net> wrote in message
·································@posting.google.com...
> > As I understand it, one common source of cheap labor comes from
> > forcing open agricultural commodity markets in developing countries
> > and then flooding the local markets with cheaper imports.
>
> Yup, evil Nike imports cheap food.
Nope - evil EU exports food for less than they produced it, indeed for
less than anyone not massively subsidised could produce it.
> > This
> > destroys the local agricultural markets and turns people who were
> > doing okay farming into lots of unskilled labor which can be hired
> > cheaply.
>
> That can't be true after the food imports fall below the level required
> by the population. When the local sweatshop pays more than raising
> food, they show up. When it doesn't, they go back to whatever. Clever
> devils - they don't stay with inferior options.
The other option being inferior because we (by which I mean the EU; I
don't know if NAFTA nations follow similar policies) destroyed it.
> > Whatever the benefits of global trade, I think food and
> > agricultural productive capacity are important enough to allow each
> > country to protect and stabilize their local agricultural economies,
> > something the rich industrialized nations have never really stopped
> > doing.
>
> If this sentiment had ever done poor people any good, that would be
> one thing. However, since the policies that have resulted from this
> sentiment have generally been a horror, I think that it's repugnant.
Hundreds of thousands of farmers incapable of producing food
efficiently, dependant on a manipulated market, yet still inexplicably
poor - welcome to Europe. The contrast is that many third world countries
can produce agricultural goods more efficiently than the west, and more
efficiently than anything else, allowing them to keep the profits for
themselves, develop, etc.
In article <····························@posting.google.com>,
Andy Freeman <······@earthlink.net> wrote:
>> As I understand it, one common source of cheap labor comes from
>> forcing open agricultural commodity markets in developing countries
>> and then flooding the local markets with cheaper imports.
>
>Yup, evil Nike imports cheap food.
>
One common practice is for a multinational agricultural company to
acquire the local farmland and produce export crops, which eliminates
the possibility that the locals can go back to subsistence farming
if they don't like the sweatshops. This acquisition is not normally
done in true free-market style. Note that undeveloped societies
usually can't support a government of a large country in the Western
sense, and so the governments that do exist tend to be corrupt. If
one isn't, by chance, it can always be removed on some pretext or
another.
Bringing subsidized products into a country for purposes of
destroying the native production ability is called "dumping",
and is normally criticized. When it's done to countries we care
about, anyway.
>> This
>> destroys the local agricultural markets and turns people who were
>> doing okay farming into lots of unskilled labor which can be hired
>> cheaply.
>
>That can't be true after the food imports fall below the level required
>by the population. When the local sweatshop pays more than raising
>food, they show up. When it doesn't, they go back to whatever. Clever
>devils - they don't stay with inferior options.
>
The usual practice is to remove much of the land from subsistence
farming, perhaps changing over to export crops. Once this is done,
the population is at corporate mercy (or what the corporations use
instead).
>> Whatever the benefits of global trade, I think food and
>> agricultural productive capacity are important enough to allow each
>> country to protect and stabilize their local agricultural economies,
>> something the rich industrialized nations have never really stopped
>> doing.
>
>If this sentiment had ever done poor people any good, that would be
>one thing. However, since the policies that have resulted from this
>sentiment have generally been a horror, I think that it's repugnant.
>
Why? Where has this sentiment been put into policy? The horror
stories of economic development come from the destruction of the
local economy, in general. Once the local economy is destroyed,
the corporate exploiters can get people for near-starvation
compensation and dispose of them when convenient.
I'm open to horror stories about third-world countries that have
kept their economies and food production intact, but I am going
to verify them.
>No, the consequences haven't been as fatal in rich countries, but "we
>hose our people this way" has never gotten much credit with me, especially
>if the results are worse for the person being sold out. Your mileage
>may vary.
>
I don't quite understand it. In a desperate attempt to stay vaguely
on-topic, could you repeat that in Common Lisp?
--
David H. Thornley | If you want my opinion, ask.
·····@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
> >> Whatever the benefits of global trade, I think food and
> >> agricultural productive capacity are important enough to allow each
> >> country to protect and stabilize their local agricultural economies,
> >> something the rich industrialized nations have never really stopped
> >> doing.
> >
> >If this sentiment had ever done poor people any good, that would be
> >one thing. However, since the policies that have resulted from this
> >sentiment have generally been a horror, I think that it's repugnant.
> >
> Why? Where has this sentiment been put into policy? The horror
> stories of economic development come from the destruction of the
> local economy, in general.
And one of the "best" excuses for destroying the local economy has
been that sentiment. "We're going to save you" has had roughly the
same effect as "we're going to enslave you", except that it gets all
the right people to sign on and praise the camp building.
Of course, those people weren't doing it right. Or, "their culture
just lends itself to excesses". Or "how were we to know that the
thugs would take over". And so on.
> I'm open to horror stories about third-world countries that have
> kept their economies and food production intact, but I am going
> to verify them.
You're confusing intent with result. That sentiment is used to
promise one thing, but it delivers something else; it doesn't
deliver intact economies or food production.
> I don't quite understand it. In a desperate attempt to stay vaguely
> on-topic, could you repeat that in Common Lisp?
>> (+ 1 2)
3
>> ; something's wrong, I wanted 5
>> (+ 1 2)
3
>> ; Okay, I'll try something different
>> (+ 2 1)
3
>> ; Okay, I was right the first time
>> (+ 1 2)
3
>> ; okay, I need to break things down more
>> (+ 1 (+ 1 1))
3
>> ; let's try it again
>> (+ 1 (+ 1 1))
3
>> ; okay, now I see the problem
>> (+ 1 2) (+ 1 2) (+ 1 2)
....
-andy
From: Marcin Tustin
Subject: Barely on topic rant about agriculture - was Re: Engineering Envy [was: Re: CL and UML]
Date:
Message-ID: <9i7oa4$r4e$2@newsg4.svr.pol.co.uk>
Russell Senior <·······@aracnet.com> wrote in message
···················@coulee.tdb.com...
> >>>>> "Craig" == Craig Brozefsky <·····@red-bean.com> writes:
>
> >> Today, it tends to divert "noble savage" labor into something that
> >> we'd call sweatshops, something that the "savages" strongly prefer
> >> to THEIR alternatives.
>
> Craig> This is a very common argument, but I have never seen anything
> Craig> but anecdotal evidence to "support" it. For one, everyone
> Craig> outside the first-world is not a subsistence farmer. There is
> Craig> not this decision between borderline starvation thru farming
> Craig> and scavenging and working in a sweatshop where suddenly
> Craig> starvation is not a problem.
>
> As I understand it, one common source of cheap labor comes from
> forcing open agricultural commodity markets in developing countries
> and then flooding the local markets with cheaper imports. This
> destroys the local agricultural markets and turns people who were
> doing okay farming into lots of unskilled labor which can be hired
> cheaply. Whatever the benefits of global trade, I think food and
> agricultural productive capacity are important enough to allow each
> country to protect and stabilize their local agricultural economies,
> something the rich industrialized nations have never really stopped
> doing.
Clearly, it would be massively wrong for ghana (or wherever) to protect
agriculture; meanwhile it is excellent for the industrialised nations to
massively subsidise farmers' production, then when they produce so much that
it is worth next to nothing at sale, the state (or states, as in the EU) to
buy lots of it and burn it, or dump it on the world agricultural market.
Bear in mind that although almost worthless at sale, the farmers have
already been paid for it (through subsidy). Also, if they sell outside their
trade community, they get paid more by the state. Selling it on the world
markets then massively depresses the price (because the farmers can give it
away and be guaranteed of income), so that farmers not massively subsidised
can't compete, no matter how efficient they are. Liquidate the Western
farmer! Make him sink or swim on his own feet (and hands, and other major
bits applicable in swimming).
From: Tim Bradshaw
Subject: Re: Barely on topic rant about agriculture - was Re: Engineering Envy [was: Re: CL and UML]
Date:
Message-ID: <ey3r8vspflq.fsf@cley.com>
* Marcin Tustin wrote:
> Clearly, it would be massively wrong for ghana (or wherever) to protect
> agriculture; meanwhile it is excellent for the industrialised nations to
> massively subsidise farmers' production, then when they produce so much that
> it is worth next to nothing at sale, the state (or states, as in the EU) to
> buy lots of it and burn it, or dump it on the world agricultural market.
> Bear in mind that although almost worthless at sale, the farmers have
> already been paid for it (through subsidy). Also, if they sell outside their
> trade community, they get paid more by the state. Selling it on the world
> markets then massively depresses the price (because the farmers can give it
> away and be guaranteed of income), so that farmers not massively subsidised
> can't compete, no matter how efficient they are. Liquidate the Western
> farmer! Make him sink or swim on his own feet (and hands, and other major
> bits applicable in swimming).
This is completely off topic, so I should shut up. But, at least in
the UK, this is a really horrible problem. Clearly farming is
subsidised hugely and clearly this is not a good thing in a lot of
ways. But the simple answer - stop doing that - means that farming
probably simply stops in the UK to first order (like, say,
steel-making has all-but stopped). Well, OK, so what, is this a bad
thing? Maybe not. Unfortunately it *is* a bad thing, because our
landscape is a result of thousands of years of farming. If you just
stop things change, quite fast, and not perhaps in good ways. We're
not a country with huge bits of untouched wilderness - even the bits
people think of as wilderness like the highlands of Scotland are
actually manufactured landscapes (manufactured by sheep farming in
this case). So you can't just stop in the UK, or at least not without
huge impact on the environment we live in. But the current situation
is clearly fouled-up beyond belief. I think, personally, that the
right solution is to explicitly say that much of the purpose of
farming in the UK is to preserve our landscape, and aim funding at
*that* rather than at something else which might incidentally achieve
that, but actually doesn't very well.
So really, perhaps it's less off-topic: the thing that seems to me
important in all this is to make sure you direct money, or effort, or
whatever at what you actually want to achieve, rather than at
something else which might help you to achieve what you want. I've
always been suspicious of business models which rely on this kind of
finessing. Things like Tivo are a good example - you need a
subscription - why? I guess so they can data-mine your viewing habits
or something. Why not just sell you the box that does the cool things
you want. Mobile phones were for a long time similar (phone hugely
subsidised, binding contract used to fund the cost), but may be
becoming less so now.
Anyway, enough off-topicness from me anyway
--tim (from a farming family in the UK)
From: Erik Naggum
Subject: Re: Engineering Envy [was: Re: CL and UML]
Date:
Message-ID: <3203512900471009@naggum.net>
* Andy Freeman
> Today, it tends to divert "noble savage" labor into something that
> we'd call sweatshops, something that the "savages" strongly prefer
> to THEIR alternatives.
* Craig Brozefsky
> This is a very common argument, but I have never seen anything but
> anecdotal evidence to "support" it.
Are they forced somehow to work in the sweatshops? If you can
demonstrate that they are, you may have a point. If you cannot, and
those who work there _could_ go back to whatever they came from, what
kind of evidence do you need? If you imply that they "have" to work
there because they would otherwise starve, which is the usual stupid
argument against child labor and sweatshops and other forms of "we think
of this as slavery, seen from the other side of the world on TV, only",
please let it occur to you that being saved from starvation is pretty
good, even if the alternative to death by starvation is some other form
of misery, as seen with Western comfort standard.
It is rather obvious to me, but maybe it needs to be said: Those who have
the option of better work than that in sweatshops would have to be forced
to work in them. There has never been any evidence of such force. Those
who are provided with a miserable standard of living that differs from a
miserable standard of dying by a lot more than most Western do-gooders
are willing to think about, somehow conjure up a fantasy world in which
these people would _not_ die if the sweatshop disappeared.
> Lastly, why should they, or anyone for that matter, be satisfied with
> subsistence labor?
Well, it sure works wonder to be dissatisfied with the only better choice
you have. That sure makes people elsewhere interested in giving them
even _better_ choices. It also certainly makes the population happier
about the improvement they have seen in their lives and therefore willing
to _invest_ in their own future. If they are _satisfied_ with the fact
that this is a step in the right direction, they will take another. If
they are dissatisfied with that step, they will take no more of the same
kind. This does not only happen in those foreign countries where the
contrasts are so stark that any unthinking couch potato can be hurled
into emotional engagement in such matters, it also applies to single
parent families that subside on social security and who are discouraged
from getting a job because the net disposable time*income is much lower.
In such cases, a job is step _down_, with which people are dissatisifed,
hence nothing ever happens.
Those who make those sweatshops look so awful to the people who may have
forgotten what other options they [do not] have, destroy not only their
financial livelihood now, but their psychological livelihood for most of
their future, too.
> We're getting quite off-topic now.
Not really. This is all about why some people "prefer" C++. :)
#:Erik
--
Travel is a meat thing.
Erik Naggum <····@naggum.net> wrote in message
·····················@naggum.net...
> * Andy Freeman
> > Today, it tends to divert "noble savage" labor into something that
> > we'd call sweatshops, something that the "savages" strongly prefer
> > to THEIR alternatives.
>
> * Craig Brozefsky
> > This is a very common argument, but I have never seen anything but
> > anecdotal evidence to "support" it.
>
> Are they forced somehow to work in the sweatshops? If you can
> demonstrate that they are, you may have a point. If you cannot, and
> those who work there _could_ go back to whatever they came from, what
> kind of evidence do you need? If you imply that they "have" to work
> there because they would otherwise starve, which is the usual stupid
> argument against child labor and sweatshops and other forms of "we think
> of this as slavery, seen from the other side of the world on TV, only",
> please let it occur to you that being saved from starvation is pretty
> good, even if the alternative to death by starvation is some other form
> of misery, as seen with Western comfort standard.
Now you're getting into the issue of to what extent are people free to
do
something, or not do that. Earning that money may satisfy a need other than
survival, a need that we may not even understand. Just because you can use
the fact that someone desires something to persuade them to serve your
purposes, does not mean that you are not exploiting them - you may know
that if they held out, you would pay them more, for instance, and that you
are
exploiting their desparation, so that they will not question what you have
to
offer.
The fact is that one can always produce objections that people are not
free
to not do something. Therefore you will have to take a stand and accept some
fairly arbitrary criteria. Not everyone will make the same choice.
> Not really. This is all about why some people "prefer" C++. :)
Ignorance. I have a friend who ridicules the idea of using Lisp "Because
it's
an AI/Neural net/blah blah language" while Pascal (Or rather delphi) is
clearly
fantastic - not that he offers any reason. Such reasons might be that it was
designed for use in projects that could be well designed, and mathematically
verified - a reason why he doesn't is that he is deeply opposed to formal
methods and any kind of software engineering - this includes such things as
a
formal process to follow (at all), or the creation of documentation. (Yes,
we
are students).
> Now you're getting into the issue of to what extent are people free to
> do
> something, or not do that. Earning that money may satisfy a need other than
> survival, a need that we may not even understand. Just because you can use
> the fact that someone desires something to persuade them to serve your
> purposes, does not mean that you are not exploiting them - you may know
> that if they held out, you would pay them more, for instance, and that you
> are
> exploiting their desparation, so that they will not question what you have
> to
> offer.
If "you'd take less" proves exploitation, the vast majority of agreements
are exploitive by BOTH parties and almost all are exploitive by at least
one party.
Of course, "exploitation" is really intended as an emotional appeal.
For some reason, these people prefer what we'd call sweatshops to THEIR
alternatives. That isn't exploitation, even if you won't work without
an Aeron chair. Exploitation is destroying their options for your
benefit.
Moreover, if you're right about the numbers, you can easily solve the
problem, drive out evil, and get the resources to do even more good.
Yet....
-andy
"Andy Freeman" <······@earthlink.net> wrote in message
·································@posting.google.com...
> For some reason, these people prefer what we'd call sweatshops
> to THEIR alternatives. That isn't exploitation, even if you
> won't work without an Aeron chair. Exploitation is destroying
> their options for your benefit.
I don't know about the specific sweat shop situation, but in many cases the
situation is not that simple. Nestle approaches farmers in Ivory Coast,
and tells them that if they produce cocoa, it will buy it. Prices are
high, for local standards, so people ditch their yams and plant cocoa.
After a few years, Nestle tells them "sorry, the world market is bad,
prices go down", and pays them less than they need to survive, and many
farmers literally starve to death.
Is it their own fault, because they somehow had an obligation to know what
a "world market" was, or that Nestle chooses not to behave like a patron
(even if they are fuly aware of the client-patron system)?
IF these sweat shop workers have been lured into an economic trap, I should
call that exploitation.
--
Biep
Reply via http://www.biep.org
From: Erik Naggum
Subject: Re: Engineering Envy [was: Re: CL and UML]
Date:
Message-ID: <3203922895939197@naggum.net>
* "Biep @ http://www.biep.org/" <·········@my-web-site.com>
> Prices are high, for local standards, so people ditch their yams and
> plant cocoa.
Why did they _all_ switch to cocoa? If ther prices were high, did they
not engage in long-range planning and _save_ some of it, or spend some of
it on less productive things that they could not have afforded before,
but which would have been a very, very smart thing to have done while
they had excess funds?
> After a few years, Nestle tells them "sorry, the world market is bad,
> prices go down", and pays them less than they need to survive, and many
> farmers literally starve to death.
Why could they not return to yams when the price of cocoa dropped below
the value of yams? That would seem to happen long before anyone starved
to death. Also, you cannot eat money, so if you are a farmer, with all
the immense risks that involves, it is very, very stupid not to maintain
crops that can sustain yourself. Or perhaps they did that stupid human
trick that never fails: If you have excess funds, procreate until you no
longer have excess funds, then share the funds equally until you all die.
It looks like these people _planned_ to starve if their assumptions (or
promises, but you have to _believe_ promises) about the price of cocoa
did not hold. (I know, I know, Norway has done that with its oil, but
the Ivory Coast folks should have known better with cocoa. :)
> IF these sweat shop workers have been lured into an economic trap, I should
> call that exploitation.
The problem is that "exploitation" happens only to people stupider (and
consequently less informed) than the "exploiter". The root cause of this
whole world problem is that some people are smarter than others. There
are two basic solutions to this problem: Kill all the morons, or kill all
the brains. If you look at how several political regimes have behaved
throughout history, you might get the impression that they are precisely
adopting one of those two options. (Social democracy is a little more
advanced: Kill everything outside 2 sigma.) World history and evolution
and nature in general keep telling us something we humans do not want to
hear: Some people _have_ to die for the rest of us to live better. The
only question that political systems can answer is _who_ gets to live or
die. Those who do not realize this will not live well before they die
young. Our current political systems have created a world where people
are afraid that we are not "sustainable". Of course we are not. But
instead of killing contemporary people, we are killing future people. It
is definitely not sustainable to keep everybody alive forever. We will,
eventually, resort to killing a lot of people, and I mean a _lot_, like
probably half of the planet's population, because, like fruit flies in a
laboratory jar that runs out of sugar, we will be too many before we get
the point. And that is OK with me, I do not plan to hang around forever,
and neither do I want children to make things worse. But in the end,
nature exploited us, not vice versa, because people are generally stupid
and ill-informed about the choices they make. (Which is probably what
some people _really_ mean when they say people are not rational.)
What we need is a very powerful, very smart, very well-informed world
leader, and it should be programmed in Common Lisp, to make that
gratuitous Common Lisp relevance again.
#:Erik, cynic at large
--
Travel is a meat thing.
"Biep @ http://www.biep.org/" <·········@my-web-site.com> wrote in message
···················@ID-63952.news.dfncis.de...
> Is it their own fault, because they somehow had an obligation to know
what
> a "world market" was, or that Nestle chooses not to behave like a patron
> (even if they are fully aware of the client-patron system)?
All right, it seems I wasn't clear here. Below I include an article on
patron-client relationships. It is from the Ethno-Info, which is directed
at a Christian readership, which is rather obvious from the text, I think,
but not the point here.
My point was that Nestle misused (and misuses) the PCR: it is fully aware
that the people it deals with are convinced Nestle will become their
patron, and then it doesn't when it is too late (farmland has been turned
into woodland, people have contracts or debts forcing them to produce cash
crops, the traditional subsistence crops have all but disappeared from the
region, and the people have become dependent on money).
Yes, these people sign contracts, but what does a stupid piece of paper
mean to them? The fact that we in the West get all worked up over
contracts and signatures doesn't mean that it has any significance in their
culture - if your patron asks you do do something, including signing a
paper, of course you do it.
Nestle steps into THEIR culture; why should they have an obligation to know
about Nestle's culture?
Oh, and some people there lisp.. :-)
--
Biep
Reply via http://www.biep.org
OF PATRONS, CLIENTS AND PIETY
Why do we, as regular customers at this market stand, pay a higher price
than one-time customers? And why does that woman address her husband with
�big brother�? These, and many other issues from daily life in Africa can
not be understood without a good insight into a work relationship that has
largely disappeared from the Western world, but that is still quite alive
in Africa: the relationship between a working �client� and a care-giving
�patron.� This relationship is created naturally in the family: a young
child depends for all its needs upon the parents as patrons; they have the
duty to take care of him or her. On the other side, the child, as client,
has the duty to do without grumbling whatever his parents ask.
The terms �patron� and �client� come from the Latin language, but the
phenomenon is well known in large parts of the world, including Africa. The
correct behavior within such a relationship was called pietas in Latin.
Pietas has come into modern English in two forms: piety (from client to
patron) and pity (from patron to client).
Patron-client relationships color all aspects of African life. If one hires
a housekeeper in Africa, one shouldn�t be amazed if she comes regularly to
complain about financial problems, or asks for all kinds of goods that she
says she needs. Doesn�t she work (as a client) for her boss? Therefore, the
boss is her patron and has the duty to take care of her like a father. If
she doesn�t have any problems, she probably will make one up, to honor her
patron. She also will easily address her boss as �patron,� �daddy,� or �big
brother,� to clarify that bond. A patron-client relationship here is
usually expressed in family terms. One of the first things that we had to
learn here as westerners is that relationships are hardly ever formed
simply on business terms. You cannot make a deal such as: �You do this for
me, I pay you, and that is all.� Such a relationship undeniably makes one a
patron and the other a client, with resulting expectations and duties.
But what about that price at the market? Well, in the market the buyer is
the patron of the seller, so it is logical that the seller, if he has a
financial problem, tries to solve it through his patrons (the regular
customers). On a subsequent occasion it is returned with a reduction, or
even better, in kind.
Sometimes people try to maneuver you into an instant-patron position.
Handicapped people would easily address us as �patron,� or �big brother,�
to give us the feeling that it is our duty to care for them. On the other
hand, we can give them various assignments: �Watch our car until we
return,� �Show us the way to the fish market,� or �Buy some bread for us
somewhere.� When they return with the bread we give them somewhat more than
the price, so that they have worked for us and we took care of them.
OF A GARDENER AND A MASON
When we, in a village close to Dogon land, rented a house from a
missionary-on-leave, a mason/handyman and a boy for the garden were
included in the rent. When the missionary had settled in the village she
was greatly helped by the Christian headmaster of the local agricultural
school. This man had found a mason to build her house, and when we came he
still worked there regularly. When, later, she sought someone to keep the
yard, the headmaster had found her a boy from his own family ready to take
this job. So, immediately we had two clients.
With the mason we got along right away. What we asked him he did with care,
and in return we could help him once or twice with an advance on his salary
or with transportation to town if necessary. Accordingly, we felt like
accomplished patrons. However, our relationship with the gardener wouldn�t
run smoothly. He didn�t do what we assigned him to do, made problems about
everything we asked him to do, and often mingled himself in the way the
mason did his work. We just let it take its course, because we didn�t want
to ruin the situation for the missionary. Nevertheless, the difficult
relationship bothered us.
This lasted more than five months, until the boy, during a small conflict
with us, suddenly flared up and actually ordered us formally out of the
garden. This was improper behavior for a client, so according to the rules
we called on the �big brother,� the head of the school and family.
Big brother arrived and accepted his role as judge. A judge here is
something quite different than a judge in the Western world. In our society
the role of the judge is to speak judgment: to determine who is guilty and
how much punishment fits the crime. The task of a judge in West Africa,
however, is to reconcile the two parties, so that those will go their way
in peace, without resentment.
After hearing both our versions, he gave a speech. To us he mainly made
clear that his �small brother� didn�t work here because of the money, but
because of the relation that he, the school principal, had with the
missionary. The missionary had had a problem, and he had solved it by
sending a family member to work here. Even without an income the boy would
have worked here. To the garden boy he also spoke for some time about good
relationships, and after that he spoke to the three of us as if to small
children: ��Let me hear no more bickering. Apologize and let that be the
end.�
With that the argument was solved, but it was only later that evening that
we started to realize what he had really said. He was the patron of the
missionary, and therefore, indirectly, also of us (that is why he could
address us as little children). The missionary had had a problem, and he,
as patron, had solved that problem in the shape of sending one of his
family members to work for her. That family member therefore represented
big brother, and was in that function the patron of the missionary, and
thus also of us.
No wonder that the gardener interfered with the work of the mason, for wasn
�t he, as patron, responsible for what the man did for us? No wonder he
didn�t accept any assignments from us. A client can�t possibly tell his
boss what to do. No wonder also that he made a problem of everything: a
client goes to his patron when he has a problem. The gardener showed us
only that he took our problems seriously as problems, no matter how small
they seemed to be.
It showed again how being raised in a Western world can make us blind for
the reality: who would expect that the boy who takes care of the yard is in
reality your boss?
OF BIG AND SMALL BROTHERS
In most African languages no word exists for �brother�: there are only
separate words for �big brother� and �small brother,� that is how different
those roles are. That, of course, has consequences for Bible translators.
For example, which word should be used in John 1:40-41? In Acts 1:16? This
shows again clearly how every translation out of necessity adds or deletes
things, and how rich we are, that we can compare different translations in
our own language and can consult commentaries in order to discover the
meaning of the Original!
It can be yet more difficult. On a dangerous journey a big brother will, as
a patron, always follow the small brother, so that he can keep an eye on
him. This is so common in West Africa, that with the birth of a twin the
second born can only be the eldest, who allowed the younger to go first.
Then try to translate the story of Jacob and Esau and the birthright, in a
culture that names the last-born twin automatically the elder!
OF WORDLISTS AND VILLAGE ELDERS
Another aspect of the patron-client relationship is the respect. A patron
derives respect from his clients, and therefore a client may never harm the
respect of his patron. This can also lead to unusual situations. One of the
things that we do is taking word lists in several villages, in order to
compare those for language relationship. There we are, in such a village,
with the village chief and the village elders under the meeting roof, while
a group of youths surrounds us. Some of these youths have gone to school
and know French, and one of them is named to be translator.
We ask our first word: �eye�. The translator neatly gives us the local word
in return, but then the village chief suddenly speaks, and says something
completely different. He doesn�t know French, but felt that he understood
what we meant. The reaction of the translator and the bystanders is such
that we immediately understand that the village chief is wrong, but nobody
wants to give us the correct translation; that would mean that the village
chief was wrong, and that would be disrespectful towards him.
The same happens with the next word and after that again. In the meantime
the translator waits politely until the village chief has spoken. It is
clear that we�ll have to repeat this wordlist in a neighboring village.
So now we do it differently: we present the translation of the wordlist as
a dull chore, for which we ask a �kid� who knows French. In this way it is
client work from which the village elders keep themselves far removed. And
the youths, between themselves, correct each other, which improves the
quality of the list.
OF A FATHER AND A BIG BROTHER
In the Biblical culture as well patron/client was the normal relationship
between free people, and one of the radical aspects of Jesus� message was
therefore that we children might be clients of God. No longer slaves for
whom only the livelihood was provided, but clients who may throw all their
problems unto their patron. We may address God as Father, and Jesus is our
Big Brother (Ro 8:29), in other words, a patron who is entitled to our
obedience and respect, and who is personally responsible to make sure that
our problems will be solved.
In the Western world the image of Jesus as brother sometimes clashes with
his position as Lord, but that combination is quite normal here in Africa.
A big brother is always lord, and in that respect entitled to all honor. We
experience it as very refreshing to read the Bible with an eye for patron-
client relationships, from Paul�s call on the emperor (as patron of all the
Roman citizens) to Jesus� relationship towards Mary.
The latter is described quite elaborately. First He was, as child,
submissive, although he received, during His Bar Mitzvah, a new patron
(Luke 2:49, 51). As He becomes an adult He stops being Mary�s client and
becomes her patron; when she wants to ask him to perform a miracle (John
2:3), He points out to her that He will decide Himself when He will start
His miracles. On the other hand He knows Himself responsible for her
problem, and solves that as well.
When she wants to call him out of his serving he refuses to obey (Mark
3:21, 31). And finally, on the cross, He turns His patron responsibilities
for her over to John (John 19:26-17).
Every Easter we celebrate that our Patron, out of pity, went to the very
end; may we learn to live as clients deserving of Him, looking up to him
with piety.
From: Erik Naggum
Subject: Re: Engineering Envy [was: Re: CL and UML]
Date:
Message-ID: <3204288502691393@naggum.net>
* "Biep @ http://www.biep.org/" <·········@my-web-site.com>
> Yes, these people sign contracts, but what does a stupid piece of paper
> mean to them? The fact that we in the West get all worked up over
> contracts and signatures doesn't mean that it has any significance in
> their culture - if your patron asks you do do something, including
> signing a paper, of course you do it.
Well, if nothing else, this certainly explains why they do not eveolve
reasonable economies or legal systems and why the whole continent reeks
of corruption. It is so tremendously sad to see what a bad culture can
do to good people and how much it can keep them back. Stamping out bad
cultures should have been one of the United Nations' primary missions.
But, tragically, it cannot be. We show "respect" for people by trying to
pretend that we think they know what they are doing, if they are harming
themselves in the name of some "culture". People in our own culture who
"invented" the same insanity would be put in jail or in hospital, but,
instead of telling people to snap out of it, we "respect" other cultures
through a process of extremely demeaning and denigratory "we do not think
you could do any better, so it is OK for you to do those insane things".
The only _real_ evidence of a lack of belief in cultural or racial
superiority is in the ability to get angry at people who do stupid and
harmful things, regardless of which culture they (seem to) come from. If
you actually think someone who does something stupid and harmful must be
protected from criticism because of his culture or his skin pigmentation,
you are a racist. Otherwise, what is so different about some stupid
culture who gets everyone supposedly screwed by "globalization" and a
gang of idiot youths who take psychoactive drugs that seriously damage
their brains? Both are _cultures_ and they should be left alone, right?
> Nestle steps into THEIR culture; why should they have an obligation to
> know about Nestle's culture?
Yeah, right. And when people from the same culture come to the "West",
their "culture" must be protected from "Western influence". So either
way, Western culture should not influence these poor hapless bastards and
it is all our fault that they get screwed over because they are stupid.
Put their retarded cultures in a museum and give the people who obviously
suffer from them a _real_ chance, dammit. The problem is not so-called
exploitation, it is that their cultures are unable to withstand attempts
to _be_ exploited, both on the societal and the personal level, and those
attempts will _always_ occur. Please recall that the evil white dudes
who "enslaved" all those Africans never actually trapped or caught _any_
of them themselves -- why bother when they could just purchase them from
the tribes that more than willingly enslaved members of other tribes,
because slavery had certainly been the accepted policy among themselves
in those _bad_ cultures for many millennia. We white guys may not have
the _right_ answer, but we most certainly do have a _better_ answer than
crappy cultures like that. (That we in fact embraced slavery of our own
people and other tribes not _that_ many years earlier is no more than
evidence that we also were once pretty crappy, but at least we figured it
out in time. However, today we are dead set on _inventing_ the slave,
instead -- through machines, computers, and robots. The idea of having
someone to command that will do any damn idiotic task you give it has not
exactly died. In fact, many managers still believe in slavery, a stupid
cultural thing that led to such disasters as labor unions and communism,
neither of which would have happened if the people in power had had any
brains at all. But brains may not be enough: ask any graduate student
about his professor's personal beliefs on slavery.)
Regardless of how one views _any_ culture, everyone has an obligation to
himself, and a duty to those who might pick up the pieces afterwards, to
figure out as best he can what he is getting himself into. Failure to do
so cannot be explained by blaming a retarded culture that has failed to
develop the concept of planning. Some stupid mistakes people make cause
death. This is a fact of life. It is true whether it involves reckless
disregard for personal safety around fire, guns, or electricity, or
abandoning your livelihood for somebody else's promises, "patron" or not.
Stupid cultures who believe in patrons die. Smart people in those
cultures get out before it is too late. I for one welcome anyone who has
the guts and brains to escape from such a retarded culture. (But I am
also inclined to send those back who bring their culture with them and
demand protection from the realities of what they have chosen.)
I do not believ that the "victims" of "globalization" are victims. I
believe they are trying to enforce their crappy cultures on "us" much
more than "we" are trying to impose ours on them. Those who favor those
cultures and still live in the "West" could just move to their favorite
cultures and live there instead of trying to get anyone to adopt the
backward, retarded cultures that are so easily "victimized".
> Oh, and some people there lisp.. :-)
I appreciate that the "gratuitous Lisp relevance" idea has caught on.
#:Erik
--
Travel is a meat thing.
From: Erik Naggum
Subject: Re: Engineering Envy [was: Re: CL and UML]
Date:
Message-ID: <3203584579168634@naggum.net>
* Marcin Tustin
> Just because you can use the fact that someone desires something to
> persuade them to serve your purposes, does not mean that you are not
> exploiting them [...]
I am not addressing the issue of exploitation, but of use of force.
People who buy lottery tickets are exploited for the sheer stupidity in
their thrill-seeking. People who are affected by advertising to buy
something they do not need are similarly exploited. People who _smoke_
are exploited. People who hold a religious belief and do the bidding of
their religious leaders are exploited. If I were interested in fighting
exploitation, I would _not_ start with a sweatshop somewhere abroad.
> The fact is that one can always produce objections that people are not
> free to not do something.
So? This silly "fact" has no bearing on anything. Anyone can always
produce any number of arguments for and objections against absolutely
anything, but we take that for granted, a given. The interesting thing
about arguments and objections is their validity.
> Therefore you will have to take a stand and accept some fairly arbitrary
> criteria. Not everyone will make the same choice.
I am used to this kind of anti-logic in political campaigns. Are we
having a political campaign with emotional agitation, or do we have a
discussion among reasonably intelligent people who are able and willing
to think? If you want to continue the political campaign, please let me
know, such as by insisting that the validity of arguments is completely
irrelevant because it is an arbitrary choice and an argument is only
measured by how many people are affected by it.
* Erik Naggum
> Not really. This is all about why some people "prefer" C++. :)
In case it did not come across successfully, this was intended as a joke.
* Marcin Tustin
> I have a friend who ridicules the idea of using Lisp "Because it's an
> AI/Neural net/blah blah language" while Pascal (Or rather delphi) is
> clearly fantastic - not that he offers any reason. [Etc.]
You will have to take a stand and accept some fairly arbitrary criteria
for what constitutes a "reason". Not everyone will make the same choice.
Do you have a problem with this line of argument in programming languages?
#:Erik
--
Travel is a meat thing.
Erik Naggum <····@naggum.net> wrote in message
·····················@naggum.net...
> > The fact is that one can always produce objections that people are not
> > free to not do something.
>
> The interesting thing
> about arguments and objections is their validity.
I assumed that the word "valid" was a given. I am talking here about
arguments referring to people being products of/affected by environments and
circumstances that they do not control.
> > Therefore you will have to take a stand and accept some fairly arbitrary
> > criteria. Not everyone will make the same choice.
>
> I am used to this kind of anti-logic in political campaigns. Are we
> having a political campaign with emotional agitation, or do we have a
> discussion among reasonably intelligent people who are able and willing
> to think? If you want to continue the political campaign, please let me
> know, such as by insisting that the validity of arguments is completely
> irrelevant because it is an arbitrary choice and an argument is only
> measured by how many people are affected by it.
Getting a little hot under the collar? I am not arguing, but rather
commenting on the argument. I reiterate that any position rests on certain
axioms simply taken as givens. The axioms of your discourse may not be the
same as someone else's.
> * Erik Naggum
> > Not really. This is all about why some people "prefer" C++. :)
>
> In case it did not come across successfully, this was intended as a
joke.
>
> * Marcin Tustin
> > I have a friend who ridicules the idea of using Lisp "Because it's an
> > AI/Neural net/blah blah language" while Pascal (Or rather delphi) is
> > clearly fantastic - not that he offers any reason. [Etc.][ad nauseam -
MT]
> Do you have a problem with this line of argument in programming
languages?
Nope.
From: Erik Naggum
Subject: Re: Engineering Envy [was: Re: CL and UML]
Date:
Message-ID: <3203608472172221@naggum.net>
* Marcin Tustin
> I assumed that the word "valid" was a given. I am talking here about
> arguments referring to people being products of/affected by environments
> and circumstances that they do not control.
I take it for granted that people have the ability to take control over
such things. Still, I am open to your counter-evidence.
> Getting a little hot under the collar?
Apparently, you do not take "valid" _that_ much as a given, but it _is_
sort of nice to see that you are actually out of control relative to your
environment and circumstances.
> The axioms of your discourse may not be the same as someone else's.
You realize, of course, that this is no more valid than the previous
nonsensical "argument" was.
As I said, I am used to that kind of anti-logic in political campaigns.
You seem to favor that over a discussion, and I must assume that that is
a result of your environment and circumstances outside your control, so
_you_ cannot change your attitude, either. "You realize that humans are
not omnipotent and therefore that any argument may contain the seed of
its own undoing?" and the cruft you produced are about equally smart
things to say. To the layman with no clue whatsoever, they sound sort of
profound, but anyone who has read even the littlest bit of philosophy
knows that spouting such drivel is the very antithesis of an argument.
We all know and understand these things, so saying them betrays the idea
that the one who repeats them thinks it has relevance in and by itself.
It has none whatsoever. It also betrays the idea tht he who repeats them
thinks that doing so has an effect on the discussion. It has none other
than to show that he who argues thusly is a fool.
Has it occurred to you that the axiom of different axioms for everybody
may not be shared by everybody, such that your ability to take part in a
discussion is limited to repeating your axiom to those who do not share it?
#:Erik
--
Travel is a meat thing.
Erik Naggum <····@naggum.net> wrote in message
·····················@naggum.net...
> * Marcin Tustin
> > I assumed that the word "valid" was a given. I am talking here about
> > arguments referring to people being products of/affected by environments
> > and circumstances that they do not control.
>
> I take it for granted that people have the ability to take control over
> such things. Still, I am open to your counter-evidence.
>
> > Getting a little hot under the collar?
>
> Apparently, you do not take "valid" _that_ much as a given, but it _is_
> sort of nice to see that you are actually out of control relative to
your
> environment and circumstances.
>
> > The axioms of your discourse may not be the same as someone else's.
>
> You realize, of course, that this is no more valid than the previous
> nonsensical "argument" was.
So you are saying that all people proceed from the same axioms?
[snip random rant]
> Has it occurred to you that the axiom of different axioms for everybody
> may not be shared by everybody, such that your ability to take part in a
> discussion is limited to repeating your axiom to those who do not share
it?
As I said, my comment was about your discussion, not a part of your
discussion - indeed, it can only be a (useful) part of a discussion about
discussion and discourse, and related subjects.
> #:Erik
> --
> Travel is a meat thing.
Erik Naggum <····@naggum.net> writes:
> * Marcin Tustin
> > Just because you can use the fact that someone desires something to
> > persuade them to serve your purposes, does not mean that you are not
> > exploiting them [...]
> I am not addressing the issue of exploitation, but of use of force.
> People who buy lottery tickets are exploited for the sheer stupidity
> in their thrill-seeking.
Stupid though "lotterying" is, the effect is fairly rational.
People buy lottery tickets because they have a hard time correctly
assessing the proper valuation of transactions involving _extremely_
skewed probability distributions.
They'll buy insurance [which _is_ rational] based on paying a fairly
small amount that, at low likelihood, has a large payoff. The pricing
there is sufficiently fair that it's often probably wise to buy _some_
insurance. The expected payoff is probably a little negative, but if
it avoids some bigger problem, that's worthwhile.
With lotteries, the conditions are fairly similar, save for the
consideration that it's likely that half the money gets skimmed off
for this and that, thus making the expected payoff _severely_
negative.
[Note: I had a classmate in a grad course in statistics that had the
education to know better, but was still entirely faithful about buying
the weekly lotto ticket. People _aren't_ terribly rational...]
--
(reverse (concatenate 'string ········@" "enworbbc"))
http://vip.hyperusa.com/~cbbrowne/spreadsheets.html
Rules of the Evil Overlord #135. "My doomsday machine will have the
advanced technological device called a capacitor just in case someone
inconveniently pulls the plug at the last moment. (If I have access to
REALLY advanced technology, I will include the even better back-up
device known as the "battery.")" <http://www.eviloverlord.com/>
In article <·······················@news20.bellglobal.com>,
<········@hex.net> wrote:
>
>They'll buy insurance [which _is_ rational] based on paying a fairly
>small amount that, at low likelihood, has a large payoff. The pricing
>there is sufficiently fair that it's often probably wise to buy _some_
>insurance. The expected payoff is probably a little negative, but if
>it avoids some bigger problem, that's worthwhile.
>
I once had a manager who insisted on entering the office lottery
pool as insurance - if we all got rich and quit he didn't want
to have to stay behind and try to cope without us.
>With lotteries, the conditions are fairly similar, save for the
>consideration that it's likely that half the money gets skimmed off
>for this and that, thus making the expected payoff _severely_
>negative.
>
Most of the time, anyway. Once in a while a progressive lottery
(like the Powerball) gets enough money in the pot so that the
expected return is fairly close to the cost. Every time I've
seen that, the prize goes out before getting quite to a positive
return. It gets harder to calculate then, because with an
increased number of tickets there starts to get to be a significant
chance of multiple winners.
>[Note: I had a classmate in a grad course in statistics that had the
>education to know better, but was still entirely faithful about buying
>the weekly lotto ticket. People _aren't_ terribly rational...]
If you find that buying a lottery ticket gives you pleasure equal
to the value of the ticket, then it is rational to buy it.
Some people like buying tickets and occasionally daydreaming about
what to do with the money. I sometimes do that. (Buying large
amounts of lottery tickets is a sign that this isn't happening.
One entry is enough to daydream on.)
And, no, people aren't rational. It's hard to understand why some
people like doing the things they do, but they do like it, and
therefore it's rational for them to spend some money on it.
--
David H. Thornley | If you want my opinion, ask.
·····@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
>>>>> "DT" == David Thornley <········@visi.com> writes:
I don't have major qualms with the rest of this but
DT> And, no, people aren't rational. It's hard to understand why
DT> some people like doing the things they do, but they do like
DT> it, and therefore it's rational for them to spend some money
DT> on it.
Hmm, how so? My favorite is people going for the brand name over the
counter drugs that sit right next to the generic equivalents. When
asked, it will turn out that they will tell you they don't like wasting
money. It takes maybe a handful of steps to come up with a convincing
argument that their behaviour in the drug store is no different than
wasting money. How's this rational? Maybe one can find rational
_explanations_ for the behaviour (power of marketing, absent mindedness,
cost of the computation to figure out that they are overpaying etc.)
but the behviour itself is not rational, IMHO.
cheers,
B<OT>M
On Wed, 11 Jul 2001 18:52:51 GMT, Bulent Murtezaoglu <··@acm.org> wrote:
> Hmm, how so? My favorite is people going for the brand name over the
> counter drugs that sit right next to the generic equivalents. When
In Italy some drugs are provided for free by the national health service.
If both a branded and a generic drug exist for a certain treatment, the
health service provides only the latter for free. The patient has the
option of choosing the branded version if he prefers, but in this case he
has to pay for it.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
In article <··············@nkapi.internal>,
Bulent Murtezaoglu <··@acm.org> wrote:
>>>>>> "DT" == David Thornley <········@visi.com> writes:
>
>I don't have major qualms with the rest of this but
>
> DT> And, no, people aren't rational. It's hard to understand why
> DT> some people like doing the things they do, but they do like
> DT> it, and therefore it's rational for them to spend some money
> DT> on it.
>
>Hmm, how so?
Because what I meant was that certain things have entertainment
value for certain people for reasons I don't understand (heck, I
don't know reasons for lots of things I like doing). It happens
that I enjoy having a lottery ticket for some odd reason sometimes,
and that this pleasure seems worth more than a dollar to me, so
I buy one. The reason(s) I like having one are probably not
rational, but the reason I buy it is because I want to.
My favorite is people going for the brand name over the
>counter drugs that sit right next to the generic equivalents. When
>asked, it will turn out that they will tell you they don't like wasting
>money.
If they think that a brand-name drug is going to be reliable and
a generic isn't, then (a) they're wrong (the FDA makes sure of that)
and (b) buying the brand name may be rational based on what they know.
In buying some things, it makes sense to pay extra to buy from a
manufacturer you trust, and avoid generics. You'll pay a lot less
for screwdrivers over your lifetime if you consistently buy quality
ones in a hardware store rather than one of those $2.79 bags in
the grocery store.
Similarly, if I were buying some sort of herb product, I'd want
to go with a label I had reason to trust, rather than buying what
was cheapest. The FDA *doesn't* regulate those. (A friend of
mine who worked for the FDA once won't take herbal pills but
will drink herbal teas, since there are regulations on foodstuffs
that aren't on dietary supplements.)
So, buying the brand name can be a rational behavior based on
a false belief. Since I do happen to know something about the
FDA, and trust it, I buy generic.
--
David H. Thornley | If you want my opinion, ask.
·····@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
········@visi.com (David Thornley) writes:
> In article <··············@nkapi.internal>,
> Bulent Murtezaoglu <··@acm.org> wrote:
> >>>>>> "DT" == David Thornley <········@visi.com> writes:
>
> My favorite is people going for the brand name over the
> >counter drugs that sit right next to the generic equivalents. When
> >asked, it will turn out that they will tell you they don't like wasting
> >money.
>
> If they think that a brand-name drug is going to be reliable and
> a generic isn't, then (a) they're wrong (the FDA makes sure of that)
> and (b) buying the brand name may be rational based on what they know.
> In buying some things, it makes sense to pay extra to buy from a
> manufacturer you trust, and avoid generics. You'll pay a lot less
> for screwdrivers over your lifetime if you consistently buy quality
> ones in a hardware store rather than one of those $2.79 bags in
> the grocery store.
A generic drug many not be as "reliable" as a generic one. The
problem is that they may be made in different ways. For instance what
if the name brand one was extracted directly from a biological source
while the generic is synthetic. They can have different potencies
even if they are the "same" chemical compound. I remember seeing a
report on just such a case about a drug which has FDA approval and is
derived from some sort of biological source, it also can be
synthisized but the synthetic version is inferior. If I remember
right there was some suspicion that the chemical which was supposed to
be the active ingrediant was not correctly identified, or that some
other chemical in the biologically derived case was some sort of a
curative cataylst.
I do agree with your point on quality on the whole it is just that the
FDA stamp of approval is not a guarentee of equivalence. It is
protection against relabeling asperin or rat poison as Prozac, but
there is still a degree of variablity and fallibility involved.
-Eric
From: Erik Naggum
Subject: Re: Engineering Envy [was: Re: CL and UML]
Date:
Message-ID: <3203921203733271@naggum.net>
* David Thornley
> If you find that buying a lottery ticket gives you pleasure equal
> to the value of the ticket, then it is rational to buy it.
:
> And, no, people aren't rational. It's hard to understand why some
> people like doing the things they do, but they do like it, and
> therefore it's rational for them to spend some money on it.
"Rational" and "agrees with me" are two very different things. Most
people have different premises, personal experiences and values, and also
different goals and self-esteem, so they go about them differently.
Given all these factors, most people _do_ behave rationally, but not
necessarily according to somebody elses set of premises, experiences,
values, goals, and self-esteem. If you ask people "what made that a
rational thing for you to do" instead of exclaiming "that's irrational",
about 95% of the people you ask think you said "that's irrational" in a
polite way because they are taught that politeness is a much, much higher
value in society than intelligence (which is rational only if people are
_immensely_ stupid), but the remaining 5% manage to think about what they
did and actually give an intelligent answer. You will never find those
5% if _your_ premise is that (other) people are not rational.
#:Erik
--
Travel is a meat thing.
David Thornley wrote:
>
> Most of the time, anyway. Once in a while a progressive lottery
> (like the Powerball) gets enough money in the pot so that the
> expected return is fairly close to the cost. Every time I've
> seen that, the prize goes out before getting quite to a positive
> return. It gets harder to calculate then, because with an
> increased number of tickets there starts to get to be a significant
> chance of multiple winners.
>
Actually, Powerball has been a "rational" bet several times a year. If the pot gets over 87 million dollars, then (if you lived 20 million years or
so ;) ) it would be rational to buy the ticket. A statistician would probably tell you it is rational anyway at that payoff rate. Now, if you have
multiple winners, this screws up the analysis a lot as to where the breakeven point is, but multiple winners are fairly rare. If you ignore multiple
winners, the rationality point is currently around 87 million and I've seen a couple of "pots" as high as 120 million or so.
Interestingly enough, right about that 87 million dollar point, people begin to pool together and form informal little consortiums ("office pools")
that buy maybe 100 tickets or so (reducing the pay off time from maybe 40 million years to 400 thousand years with everyone agreeing to divide up the
winnings). Some of these consortiums have actually won and (as far as I know) shared the wealth as planned. Once the bet turns rational, dividing
the payoff is just fine because you're merely trading frequency of winning for a bit less money.
Now, someone will tell me that down the hall there's a consortium that bets every PowerBall. What I'm pointing out is that as the pot grows,
especially as the pot passes the rationality point, you see a lot more of these start to happen.
So, I guess that proves we're sometimes rational.
Larry
········@hex.net writes:
> Erik Naggum <····@naggum.net> writes:
> > * Marcin Tustin
> > > Just because you can use the fact that someone desires something to
> > > persuade them to serve your purposes, does not mean that you are not
> > > exploiting them [...]
>
> > I am not addressing the issue of exploitation, but of use of force.
> > People who buy lottery tickets are exploited for the sheer stupidity
> > in their thrill-seeking.
>
> Stupid though "lotterying" is, the effect is fairly rational.
>
> People buy lottery tickets because they have a hard time correctly
> assessing the proper valuation of transactions involving _extremely_
> skewed probability distributions.
>
> They'll buy insurance [which _is_ rational] based on paying a fairly
> small amount that, at low likelihood, has a large payoff. The pricing
> there is sufficiently fair that it's often probably wise to buy _some_
> insurance. The expected payoff is probably a little negative, but if
> it avoids some bigger problem, that's worthwhile.
>
> With lotteries, the conditions are fairly similar, save for the
> consideration that it's likely that half the money gets skimmed off
> for this and that, thus making the expected payoff _severely_
> negative.
>
> [Note: I had a classmate in a grad course in statistics that had the
> education to know better, but was still entirely faithful about buying
> the weekly lotto ticket. People _aren't_ terribly rational...]
the expected value for the return may be low, however it might not be
completely irrational. consider a poor person with only a few
dollars. they could surmise that with this money they cannot afford
to save for, e.g., retirement. if they play the lottery, there is a
remote chance of winning. it might even be their best shot. expected
value is only relevant if you place enough times to get an average.
thus it makes no sense to spend millions on lottery tickets. however,
if $5 is of little value, the chance -- however slim -- of winning
$10M might be the rational choice.
william feller in his book on probability (i think it's vol i) has a
section on gambling and the ruin problem. he describes gambling when
the house has better odds. he goes on to point out that to maximize
expected return in this case it is better to place one large bet than
many small ones. in the former, you might win. in the latter, you
are almost guarenteed to go bust. however, he points out that there
is no statistical basis to reject gambling altogether.
--
J o h a n K u l l s t a m
[········@ne.mediaone.net]
Don't Fear the Penguin!
Johan Kullstam <········@ne.mediaone.net> writes:
> ········@hex.net writes:
>
> > Erik Naggum <····@naggum.net> writes:
> > > * Marcin Tustin
> > > > Just because you can use the fact that someone desires something to
> > > > persuade them to serve your purposes, does not mean that you are not
> > > > exploiting them [...]
> >
> > > I am not addressing the issue of exploitation, but of use of force.
> > > People who buy lottery tickets are exploited for the sheer stupidity
> > > in their thrill-seeking.
> >
> > Stupid though "lotterying" is, the effect is fairly rational.
> >
>
> the expected value for the return may be low, however it might not be
> completely irrational. consider a poor person with only a few
> dollars. they could surmise that with this money they cannot afford
> to save for, e.g., retirement. if they play the lottery, there is a
> remote chance of winning. it might even be their best shot. expected
> value is only relevant if you place enough times to get an average.
> thus it makes no sense to spend millions on lottery tickets. however,
> if $5 is of little value, the chance -- however slim -- of winning
> $10M might be the rational choice.
I've often called lotteries "stupidity tax". Especially since the
money accumulated is often spent on education, this seems ok to me,
since I believe the fool and their money are soon parted anyway.
Might as well send that parted money back into the educational system.
But a simpler argument prevails from the purchaser's point of view.
Hope is not based on rationality, but on belief. For the $1 purchase
of a lottery ticket, they walk around all day with the hope of being a
millionaire, almost independent of the oddsd. There is likely no
other item you could sell them for a buck that would give them this
kind of hope, so even if they never win, they have been afforded
extraordinary value for their dollar.
Finally, all these analyses of possible return amaze me. If you win big,
the lottery pays out over 20 years, at least here. In effect, they are
paying 5% per year--i.e., the interest. They aren't giving you the
principal. They still have the money you won at the end of the 20 years.
After that, they can "give it away" again. At this point, the lottery
is sheer profit. (I think you can take an option for an immediate
settlement of a fractional amount, and that in that case you do monetarily
quite a bit better... assuming you trust yourself to spend it well. A lot
of lottery winners spend it badly, and it's just as well it's dealt out
to them slowly.)
Not that I'm quite sure what any of this has to do with Lisp. But that's ok.
From: Erik Naggum
Subject: Re: Engineering Envy [was: Re: CL and UML]
Date:
Message-ID: <3204117461936780@naggum.net>
* Kent M Pitman
> But a simpler argument prevails from the purchaser's point of view. Hope
> is not based on rationality, but on belief. For the $1 purchase of a
> lottery ticket, they walk around all day with the hope of being a
> millionaire, almost independent of the oddsd. There is likely no other
> item you could sell them for a buck that would give them this kind of
> hope, so even if they never win, they have been afforded extraordinary
> value for their dollar.
However, this artificial hope depends on the ignorance of the purchaser.
For instance, I have absolutely _no_ hope attached to a lottery ticket.
On the other hand, I do have "hope" attached to insurance: I know that I
will not be devastated financially by a disaster, should it happen with
the same likelihood that I would win the lottery. The effect of owning a
lottery ticket is likely the continuation of my current lifestyle, since
I do not win. The effect of having insurance is likely a continuation of
my current lifestyle, since I do not _lose_ everything should a disaster
happen. However, if I do not buy the lottery ticket, the likelihood of
continuation of my current lifestyle is marginally _increased_: I do not
have to deal with the changes coming from winning the lottery. If I do
not purchase the insurance, the likelihood is marginally _decreased_: I
may have to deal with the changes coming from losing everything in a
disaster. Insofar as planning goes, lottery tickets are just as high
risk as disasters. I do not want disasters to befall me, and for the
exact same reason, I do not want to win millions of dollars in a lottery:
Both would upset my plans tremendously. If the disaster would not upset
my plans noticeably, I do not need insurance. If they lottery payout
would not alter my plans, I do not need the ticket, either. In which
case, it would be a sheer waste of moeny to play the lottery, and a
caculated risk to buy insurarnce or not.
Now, "the Norwegian Dream" is, in quite amazing contrast to "the American
Dream" or "the Swedish Dream" or "the German Dream", etc, is to win big
in the lottery. The Norwegian population buys many times more lottery
tickets than the next civilized country. I guess this is becausae as a
nation, we are still quite poor, but we found this lottery ticket on the
ocean floor which returned the multitrillion-dollar prize: _oil_. (Worst
thing that ever happened to this nation, if you ask me.) People in this
country to not expect to get rich through work, they expect to get rich
by winning something or other by chance. Those very few who managed to
beat the Norwegian attitude and make real money are despised and loathed
by the population in general. Lottery winners are, however, regarded
with very positive eyes. Lots of advertising exclaims that "Lotto
millionaires are not like other millionaires", and they show people who
have spent their money extremely unwisely on something rabidly idiotic.
Quite entertaining though they may be, they tell a sad story about the
people who buy lottery tickets and the Norwegian attitude to money.
> Finally, all these analyses of possible return amaze me. If you win big,
> the lottery pays out over 20 years, at least here. In effect, they are
> paying 5% per year--i.e., the interest. They aren't giving you the
> principal. They still have the money you won at the end of the 20 years.
This is grossly oversimplified, Kent. The real value of the principal is
(roughly) maintained _because_ of the compounded interest. If you give
away the interest, you give away that much of the principal's real value,
both in comparison to what you would have gotten for it if invested
elsewhere, as well as through inflation of the money supply and other
loss of value of your currency relative to the goods you might want to
exchange for it. If you manage to get 5.5% interest on the money, you
will have the same number of dollars at the end of the 20 years as when
you started, while having given away one million dollars a year. Suppose
you have 2.5% annual decrease in real purchasing power during the same
period, meaning that you would have to have almost 33 million dollars in
20 years to have the same buying power, you would need to get a 7% annual
return on investment on those 20 million to "keep the money" while giving
away 1 million dollars a year. If you manage to get 7% interest but did
not give the money away, you would have had 77.4 million dollars after 20
years, which means that you have _actually_ given away 44 million dollars
of real value at the end of those 20 years, but the poor idiot who got
the money only received 20 million dollars that were probably spent each
year for an ever decreasing number of real goods. If saved, it would
probably maintain its total purchasing power after 20 years, but then you
would have gained nothing in the interim, which would be dumb, so let the
winner spend $500,000 adjusted for inflation every year. After 20 years
with 3% inflation he would have about $10M left and could keep going
through his cash like that for another 10 years. With more modest
annual spending, the money could very well last for the rest of his life.
> After that, they can "give it away" again.
As I think I have demonstrated, that would require inordinate financial
ability and would _not_ happen automatically. In other words, for a
lottery to make money over time, it needs to keep a fairly large chunk of
the money it continues to receive for lottery tickets to fulfill its
obligation to continue to pay past winners. The way these things are
run, they are essentially betting on there being enough future fools to
pay for past winners. If they had had the financial savvy to maintain
the value of their money, they would have found better ways to spend the
prize money than give it away to lottery winners. All in all, it is a
rip-off from start to finish, and the likelihood it will survive and all
the winners will get their winnings to the last nickel is about as good
as social security being there for us in 50 years, which is just another
racket and barely-cloaked pyramid game run by ignorant politicians.
However, lotteries basically being a way of financing stuff that nobody
would finance if they knew what they were financing, it may be the only
way of getting your hands at a significant amount of money to promise to
give most of it away. If you are very, very smart and run lotteries on
the grand scale (like a government can do), you really can get away with
investing all that money you get from tickets and get more than 7% return
on investment, but then you need a _lot_ of surplus money. If you should
_ever_ default on your payment to your past winners, you will lose _all_
confidence and get no more money from any more lottery ticket buyers and
it does not take more than one of those incidents to rip you to shreds
and have lawyers down your throat. If you run a confidence game like a
lottery really is, confidence is your _only_ asset. The reason most
governments have strict controls on lotteries and prefer to run them on
their own is precisely that it is a form of calculated fraud. If only
people were happy to get a little hope in return for a buck, it would be
fine -- but the mere sight of a lot of people giving somebody a lot of
money in return for a few of them getting a lot of money back is like
waving flypaper in a roomfool of criminals. What would it take to rig
the game so somebody who is in on the game is guaranteed to walk away
with much less than the announced winnings and consequently help land
much more money in the hands of the lottery operator? Very little. In
fact, so little that the mere _intention_ of setting up a lottery is
criminal in most countries unless you obey a whole lot of laws and
controls. Yet, it is a breeding ground for criminals of all kinds. It
is absolutely no different from selling insurance and then going out of
business before ever paying any claims. Come to think of it, that _is_
the social security lottery.
> Not that I'm quite sure what any of this has to do with Lisp. But that's ok.
Gratuitous Common Lisp relevance: I computed all the above figures with a
few simple financial functions written in Common Lisp.
#:Erik
--
Travel is a meat thing.
On Sat, 14 Jul 2001 03:00:20 GMT, Kent M Pitman <······@world.std.com>
wrote:
> I've often called lotteries "stupidity tax". Especially since the
> money accumulated is often spent on education, this seems ok to me,
Part of the funds raised from an Italian lottery are used for restoring and
preserving monuments and other works of art.
> But a simpler argument prevails from the purchaser's point of view.
> Hope is not based on rationality, but on belief. For the $1 purchase
> of a lottery ticket, they walk around all day with the hope of being a
> millionaire, almost independent of the oddsd. There is likely no
[...]
> Not that I'm quite sure what any of this has to do with Lisp. But that's ok.
Not exactly. For the time and resources spent on learning Lisp, I will walk
around all my life, not just one day, with the certainty of being a lucky
and privileged programmer :)
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
Kent M Pitman <······@world.std.com> writes:
> Finally, all these analyses of possible return amaze me. If you win big,
> the lottery pays out over 20 years, at least here. In effect, they are
> paying 5% per year--i.e., the interest. They aren't giving you the
> principal.
> (I think you can take an option for an immediate
> settlement of a fractional amount, and that in that case you do monetarily
> quite a bit better... assuming you trust yourself to spend it well. A lot
> of lottery winners spend it badly, and it's just as well it's dealt out
> to them slowly.)
I think you generally have a choice. But if you take the lump sum, you lose
a bunch because of the present value of the money, plus a bunch more on taxes.
Here's an analysis from a recent California lottery:
http://www0.mercurycenter.com/business/center1/lot0628.htm
_______________________________________________________________________________
Don Geddis www.goto.com ······@goto.com
Whether lottery playing is rational depends on the marginal value of money.
In many situations, the marginal value of money decreases as the total
amount goes up, but that is not always the case.
If I am poor, and foresee that someday I may no longer be able to work and
will starve, or live in misery, then the value of the euro that will enable
me to live a decent life till I die of something else than starvation or
poverty-induced illness may be a lot higher than that of any other euro:
euros below will not enable me to escape my horrible fate, and euros above
won't have to, and can only add to an already decent standard of living.
In such a situation, gambling "cheap" euros for fewer "expensive" ones may
be utterly rational.
On a completely different line: it may be fully rational to play in a
lottery, the proceeds of which go to a cause that one supports with an
amount that is as much smaller as the amount of the ticket price that is
not paid out to winners but to the cause. So, instead of donating E 10,- [I
assume that euro amounts will use a decimal comma in American English, just
as dollar amounts use a decimal point in most other languages..] to the
cause, I buy a lottery ticket of which, say, E 3,- goes to the cause and
donate E 7,-.
(This assumes that lottery costs are negligable.)
--
Biep
Reply via http://www.biep.org
Erik Naggum <····@naggum.net> writes:
> * Craig Brozefsky
> > This is a very common argument, but I have never seen anything but
> > anecdotal evidence to "support" it.
>
> Are they forced somehow to work in the sweatshops? If you can
> demonstrate that they are, you may have a point. If you cannot,
> and those who work there _could_ go back to whatever they came
> from, what kind of evidence do you need?
Do they have a gun to their head? Most likely not, although in a
number of cases they do. When you look at the historical context,
yes, I would call it force. The economic situations in these
countries did not spontaneously appear, we did not just discover them
the other day. They have been systematically exploited thru various
means of imperialism for the last hundred years, some going back
centuries.
The economic conditions have been created and cultivated by the same
people who are now benefitting from the cheap labor. This used to be
done thru military occupation and partnerships between trade companies
and occupying governments (Indian, Belgian Congo, L.A.) it's now done
thru WTO "structural reforms" and the "liberalization of markets".
The goal remains the same, enable access to the natural resources of
these countries and keep their labor pool manageable and cheap and
producing goods which are exported and not used for subsistence, and
keep them heavily dependent upon imports (ranging from food to oil).
We gain no understanding of the situation, perhaps only giving
ourselves a bit of ethical salve, by looking at it in an ahistorical
context. Such consideration does not look at how the condition
allowing that low cost labor arrived. It is indeed a willful
decision, work or starve, or work and starve for some, that from a
political-economic standpoint is fair and ethical, noone was pointing
a gun at them. But unless we understand their historical condition,
we understand nothing.
> It is rather obvious to me, but maybe it needs to be said: Those
> who have the option of better work than that in sweatshops would
> have to be forced to work in them. There has never been any
> evidence of such force.
Actually there has been evidence of forced labor on every continent.
Burma, China, India, Pakistan, Nepal, Brazil, Ghana to name a few.
The work ranges from manufacturing to mining to prostitution.
> Well, it sure works wonder to be dissatisfied with the only better
> choice you have.
Oh that's right, there is no alternative. My fault for taking off my
panglossian shades. I'm glad us white-men are here to fulfill our
divine imperative of industrializing and employing those hapless
uncivilized savages. It would obviously make me a less productive
citizen to consider the extent to which my well-being and my ability
to make it thru the day and afford my various consumer goods is
predicated upon the suffering of others, but since there is no other
choice for them, or me, there is no need to get worked up about it. I
know! I'll rationalize it as completely ethical transaction with some
schoolboy political-economics.
> Those who make those sweatshops look so awful to the people who may have
> forgotten what other options they [do not] have, destroy not only their
> financial livelihood now, but their psychological livelihood for most of
> their future, too.
How did they get into a position where they had no alternative?
--
Craig Brozefsky <·····@red-bean.com>
http://www.red-bean.com/~craig
"Indifference is the dead weight of history." -- Antonio Gramsci
From: Erik Naggum
Subject: Re: Engineering Envy [was: Re: CL and UML]
Date:
Message-ID: <3203606201068434@naggum.net>
* Erik Naggum
> Well, it sure works wonder to be dissatisfied with the only better choice
> you have.
* Craig Brozefsky
> Oh that's right, there is no alternative. [Misdirected rant elided.]
Next time, please try to read what I write. You somehow managed not even
to see the word "better" up there. Omitting that word changes the
meaning of the sentence to the nonsense you responded to. Shame on you
for being so obsessed with your own opinions and your weltanschauung that
you have no time nor desire to read and understand those of others before
your knee-jerk reactions set in.
I should have known better than to respond to you. You have argued so
strongly for an insight-free way of seeing things that the hope of
getting across to you that there are people out here who do not hold the
standard opposite view of yours is rather slim. There is just no point
in reiterating the same old arguments that have failed to work on you
clueless leftist rebels before, so for the sake of argument, assume that
I have already realized what your opinions and deeply racist view of
white people are based on and do _not_ present you with a smorgasbord of
well-known and mostly invalid arguments that you can dismiss out of sheer
routine. It would help the _discussion_ if you also assumed that I had
read the whole thread and your "deliberations", as well.
You have completely failed to understand what a number of people have
tried to commmunicate to you and instead respond as if you had a regexp
argument matcher, caring about neither false positive nor false negative
matches in the Perl fashion of using regexps. Like some people who have
"trigger words" for the groups they believe are their opponnents and
pidgeon-hole them upon using such words, you seem to have latched onto a
set of arguments that respond not to a single thing anyone have said, but
instead to some caricature of a standardized opponent, much like you talk
about "the same people" both cultivating in the past and now exploiting
those poor, helpless retarded people that could never in their lifetime
have done anything to improve their miserable life under "imperialism"
until Craig Brozefsky came along to explain everything to them.
It is downright insulting to those who have tried to reach you despite
the silly regurgitated "imperialist" and "exploitation" agitation that
function so well as "trigger words" for pidgeon-holing you as a "leftist
rebel without a clue". I am quite sure you had a brain when you accepted
all those emotive "arguments", so if you work a little on it, it might
yet work to receive arguments once again, perhaps even non-emotive ones
now that you have grown a little older. You see, it looks like you have
none at all when you fail to grasp that you are no longer succeeding with
all that standard far-leftist rhetoric. I can talk to such phrase-book
parroting robots locally any time I want to waste my time, but here on
comp.lang.lisp, I expect more. _Especially_ more intelligence at work.
The rest of your article is similarly misdirected.
#:Erik
--
Global warming is caused by too many humans not keeping their cool.
Erik Naggum <····@naggum.net> writes:
<response on the group since I think there is a need to make my
apology public>
> * Erik Naggum
> > Well, it sure works wonder to be dissatisfied with the only better choice
> > you have.
>
> * Craig Brozefsky
> > Oh that's right, there is no alternative. [Misdirected rant elided.]
>
> Next time, please try to read what I write. You somehow managed not even
> to see the word "better" up there.
I did see the word better. That wasn't the problem. The problem was
that I read your comment as sarcastic, as if "it sure works wonder"
was being said with eyes rolling. It was not quite a regexp firing.
It was rather more like my frustration at being unable to articulate
my response to your comment sufficiently was given excuse to let loose
in a rant by some imagined sarcasm. You're right that it was a
unconstructive reaction, and after re-reading it I find myself largely
in agreement. I owe you an apology.
Sorry.
> The rest of your article is similarly misdirected.
I think that I failed to sufficiently illustrate why I thought the
historical context is useful. It's not because I think that it will
give me, or anyone who masters its vocabulary a position of authority.
We certainly don't need yet another vanguard party of lefties telling
us what to do, particularly when they are guided by a need to preserve
an ideology or figurehead, or to protect the own existence (as
organizations, not the constituencies they claim to represent).
My original comment about the question of globalization of production
being good for countries suggested that in many cases the forces of
global financing erase the benefits to the populations thru things
like massive public debt, capital flight, and forced migration to
towns and cities. In other words, the things that the country offers
the company to locate an operation of some sort within it outweigh the
benefits. The people who decide what to offer, and who often are the
biggest benefiaries, are not the ones who pay the tab.
Obviously, this is not always the case, but for sub-saharan Africa,
many parts of Latin Ameria, and now Eastern Europe it has normalized
to this. The U.S. and other nations are also not immune, these
policies works domestically as well as internationally, with large
parts of their population in poverty. My conclusion is based on my
own experience an that of my family and friends. I dare to generalize
it after looking at quality of life figures, life-expectancy, income
disparity figures, infection rates for controllable diseases, weight
of public debt in relation to GDP, value of local currency,
environmental damages, control of public debt, trade deficits, and
loss of control of various aspects of their governments to
non-democratic foreign control, and listening to people from various
countries around the world.
When in response to your question about force, I suggested that we
consider the historical context of the decisions we are making as
laborers, it is not because I want to prove that anyone is worse off.
Rather it was to expand the question from force being just immediate
physical threat, to the forces that created the situation in which
being a prostitute, garment worker, or miner is the only option
against starvation that is readily available. I think that there are
people forced into these situation by the removal any ther optional
they feel is realizatic. The goal is not to remove that only option,
the simplist anti-sweatshop solution, but to create more posibilities.
If we, as people in these situations (some more dire than others), are
going to attempt to create better choices for ourselves, we have to
know how we got where we are now, so that we can act now.
--
Craig Brozefsky <·····@red-bean.com>
http://www.red-bean.com/~craig
"Indifference is the dead weight of history." -- Antonio Gramsci
> > "Depletion of natural resources" is fairly industrial age.
>
> Yes it is. However, what we have in these situations is a colonial
> exploitation of the natural resources of a country with the cost of
> infrastructure for that exploitation being put onto the public's head,
> and the profits being almost entirely taken out of the country.
> Indeed this has gone on for quite some time, as it is a basic function
> of imperialism.
Except that the trade barriers don't exist, so it really isn't much
different than how GM treats random towns in Michigan.
And, as I noted, if things really are that way, there's a moral
obligation for YOU to do better by those folks. If there's excess
profits in the hands of evil doers because the good refuse to
compete....
> > Today, it tends to divert "noble savage" labor into something that
> > we'd call sweatshops, something that the "savages" strongly prefer
> > to THEIR alternatives.
>
> This is a very common argument, but I have never seen anything but
> anecdotal evidence to "support" it.
There's the small fact that the workers show up. That's the only
evidence that you'll ever find that workers prefer one job to another.
Precisely what evidence would you find acceptable? Make sure that
it applies in other situations, such as your OWN employment.
> For one, everyone outside the
> first-world is not a subsistence farmer.
Interestingly enough, there was no previous mention of subsistence
farming. Why the sneering mis-attribution?
Of course, their previous state of employment isn't all that relevant.
They show up, ergo, they prefer it.
> There is not this decision
> between borderline starvation thru farming and scavenging and working
> in a sweatshop where suddenly starvation is not a problem.
Yet, still they show up. Stupid savages. They need to have their options
reduced by moralists.
> Secondly,
> the 10k that get the sweatshop jobs may appreciate their increased
> earnings over their countrymen (money works that way, it's how much
> you have in RELATION to others in the market that determines it's
> value) but that doesn't address the effects it has on the population
> as a whole.
The local Nike plant does increase the amount of money circulating
in the local economy. (Otherwise, the folks won't show up.) Some
of that money will go to buying goods that they'd like from outside.
Other of that money will go to higher prices for the local goods
that the Nike workers would have otherwise produced.
Of course, it is degrading work, making shoes for spoiled white folk.
> Lastly, why should they, or anyone for that matter, be
> satisfied with subsistence labor?
They don't have to be satisfied. They merely deserve to make the
best choice from among the options they have, and reducing their
options doesn't help them, no matter how much better you'd feel.
Feel free to risk your money to give them better options. (It
doesn't cost much to set up a light manufacturing plant and Walmart
will buy from anyone.) Of course, if you're wrong about the economics,
but then, you wouldn't possibly be wrong when it's someone else's nickel....
-andy
······@earthlink.net (Andy Freeman) writes:
> > Lastly, why should they, or anyone for that matter, be
> > satisfied with subsistence labor?
>
> They don't have to be satisfied. They merely deserve to make the
> best choice from among the options they have, and reducing their
> options doesn't help them, no matter how much better you'd feel.
Who determines what choices they have? How did those become the
choices?
Don't feel obligated to post your answer, just consider the question.
You can continue this on another newsgroup, alt.cyberpunk is a good
one for such discussion (beleive it or not), but I'm done posting to
this thread on c.l.l.
--
Craig Brozefsky <·····@red-bean.com>
http://www.red-bean.com/~craig
"Indifference is the dead weight of history." -- Antonio Gramsci
Craig Brozefsky wrote:
> [snip]
> This is a very common argument, but I have never seen anything but
> anecdotal evidence to "support" it. For one, everyone outside the
> first-world is not a subsistence farmer. There is not this decision
> between borderline starvation thru farming and scavenging and working
> in a sweatshop where suddenly starvation is not a problem. Secondly,
> the 10k that get the sweatshop jobs may appreciate their increased
> earnings over their countrymen (money works that way, it's how much
> you have in RELATION to others in the market that determines it's
> value) but that doesn't address the effects it has on the population
> as a whole. Lastly, why should they, or anyone for that matter, be
> satisfied with subsistence labor?
>
More interestingly, I have long wondered whether we are captives of our own accounting systems.
Third world women may spend half their day fetching water from the well and another third of it getting food out of the garden, but we would account
for all of that as "nil" as far as contributing to that country's gross domestic product. But, if we give them a loan, and put in a water utility,
and everyone pays a few nickels for the same water, the GDP goes up. Yet, the social benefit is little different if nothing else happens. All that
really changed is the activity became measurable by Western accountants.
Now, it is probably a Good Thing to have women not spending half their day fetching water, especially if the utiltity means that water quality
improves. That, however, is not my point.
My point is, is that we often tacitly and falsely assume all activity is economically measurable. So, if someone survives on "one hundred dollars a
year" we presume that it is "crushing poverty" where it may merely be subsistence farming that has worked for a thousand years and they don't
meaningfully participate in the moneyed economy.
Now, if they all rush to work for Nike when it shows up, then what it really might suggest is that a money economy is a better way of allocating goods
(e.g. managing grain short falls in drough years, having an infrastructure that supports teachers, doctors, and pharmaceuticals, etc.) and so
displaces non-moneyed economies whenever it gets the chance, even at wage levels that strike us as "too low."
But, I have often wondered about whether the mere recitation of a low annual wage in a subsistance society is ipso facto a declaration of suffering
(except maybe that they don't get access to modern medicine).
Larry
Larry Loen <······@rchland.vnet.ibm.com> writes:
> Craig Brozefsky wrote:
> > [snip]
> > This is a very common argument, but I have never seen anything but
> > anecdotal evidence to "support" it. For one, everyone outside the
> > first-world is not a subsistence farmer. There is not this decision
> > between borderline starvation thru farming and scavenging and working
> > in a sweatshop where suddenly starvation is not a problem. Secondly,
> > the 10k that get the sweatshop jobs may appreciate their increased
> > earnings over their countrymen (money works that way, it's how much
> > you have in RELATION to others in the market that determines it's
> > value) but that doesn't address the effects it has on the population
> > as a whole. Lastly, why should they, or anyone for that matter, be
> > satisfied with subsistence labor?
> More interestingly, I have long wondered whether we are captives of
> our own accounting systems.
> Third world women may spend half their day fetching water from the
> well and another third of it getting food out of the garden, but we
> would account for all of that as "nil" as far as contributing to
> that country's gross domestic product. But, if we give them a loan,
> and put in a water utility, and everyone pays a few nickels for the
> same water, the GDP goes up. Yet, the social benefit is little
> different if nothing else happens. All that really changed is the
> activity became measurable by Western accountants.
Much the same principle may be applied to various sorts of "women's
work" in Old, New, and Third Worlds. The things that a "housewife"
does are not formally recognized as part of the economy, and I suspect
that some chunk of the politics surrounding Women in the Workplace
falls out of this.
The economy "grows" when women go to work, even if, at the end of the
day, most of the money generated by such working efforts go into the
combination of (DAYCARE TRANSPORTATION WORKPLACE-FASHIONS).
In effect, the "social benefit" is a lot more limited than the large
sums of money that flow through the economy would imply.
This should not be taken as an argument for some sort of "keep 'em
barefoot'n'expectant" position, but rather just to suggest that
there's some double-counting of value that takes place now as compared
to a vast _ignoring_ of value in the past.
> Now, it is probably a Good Thing to have women not spending half
> their day fetching water, especially if the utiltity means that
> water quality improves. That, however, is not my point.
> My point is, is that we often tacitly and falsely assume all
> activity is economically measurable. So, if someone survives on
> "one hundred dollars a year" we presume that it is "crushing
> poverty" where it may merely be subsistence farming that has worked
> for a thousand years and they don't meaningfully participate in the
> moneyed economy.
I spent a bit of time in India last year, and came to understand that
while there certainly _is_ "crushing poverty" out there, it is by _no_
means as simple to evaluate as:
> (crushing-poverty-p 100)
T
where we have something like:
(defun crushing-poverty-p (income)
(> income *some-minimal-amount-we-like*))
When income is $100, they're certainly _not_ living in something
comparable to what you'd pay $40/year for rent for, here in North
America, and they're _not_ spending $60/year on the food we'd pay
$60/year for here.
They're definitely exceedingly poor, at $100/year, but the notion that
you can _usefully_ compare an income of $100/year (and attendant
living costs) to a North American income (and expenses) of
$30,000/year. The 300x factor on income and expense sides has such
_radical_ effects particularly on expenses that there's not a
particularly useful comparison.
> Now, if they all rush to work for Nike when it shows up, then what
> it really might suggest is that a money economy is a better way of
> allocating goods (e.g. managing grain short falls in drough years,
> having an infrastructure that supports teachers, doctors, and
> pharmaceuticals, etc.) and so displaces non-moneyed economies
> whenever it gets the chance, even at wage levels that strike us as
> "too low."
The big problem that should be thrown into this is that when Nike (or
whomever else) comes to town, they are likely to come in as a single,
huge entity. It's almost as if the Mafia is coming to town; if you
want Western Money, then there's only one place to go, and that's
Nike.
That's _not_ to imply that Nike's inherently a criminal element in
this, but rather describes how they _do_ wind up with an
_extraordinary_ degree of economic power in the relationship, and, in
the resultant non-competitive marketplace, have considerable influence
to dictate very low labour prices.
In effect, it's not that wage levels are generally low in the Third
World that's the problem; it's that when the labour market for
"Western Money" is almost entirely noncompetitive, the big companies
can pretty much dictate that wage levels _stay_ low.
> But, I have often wondered about whether the mere recitation of a
> low annual wage in a subsistance society is ipso facto a declaration
> of suffering (except maybe that they don't get access to modern
> medicine).
Low, low wages do tend to correlate with having a whole lot less in
the way of:
- Nice living quarters
- Nice selection of protein in the diet
- Safe water to drink
But once the numbers fall, and there's a population living on that
"whole lot less," the kinds of things that these less-monied
"consumers" are consuming are very different from what we, in the
West, are accustomed to, and the comparisons quickly get difficult to
the point of being impossible to quantitatively understand.
--
(concatenate 'string "cbbrowne" ·@acm.org")
http://vip.hyperusa.com/~cbbrowne/
`I am convinced that interactive systems will never displace batch
systems for many applications.' - Brooks, _The Mythical Man-Month_
(And this does indeed seem true. MVS/CICS systems have *NOT* gone
away...)
In article <··················@news.blueyonder.co.uk>,
DJC <·····@lostcause.co.uk> wrote:
>On Thu, 05 Jul 2001 21:18:12 GMT, ········@visi.com (David Thornley)
>wrote:
>
>>necessarily likely). People will invest great effort in something
>>that might possibly make them wealthy (not all people, but enough),
>>and will not necessarily work nearly as hard for something that
>>might give them a comfortable retirement at age 62.
>
>But, even if this does promote 'the useful arts', is it a good thing
>for a society in general to promote a 'win a lottery', 'get rich
>quick' mindset? What is so desirable about a frezied pursuit of
>innovation and novelty at any cost?
>
That depends an a whole lot of things, like what you think is "a
good thing" and where you think the consequences go.
There are useful innovations and useless innovations, and it's
really not possible to tell which is which ahead of time.
Among the ones that look like they might be worth trying,
the useless outnumber the useful. Nor is it possible in general
to distinguish between a useless innovation and a potentially
useful one that is not pushed hard.
This means that we want some people to go out there with innovations
that might be useful and put a whole lot of work into trying to
make them pay off. In doing this, we have to take into account
that the majority of these enterprises are going to fail. (Last
time I saw any stats on this, they said that 80% of new businesses
fail within five years.)
What this comes down to is that we need a method of allowing
an entrepeneur to start a business, inducing him or her to work
hard to make it a success, while expecting it to fail.
The concept that the entrepeneur can make lots and lots of money
seems to work well here, not only from an empirical basis but also
from a consideration of the requirements. If we allow only those
businesses to start that are likely to succeed, we miss a lot of
useful innovation. If we provide overly soft landings for the
entrepeneurs, we don't get the same drive to make something
succeed. If we don't have some large reward for success, it just
plain won't look worth it to most people.
As a society, we can roughly balance these things to encourage
people to stick their necks out with new ideas without keeping
the populace in a frenzy of cutthroat competition and novelty-seeking.
Empirically, it seems to be working OK.
>>The only way you can sell a software product to large numbers of
>>people at a large profit is to have some sort of restriction
>>on copying and resale. Copyright is adequate for this.
>
>But this restriction takes two forms: a legal sanction and the cost
>and difficulty of copying. THe second no longer applies to book etc
>and never was in the case of software. So you have a law that is
>unenforceble.
>
What laws are enforceable in that sense? Around here, we have people
violating the law on first-degree murder from time to time. All
the authorities can do is find some of these murderers and put them
in prison for decades.
This is about economics, and so we have to make copyright work on an
economic level. We don't have to have 100% enforcement ability.
Consider Microsoft Office. I would think that the bulk of the
profits for Microsoft come from commercial use, either by
businesses or by vendors buying it to preload on computers they
sell. Businesses and computer vendors have a good deal to lose if
they are caught copying software illegally, and it isn't that hard
to at least get probable cause to check up on them. In the meantime,
there is a good deal of traffic in illicit copies, but it's all on
a small scale and probably doesn't cost Microsoft much.
The biggest problems are in pure consumer software, such as games, but
it seems to me that computer game publishers are staying in business,
although there is some pressure towards cartridge games for specialized
consoles when possible.
BTW, how easy is it to make a copy of a book? Assuming I want to
leave the original intact, I've got to do a good bit of work to
photocopy one, and at the end I've got a stack of photocopies that
is much less usable than a real book. The best I can do with
the equipment in my house is to come up with single-sided spiral-bound
books, like (obLisp) my Garnet documentation. Software is
easy to copy, but books are no easier than they've been for decades.
--
David H. Thornley | If you want my opinion, ask.
·····@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
> But, even if this does promote 'the useful arts', is it a good thing
> for a society in general to promote a 'win a lottery', 'get rich
> quick' mindset? What is so desirable about a frezied pursuit of
> innovation and novelty at any cost?
"At any cost" is a straw man. Being innovative/novel is worth exactly
the same as being non-innovative/novel - they both bring in the price
multiplied by the number of sales. (With the innovative/novel, both,
and their product, tend to be somewhat volatile.)
There is a pursuit to supply innovation and novelty because there is
a significant demand for innovation and novelty. Moreover, you (mostly,
the exceptions are largely govt driven although the concerns are mostly
about biz) get to decide which innovation/novelty that you reward.
The problem is that the rest of you don't have my good sense, so you
reward the wrong things. (I sat out disco and rap, yet they are/were
rewarded.) Any suggestions on how to deal with your failures?
> So you have a law that is unenforceble.
What's an enforceable law? Are there any examples? (I know what a
profitable law is, one where the realized benefits exceed the incurred
expenses. Interestingly enough, we don't put bankrupt laws out of our
misery - we'll stick with things that haven't, and never have, delivered
any actual benefits, and we'll incur the costs of jailing people who
violate them.)
-andy
······@earthlink.net (Andy Freeman) wrote in message
> misery - we'll stick with things that haven't, and never have, delivered
^^^^
will
> any actual benefits, and we'll incur the costs of jailing people who
> violate them.)
The damage caused by these violators is, of course, evidence of the law's
failure, not an argument for its necesssity.
-andy
Andy Freeman <······@earthlink.net> wrote in message
·································@posting.google.com...
> What's an enforceable law? Are there any examples? (I know what a
> profitable law is, one where the realized benefits exceed the incurred
> expenses. Interestingly enough, we don't put bankrupt laws out of our
> misery - we'll stick with things that haven't, and never have, delivered
> any actual benefits, and we'll incur the costs of jailing people who
> violate them.)
Actually, I doubt this - for instance drug laws. They benefit the
ordinary
citizen not one bit, but they do allow the state to massively increase their
power, and to co-opt existing institutions which (at least ostensibly) serve
a purpose to place more people very directly in their (absolute) power.
David Thornley <········@visi.com> wrote in message
··························@ruti.visi.com...
> (Disclaimer: I am an open-source advocate, but not a fanatic.
> I do believe that there have got to be better ways to finance
> the making of high-quality software, but I haven't found any
> compatible with the way the economy works today. I make no
> promises about the future.)
Hear hear.
········@visi.com (David Thornley) writes:
> In article <··················@helice>, George Neuner <·······@dyn.com> wrote:
>
> >As a developer, I have never been a fan of patent or copyright
> >protection for software. Patents were designed for manufacturing
> >industry and copyrights for publishing books ... I don't happen to
> >think software is a particularly good match for either.
> >
> Not really, but there does have to be some sort of IP protection.
> I'm not totally against patents, but I think there are severe
> problems with the software patent practice (for one thing, the
> definitions of "obvious" appropriate for an electric or mechanical
> system are not appropriate for a software system). Copyright
> seems like a reasonable match.
>
Software patents are ridiculous -- especially given their far too wide
scope. Copyright is a better solution and it does not prevent others
from using something that is sort of similar to something that is
somewhat like the patented idea.
> The US Constitution gives Congress the right to make these laws
> for the purpose of promoting the advancement of the useful arts.
> The best general way I know of to promote something is to make
> it possible to make lots and lots of money off it (although not
> necessarily likely). People will invest great effort in something
> that might possibly make them wealthy (not all people, but enough),
> and will not necessarily work nearly as hard for something that
> might give them a comfortable retirement at age 62.
>
> The way to make lots and lots of money off something is to come up
> with some method whereby you do something once that is valuable to
> many people. In software, you make millions (when you do) by
> writing software and selling it over and over again to lots of
> people. You can't make millions by selling services, and technical
> books simply don't sell like Tom Clancy's books do (unless, I
> guess, Clancy writes them, and I'd suspect that his fiction
> outsells his nonfiction by a large margin).
>
Well, you can make millions by selling services, IMHO. Does Red Hat
*write* the vast majority of software they distribute? No, they sell a
*service*: stuffing lots of free software onto a CD-ROM with an
installer, manual, and support. Mandrake, Ximian, etc, are also
similar. LinuxCare sells support. TheKompany sells (among other
things) CD-ROMs with developer's tools on them. I don't know how many
of these companies ``make millions'' but I am sure they make a lot of
money. RMS works for two months a year doing consulting work and
spends the rest of his time working on GNU projects and running the
FSF. It is possible to make a lot of money on non-proprietary
software, even in cases such as Red Hat the millions of dollars that
you cite as a way to promote software.
But then I would be missing the larger `misteak': money is not the
only way to promote something. If you find some people who think that
Emacs is really interesting, and offer to pay them enough to live
comfortably on while they hack up Emacs-related stuff (to be released
as free software with support services etc), will they take the offer?
(You can replace Emacs with KDE, GNOME, Python, Linux kernel, whatever
extensible system you like best.) I know that I would rather work on
interesting free software than uninteresting proprietary software; and
I would rather work on interesting free software than interesting
proprietary software. Being able to freely modify interesting systems
would be a very good job IMO. So interesting free software projects
are an incentive.
#ifdef I-HATE-CERTIFICATION
Not only that, but lots of money can actually *decrease* the quality
of software. How many people with no technical skill do you see
developing free software? Compare that with the number of code
grinders on <a-propriety-OS>. Lots of money encourages people to go
take certification exams and get almost every correct answer by
memorizing the contents of
<FakeURL:http://www.make-lots-of-$$$.com/secret/answers.htm>, which
they found using Ask Jeeves. Then they get WinNT administration jobs.
Then the company finds that their systems don't work and they fire
that person. Then the person takes some ``M$ Visual BASIC
Certification Test'' and finds another job. They haven't programmed
before so they pay $999.99 for a ``M$ VB Guranteed Certification
Class'' and learn how to make a graphical ``Hello World'' program
(which pops up a friendly dialog box when it crashes). Then they go
and barely pass the test, wave their certification certificate at a
company, get hired, and write terrible software that barely works at
all.
True, this is *not* the average story of a proprietary programmer. But
it is becoming more common. Now that Big Companies (IBM, etc) have
found free software and there are ``Linux Certification Exams'', will
free software suffer the same fate? I say ``no'', because to write
working programs on GNU/Linux and BSD systems there is enough of a
beginning learning curve that an idiot can't write a graphical Hello
World program without understanding the system enough to write decent
software. GNOME and KDE change nothing -- you *still* need to have
some programming skills to write a slightly complex program in the
Unix environment, whereas on M$-Windoze you fill in the blanks to get
an event handler.
#endif I-HATE-CERTIFICATION
> The only way you can sell a software product to large numbers of
> people at a large profit is to have some sort of restriction
> on copying and resale. Copyright is adequate for this.
>
Not true (``the only way...'' part). Think of GNU/Linux distros.
Mandrake and Corel make money selling to newbies. Debian and Progeny
market to developers (Debian's a non profit but they do sell CDs). Red
Hat and SuSE fall into ``general purpose'' distos (meaning, they're
not by default great for any one thing, but can do everything fairly
well if you know what you want to do). Slackware is mostly for
networking, somewhat for developers. Etc etc.
Ximian sells CD-ROMs with Ximian GNOME on them (the CDs probably cost
$0.50 each to make) for $25 (both values in US dollars). ThinkGeek is
not software but makes tons of money selling T-shirts, coffee mugs,
and Nerf guns to software developers. The FSF gets funding from
selling manuals to GNU software. Sun Microsystems open-sourced
StarOffice but I think that they still sell it. You can buy CD-ROM
snapshots of major open-source Unix software sites (SunSITE.unc.edu
(which is now metalab.unc.edu (which is now part of www.ibiblio.org)),
etc). LinuxCare sells support. Etc etc.
I won't list more examples, you can find more if you want them.
> (Consider the business I work for. We make a very large and
> complicated product that is very useful, partly from its
> comprehensiveness, and so we sell it for large amounts of
> money. The ability to charge hundreds of thousands, or even
> millions, of dollars for a short stack of CD-ROMs is what
> makes it possible to make this product.)
>
Well, from the next paragraph I assume you don't think its possible to
make lots of money from Open Source software. Consider that you
*could* sell your CD-ROMs for the same amount. Consider that you could
make some parts of your product free software/Open Source, and keep
some parts proprietary. For example, Scriptics (or whatever the Tcl
company is called) makes Tcl/Tk free software, and write proprietary
development tools for it (TclPro is their main product IIRC). I know
you most likely don't have enough influence to release an Open Source
product, but I am just trying to convince you that making money on
Open Source is possible. In addition, let's not forget selling tech
support, consulting, etc. Large, comprehensive systems (Unix, Emacs,
*probably your product*) are wonderful targets for consulting
contracts.
> (Disclaimer: I am an open-source advocate, but not a fanatic.
> I do believe that there have got to be better ways to finance
> the making of high-quality software, but I haven't found any
> compatible with the way the economy works today. I make no
> promises about the future.)
>
CoSource and SourceXchange type systems might work. I don't think
these particular implementations of the idea have any future but if I
suddenly gain huge amounts of free time and money I'll think about
trying to start something similar. It's easy to design, expensive to
implement...
> --
> David H. Thornley | If you want my opinion, ask.
> ·····@thornley.net | If you don't, flee.
> http://www.thornley.net/~thornley/david/ | O-
--
BPT <···@hobbiton.org>
backronym for Linux: Linux Is Not Unix
······@earthlink.net (Andy Freeman) writes:
> > > A core value I'm trying to protect is the right of people to think.
> > > At its core level, programming is not much different from speaking
> > > or thinking. It is just expressing a concise and clear thought about
> > > a process or procedure. That there should be liability incurred in
> > > such an act is deeply wrong, IMO.
> >
> > Agreed; it's also deeply wrong that such an act could be patented.
>
> Do you also object to patents that result from someone drawing something,
> say a novel fluid pump?
Btw, I think the key here is that the "patent" should allow those with a
brain to independently derive the thing. If I say "think of a way to do x"
and you think somehting up that's patented, that should be not preclude you
from using the thing, it should invalidate the patent--at least for you.
It works that way for copyright.
Back on the subject of whether programmers should be liable, whoever invents
the first thinking droid might as well just commit suicide rather than face
the lawsuits that will ensue...
> > Do you also object to patents that result from someone drawing something,
> > say a novel fluid pump?
>
> Btw, I think the key here is that the "patent" should allow those with a
> brain to independently derive the thing. If I say "think of a way to do x"
> and you think somehting up that's patented, that should be not preclude you
> from using the thing, it should invalidate the patent--at least for you.
> It works that way for copyright.
Independent creation is a statutory defense against copyright infringement
liability, but I wonder how often it works in practice.
For what it's worth, US patent law doesn't seem to actually care about
"with a brain" when it comes to granting applications. There's a personhood
requirement (unlike with copyright), which will eventually result in
some significant legal expenses, but I suspect that initial ownership of
machine-made inventions will rest with "the operator" and assignment
contracts will do the impedance match to reality. (We've almost
certainly seen something similar before, as some inventors delegate
certain activities and then use the results as part of an invention.
The question is always whether the delagee contributes to the novelty
of the invention, not whether they did something novel to contribute;
the latter would be the subject of their invention.)
With copyright, the corporate overlord in charge of the million monkeys
at typewriters for a very long time already gets the copyright. With
patents, that option isn't available, but operator pass-through works.
It's unlikely that a "the invention doesn't belong to anyone" result
will ensue, if for no other reason than we'll approach "operator pass-through
via precedents as the operator contributes less and less to the process.
(Some will note the invention comes from the person who established
the system, not the person who put the cards into the machine, but I'm
looking towards the truely autonmous invention machine.)
> Back on the subject of whether programmers should be liable, whoever invents
> the first thinking droid might as well just commit suicide rather than face
> the lawsuits that will ensue...
It depends on what the droid does. For example, if the droid was the
CAD equivalent of the million monkeys at typewriters for a very long
time, and there was an attached filter to recognize utility & novelty
for function, you don't have to file, you could just publish, which
bars filing by subsequent inventors.
-andy
Kent M Pitman <······@world.std.com> writes:
> > > Agreed; it's also deeply wrong that such an act could be patented.
> >
> > Do you also object to patents that result from someone drawing something,
> > say a novel fluid pump?
>
> Btw, I think the key here is that the "patent" should allow those with a
> brain to independently derive the thing. If I say "think of a way to do x"
> and you think somehting up that's patented, that should be not preclude you
> from using the thing, it should invalidate the patent--at least for you.
> It works that way for copyright.
The core purpose of patent is to encourage the sharing of ideas with
the public. This is why patents are available for public viewing.
One way it enocurages this publication is by granting temporary
monopoly on the idea or process. If someone could come along and copy
your process, but claim they never saw your patent, then it would
severely undermine patent's intent to grant temporary monopoly.
Patent and copyright protect two different things. Your idea is
feasible for copyright, because copyright protects the expression of
an idea or proces, whereas patents protect a particular idea or
process.
Mind you, I think patents should be irradicated or SEVERELY reformed.
--
Craig Brozefsky <·····@red-bean.com>
http://www.red-bean.com/~craig
"Indifference is the dead weight of history." -- Antonio Gramsci
Craig Brozefsky <·····@red-bean.com> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > > > Agreed; it's also deeply wrong that such an act could be patented.
> > >
> > > Do you also object to patents that result from someone drawing something,
> > > say a novel fluid pump?
> >
> > Btw, I think the key here is that the "patent" should allow those with a
> > brain to independently derive the thing. If I say "think of a way to do x"
> > and you think somehting up that's patented, that should be not preclude you
> > from using the thing, it should invalidate the patent--at least for you.
> > It works that way for copyright.
>
> The core purpose of patent is to encourage the sharing of ideas with
> the public.
Yes, certainly. Same as with copyrights. But what I'm saying is that at
the same time, if you share something with the public and they immediately
"get it", that's some evidence to me that what you shared is of less value.
The simplest way to fix all the fights likely to occur over this, IMO,
is just to keep patent rights short. I think patent should protect
time to market--saying that if you put something out and it's
interesting and cool, you get a brief duration during which you can
recover your costs of development, but not an infinite monopoly. Since
most software is obsolete in 3 years or less, it seems hard for me to
see a justification in any software patent lasting longer than that.
In 99% of cases, if you haven't made your fortune by that time, it
wasn't the big deal thing you thought...
> Patent and copyright protect two different things. Your idea is
> feasible for copyright, because copyright protects the expression of
> an idea or proces, whereas patents protect a particular idea or
> process.
Er, I don't *think* you can patent an idea. I think it has to be a process.
> Mind you, I think patents should be irradicated or SEVERELY reformed.
Yep.
> Yes, certainly. Same as with copyrights. But what I'm saying is that at
> the same time, if you share something with the public and they immediately
> "get it", that's some evidence to me that what you shared is of less value.
I think that the various incompleteness theorems, NP-completeness,
and even diagonalization are counter-examples. Lots of things are
blindingly obvious in retrospect; I don't see how that correlates
with value.
In any event, patents aren't a guarantee of value, they're a reward
for revealing novelty. One might argue that obvious in retrospect
is evidence against novelty, but it seems weak at best.
> most software is obsolete in 3 years or less, it seems hard for me to
> see a justification in any software patent lasting longer than that.
> In 99% of cases, if you haven't made your fortune by that time, it
> wasn't the big deal thing you thought...
Consider linear programming. A given program may well be obsolete
in 3 years, but a significant advance in linear programming would have
benefits that lasted long after its first implementation was obsolete.
Heck - programs fail to make money for lots of reasons; why should
protection lapse just as rev 3.1 hits the market?
It's somewhat surprising to see KMP claim that an algorithm developer's
livelyhood should be tied to the success of a software product....
Remember, trade secrets are the alternative to patents. TSs can
live forever.... (Independent development is a defense, but if
a Microsoft executes a well-designed plan of exploitation, it can
be extremely difficult to find competent independents.)
> Er, I don't *think* you can patent an idea. I think it has to be a process.
mechanism/process for function
-andy
"Andy Freeman" <······@earthlink.net> wrote
> > Er, I don't *think* you can patent an idea. I think it has to be a
process.
> mechanism/process for function
Yes but the problem is that the USPTO seems to have a broad idea of what is
a "process". As they can't afford competent people to look at the claims'
validity and non obviousness, it's mainly a registration system.
So far so good, the pb comes later. As it's only a timestamp on some claims
you then have to go to the legal system to challenge or enforce it. And so
the biggest problem is that the patent system protection works mainly for
big firms who can afford hordes of lawyers. Look at amazon patents for
instance, they have no validity but you have to prove this in court. This
takes time and money that small company can't afford. If at the beginning of
the Internet, somebody could have imagined that the USPTO was accepting
shopping cart patents he would have patented 42 ways to do it and then would
have been granted a monopoly on e-commerce.
BTW Europeans interested in that subject should look at the "Petition for a
Software Patent Free Europe" :
http://petition.eurolinux.org/index_html?LANG=en
Just my 0.02 euros.
Marc
PS a quote from Wired
(http://www.wired.com/news/politics/0,1283,19473,00.html):
More recently, the PTO has awarded patents for actual Internet business
models.
Priceline.com is defending a patent awarded for its "name-your-price"
business method. Sightsound.com is fending off an effort by N2K to take down
its patent on the concept of selling music downloads over the Net. And
Netword recently lost a court battle over a patent covering the use of
keywords to represent Web addresses.
Such cases have renewed criticism of the PTO among lawyers and Net activists
for having granted the likes of patent number US05491779 -- a
"three-dimensional presentation of multiple data sets in unitary format with
pie charts." The document grants ownership of the 3-D pie chart.
······@earthlink.net (Andy Freeman) writes:
> > most software is obsolete in 3 years or less, it seems hard for me to
> > see a justification in any software patent lasting longer than that.
> > In 99% of cases, if you haven't made your fortune by that time, it
> > wasn't the big deal thing you thought...
>
> Consider linear programming. A given program may well be obsolete
> in 3 years, but a significant advance in linear programming would have
> benefits that lasted long after its first implementation was obsolete.
Well, first, I'd guess meta-issues like this are probably rare. I bet
most patents are first-order. Not that that's material to my
thinking, but I wonder how typical this is.
Even so, let's look at it this way: If you know a piece of
meta-information, there's no reason for you to share it and get
protection on it if you can "down" the information one level and
patent the process. Trade secret protection is much better than
patent protection in this case, because you are not revealing the
process at all--no need.
But *if* you think that doing one or two or three examples of the
lower-level process will reveal the meta-information, then the value
of the meta-information is, it seems to me, of little value beyond the
value of any given specific solution, since you're saying anyone who
comes up with that same solution risks getting the meta-solution
whether or not YOU know it. (For example, you might just be lucky and
someone else can generalize it.)
> Heck - programs fail to make money for lots of reasons; why should
> protection lapse just as rev 3.1 hits the market?
Because the market values having the solution in the hands of someone
who can work with it. You profess, as the inventor, to understand it.
It's not the job of the market to make you a winner, it's the job of
the market to give you a fighting chance in situations where you have
something to trade.
> It's somewhat surprising to see KMP claim that an algorithm developer's
> livelyhood should be tied to the success of a software product....
Then it's good we had this discussion. I don't think this is a shift
of position for me. I think perhaps you've just heard too many people say
"Geez, kent, you think the market owes you money" when I've been saying
something else entirely.
I've worked many times for companies like Symbolics and others that have taken
good technical stuff and effectively failed. I think it would be fair to see
that IP return to the people who produced it if the sharks who buy it are
just going to lock it in a drawer. (The "abandonment concept".) But
mostly that's a "copyright" issue, because their hold on that software doesn't
keep someone from writing something that does effectively the identical thing
from scratch. I absolutely believe that patent protection
should revert to "the world in general" once an inventor has had his shot,
rather than just saying "no one can use it". And, moreover, I think it's the
responsibility of the inventor to pick a winning team--he can't just say
"I did my part, I deserve to win" more than anyone else in the market can.
If I thought that, I'd just propose government stipends for inventors and
I definitely don't want to do that.
> Remember, trade secrets are the alternative to patents. TSs can
> live forever.... (Independent development is a defense, but if
> a Microsoft executes a well-designed plan of exploitation, it can
> be extremely difficult to find competent independents.)
I'm not sure I can see what you're getting at here. Can you make this
more concrete (even if you have to make up dtails). Aren't there
generally enough people outside any given organization that if a good
idea is published which is "obvious", that trade-secret wouldn't
matter. And if the thing is not published, isn't TS already a
problem? What's to stop someone who doesn't want to share, right now
as bandwidths get fast, from selling only servers and never giving you
the bits to software ever again?
> > Consider linear programming.
...
> Well, first, I'd guess meta-issues like this are probably rare.
However, we either come up with a system that can semi-reasonably
distinguish these cases or we're forced to ignore the distinction.
In a world where Disney's trademarks are better than mine, I wouldn't
bet that the distinction will do the right thing.
> > It's somewhat surprising to see KMP claim that an algorithm developer's
> > livelyhood should be tied to the success of a software product....
>
> Then it's good we had this discussion. I don't think this is a shift
> of position for me. I think perhaps you've just heard too many people say
> "Geez, kent, you think the market owes you money" when I've been saying
> something else entirely.
I don't think that you've said that the market owes you money. I thought
that you wrote that you should be allowed to sell your work-product under
the terms that you find acceptable. When someone offered "you can always
do software support" as an alternative, you objected.
An algorithm developer might well ask for the same thing and object to the
"you can always develop software, and you get one chance to get it right"
alternative.
I think that we should encourage people to try things that take a long time
to try, say decades. If they fail, that's the breaks; they take the loss.
However, the only way to get them to try is for there to be a potentially
large payoff if they succeed.
> from scratch. I absolutely believe that patent protection
> should revert to "the world in general" once an inventor has had his shot,
> rather than just saying "no one can use it".
Since that's not what the patent system does, I don't see the relevance.
Moreover, as a practical matter, I suspect that most "in a drawer" patents
never result in infringement actions. In addition, the people who own that
drawer are almost always quite happy to sell, if the price is right.
Also, the sharks bought the IP. It was collateral. It wouldn't have
been developed without their money. If they're not going to get it when
things go wrong (for the chance to sell it later), they'll merely put up
less money. I don't see how that's necessarily a good thing.
> > Remember, trade secrets are the alternative to patents. TSs can
> > live forever.... (Independent development is a defense, but if
> > a Microsoft executes a well-designed plan of exploitation, it can
> > be extremely difficult to find competent independents.)
>
> I'm not sure I can see what you're getting at here. Can you make this
> more concrete (even if you have to make up dtails). Aren't there
> generally enough people outside any given organization that if a good
> idea is published which is "obvious", that trade-secret wouldn't
> matter.
It's not whether there are enough good people outside, it's whether
there are enough good people who aren't tainted. One way to taint people
is through contact at a university. ("Okay class, we're going to learn
about operating systems by studying Unix(TM), thanks to some help from
our friends at AT&T.") Another way is through contact at an employer
who happens to have the relevant contracts. Individuals can also get
tainted through agreements such as "in accepting this license, you won't
reveal its trade secrets".
The system doesn't quite make this possible, but if the alternative is
no patent-like protection, I doubt that the relevant changes won't happen.
(This sort of thing is only an option for Microsoft today and IBM of the
early 60s.)
> And if the thing is not published, isn't TS already a
> problem? What's to stop someone who doesn't want to share, right now
> as bandwidths get fast, from selling only servers and never giving you
> the bits to software ever again?
I've been wondering about how the GPL is going to deal with this.
-andy
······@earthlink.net (Andy Freeman) writes:
[I left out some of your message that I didn't have an immediate reaction
to. I'll think about whether to reply to more of it later.]
> It's not whether there are enough good people outside, it's whether
> there are enough good people who aren't tainted. One way to taint people
> is through contact at a university. ("Okay class, we're going to learn
> about operating systems by studying Unix(TM), thanks to some help from
> our friends at AT&T.") Another way is through contact at an employer
> who happens to have the relevant contracts. Individuals can also get
> tainted through agreements such as "in accepting this license, you won't
> reveal its trade secrets".
I've seen this kind of fear introduced by people, but I don't know if it
holds up legally and I certainly don't think it should. The university
is almost surely the one that will get screwed on this, at least until
universities start taking better care. But surely students, who are not
in general employees, are not bound by agreements made by the school. A
good school might make them sign an NDA to take certain classes, but if
it fails to, I think that's the school screwing up, not the person being
tainted...
I also think that unless a company specifies which parts are the trade
secrets, a broad claim that an entire body of code is a trade secret is
very, very marginal.
I saw exactly the process you're talking about happen with Unix/AT&T and
someone when I was and undergrad. But I don't think, in the end, they managed
to get that level of hold on people...
Also, I've never seen enumerated the legal remedy issues if a trade secret
is violated and it gets into the hands of someone not bound by the
agreement.
> > And if the thing is not published, isn't TS already a
> > problem? What's to stop someone who doesn't want to share, right now
> > as bandwidths get fast, from selling only servers and never giving you
> > the bits to software ever again?
>
> I've been wondering about how the GPL is going to deal with this.
I think by its own reverse-FUD campaign saying that you can't trust a system
that is server-based because you can't tell what it's going to do if you don't
see its source code. Whether people will buy that level of paranoia is hard
to tell. The population may segment itself into people who believe this
completely and people who think it's silly. Whether it will make a difference
in practice will be interesting to see.
Kent M Pitman <······@world.std.com> wrote in message news:<···············@world.std.com>...
> ······@earthlink.net (Andy Freeman) writes:
> > It's not whether there are enough good people outside, it's whether
> > there are enough good people who aren't tainted. One way to taint people
> > is through contact at a university. ("Okay class, we're going to learn
> > about operating systems by studying Unix(TM), thanks to some help from
> > our friends at AT&T.") Another way is through contact at an employer
> > who happens to have the relevant contracts. Individuals can also get
> > tainted through agreements such as "in accepting this license, you won't
> > reveal its trade secrets".
>
> I've seen this kind of fear introduced by people, but I don't know if it
> holds up legally and I certainly don't think it should.
"The prerequisite for taking CS492, advanced operating systems, is signing
an NDA with AT&T." or "The CS362 series uses Oracle. Oracle has graciously
provided inexpensive student versions." (and those versions have an appropriate
EULA).
Yes, some professors won't go along, and fewer universities will make blanket
policies against this (reraising interesting questions wrt existing sponsored
research, questions that the universities have already answered with "we'll
take the restrictions to get the money"), but I don't see that as significant
protection.
I don't think that they can quite pull it off today, but Congress is in
session and has been sympathetic to the required minor tweaks for decades.
Right now, there's not much incentive to lobby for those changes or to
try to taint people. That's the only significant protection that I see.
> Also, I've never seen enumerated the legal remedy issues if a trade secret
> is violated and it gets into the hands of someone not bound by the
> agreement.
If I steal your car and then sell/give it to someone else, who then
does the same, you can get it back without compensating the eventual
end of that chain. That end person is out whatever they spent unless
they can recover from their seller, and so on.
I don't know whether trade secrets work the same way. However, if
you're making a biz out of that innocently acquired trade secret,
do you want a jury to hear that argument? Will a VC invest with
that possible risk? Will customers buy if they think that you
might be diverted from support and developing V1.5 by such a trial?
> > I've been wondering about how the GPL is going to deal with this.
>
> I think by its own reverse-FUD campaign saying that you can't trust a system
> that is server-based because you can't tell what it's going to do if you don't
> see its source code. Whether people will buy that level of paranoia is hard
> to tell. The population may segment itself into people who believe this
> completely and people who think it's silly. Whether it will make a difference
> in practice will be interesting to see.
Considering how few people care about the source code that they can't see
now, I don't see that significant numbers will care in the future.
-andy
Andy Freeman <······@earthlink.net> wrote in message
·································@posting.google.com...
> Kent M Pitman <······@world.std.com> wrote in message
news:<···············@world.std.com>...
> > ······@earthlink.net (Andy Freeman) writes:
> Considering how few people care about the source code that they can't see
> now, I don't see that significant numbers will care in the future.
I agree - it's likely to be the same people who need to see the source
now. That is, those purchasing an encryption product (Where access to the
source is not important because I need to understand it, but rather because
I need to know that there are going to be quite a few people out there who
can independantly scrutinise that code and cry foul); and those who are
investing in a product that is going to become central to their business,
and is going to become a legacy component - these people like open source,
because if the supplier and supporter disappears, they don't have to
re-engineer their whole system. Of course, the other choice is to buy from
someone huge and reliable, who will happily maintain this stuff, and if
no-one else wants it, will sell it dirt cheap.
Andy Freeman wrote:
[snip]
>
> I don't know whether trade secrets work the same way. However, if
> you're making a biz out of that innocently acquired trade secret,
> do you want a jury to hear that argument? Will a VC invest with
> that possible risk? Will customers buy if they think that you
> might be diverted from support and developing V1.5 by such a trial?
>
Um, I thought that keeping a trade secret secret was largely if not exclusively the responsibility of the person owning the secret.
If the secret gets out, why would companies owning the secret have more protection than the government did in the Pentagon Papers case (assuming no
confidentiality disclosures were breached to get the secret)?
I don't know if anyone has convincingly reverse-engineered the formula for Coca-Cola, but I never read or heard that if you sold something that used
that formula, there were grounds to sue you. The company might do so anyway, just to try and sue you out of business, but I'm having a hard time
understanding the legal grounds for "I lost my secret, so the company that got it must pay." Applied broadly, this would turn trade secrets into
super-patents, and into perpetuity at that. Moreover, since it is by definition a secret, how does one avoid after-the-fact claims of the sort "I
didn't patent this, I kept it secret instead, and now company B must pay me for infringing on my secret." This wouldn't happen for Coke's formula,
because the fact that there _is_ a secret is known, but a lot of secrets aren't even known to exist by the outsiders.
Larry
Larry Loen <······@rchland.vnet.ibm.com> wrote in message news:<·················@rchland.vnet.ibm.com>...
> Andy Freeman wrote:
> > I don't know whether trade secrets work the same way. However, if
> > you're making a biz out of that innocently acquired trade secret,
> > do you want a jury to hear that argument? Will a VC invest with
> > that possible risk? Will customers buy if they think that you
> > might be diverted from support and developing V1.5 by such a trial?
> >
>
> Um, I thought that keeping a trade secret secret was largely if not
> exclusively the responsibility of the person owning the secret.
It is. However, they still have recourse if it gets out.
> If the secret gets out, why would companies owning the secret have more
> protection than the government did in the Pentagon Papers case
The US govt operates under different constraints. For example, you're
not entitled to a copy of the 747's blueprints, but you are entitled to
a copy of the space shuttle's blueprints.
> (assuming no confidentiality disclosures were breached to get the secret)?
You can't make that assumption. Or rather, even if you got it innocently,
you run the risk of being sued by an owner who feels differently. (We
were discussing the case where someone did violate such an agreement
but passed it on to someone who is unaware of the violation.)
It doesn't matter whether you "should" win such a lawsuit. The question
is whether you can survive one, or even the threat of one. Where will
you get funding with that cloud hanging over you?
-andy
Andy Freeman wrote:
> It doesn't matter whether you "should" win such a lawsuit. The question
> is whether you can survive one, or even the threat of one. Where will
> you get funding with that cloud hanging over you?
>
> -andy
Oh, I see. As is often the case with the powerful, the protections are extra-legal.
I suppose the only hope is a contingency-fee countersuit. . .but we're getting into mutual sleeze now.
Larry
In article <···············@world.std.com>,
Kent M Pitman <······@world.std.com> wrote:
>······@earthlink.net (Andy Freeman) writes:
>
Disclaimer: I am not a lawyer. Do not act on anything I suggest
without consulting a good intellectual property lawyer. This is
speculation based on an incomplete knowledge of the law.
>> It's not whether there are enough good people outside, it's whether
>> there are enough good people who aren't tainted. One way to taint people
>
>I've seen this kind of fear introduced by people, but I don't know if it
>holds up legally and I certainly don't think it should.
We're talking here about the form of intellectual property known as
"trade secret", and IIRC one of the important things about this is
that it is a secret. These are recognized in law, and there are
laws about them. I believe that the law does require the possessor
of a trade secret to take some effort to maintain secrecy.
I really, really doubt that it would be possible to expose a large
number of college students to something and claim it's a secret.
The university
>is almost surely the one that will get screwed on this, at least until
>universities start taking better care.
How many universities are allowed to work with trade secrets right now,
other than in strictly controlled circumstances? If I had a business
with a trade secret, there's no way I'd allow that secret into a
classroom.
>I also think that unless a company specifies which parts are the trade
>secrets, a broad claim that an entire body of code is a trade secret is
>very, very marginal.
>
Probably. The proper protection for an entire body of code is copyright.
If there are secret algorithms or something in there, either keep them
a secret (probably not feasible) or patent them.
>Also, I've never seen enumerated the legal remedy issues if a trade secret
>is violated and it gets into the hands of someone not bound by the
>agreement.
>
I *think* it's illegal in the US to deliberately do anything to
reveal a trade secret without permission of the secret owner.
If a professor knows the secret and teaches it in a class, the
professor's probably liable (and maybe also the college). If
a student makes a serious attempt to learn it, possibly through
bribery or rifling files, that's probably illegal. If a person
innocently comes into possession of a trade secret, I really
doubt there's much the law can do about it. Given enough freshmen,
somebody's going to spill the beans. You can go after him or her
and sue the violator for the $2.43 that he or she is worth in
total assets, but that's not going to put the secret back.
>> > And if the thing is not published, isn't TS already a
>> > problem?
Well, TS could apply then. What's the problem?
It seems to me that TS is self-limiting. Show it to everybody and
it isn't a secret anymore. Don't show it to people and other people
can reverse-engineer it or invent something similar freely.
What's to stop someone who doesn't want to share, right now
>> > as bandwidths get fast, from selling only servers and never giving you
>> > the bits to software ever again?
>>
>> I've been wondering about how the GPL is going to deal with this.
>
>I think by its own reverse-FUD campaign saying that you can't trust a system
>that is server-based because you can't tell what it's going to do if you don't
>see its source code. Whether people will buy that level of paranoia is hard
>to tell. The population may segment itself into people who believe this
>completely and people who think it's silly. Whether it will make a difference
>in practice will be interesting to see.
There are applications where I think the open source code idea is
perfectly valid, although obviously in most cases it doesn't matter.
Most Linux users aren't going to do a thing with the source code.
The big difference with server-based stuff where you don't buy the bits
is that you are putting stuff in somebody else's hands.
When you use a server for something instead of having everything in-house,
you're relying on the people running the server. If they have problems,
you have problems. If they go out of business, you may suddenly have
vital business functions and information unavailable for an unknown
period of time. If they don't maintain a secure environment, it's
your secrets that are at risk.
Obviously this is not going to stop people from using server-based
facilities, but it is going to ensure that there is a continued
market for software that the business can buy or lease and
run on its own hardware.
It winds up in the same sort of thing as internal use of GPLed
software. Suppose you rewrite part of gcc to make it work better
for you, and don't distribute the compiler. You don't have to share
it. If you do, of course, you must supply source code and must
release it under the GPL. I haven't heard RMS complaining excessively
about that (although I will not warrant that I've heard all of
his excessive complaints).
--
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 <········@visi.com> wrote in message
··························@ruti.visi.com...
> In article <···············@world.std.com>,
> Kent M Pitman <······@world.std.com> wrote:
> >······@earthlink.net (Andy Freeman) writes:
> It winds up in the same sort of thing as internal use of GPLed
> software. Suppose you rewrite part of gcc to make it work better
> for you, and don't distribute the compiler. You don't have to share
> it. If you do, of course, you must supply source code and must
> release it under the GPL. I haven't heard RMS complaining excessively
> about that (although I will not warrant that I've heard all of
> his excessive complaints).
On the one hand, the GPL really bugs me - you can't make bits of a gpl
work better, then use the whole, improved work, packaged up in some way so
that you can only distribute the code to the gpl work, and use that
(modified, open) work as part of work including closed source. Hence, you
can only use non-gpl and closed together if you write some libraries, and
make the GPL work call your libraries. This seems wrong. (Obviously, LGPL
addresses this). By contrast, I fully understand that having written
something and given it away, one might not want to allow someone to make
large amounts of money from merely writing a thin layer atop your work
(Although only where your work is significantly innovative - if I write a
hello world implementation, protecting it with the gpl seems smallminded; if
I write a successful AI core, I might want to see a significant benefit from
any commercial application.)
"Marcin Tustin" <·······@GUeswhatthisbitisfor.mindless.com> writes:
> David Thornley <········@visi.com> wrote in message
> ··························@ruti.visi.com...
> > In article <···············@world.std.com>,
> > Kent M Pitman <······@world.std.com> wrote:
My name is quoted here but the text being replied to is not mine, in spite
of the mixed up levels of anglebrackets. I think it's andy talking.
> > >······@earthlink.net (Andy Freeman) writes:
>
> > It winds up in the same sort of thing as internal use of GPLed
> > software. Suppose you rewrite part of gcc to make it work better
> > for you, and don't distribute the compiler. You don't have to share
> > it. If you do, of course, you must supply source code and must
> > release it under the GPL. I haven't heard RMS complaining excessively
> > about that (although I will not warrant that I've heard all of
> > his excessive complaints).
>
> On the one hand, the GPL really bugs me - you can't make bits of a gpl
> work better, then use the whole, improved work, packaged up in some way so
> that you can only distribute the code to the gpl work, and use that
> (modified, open) work as part of work including closed source. Hence, you
> can only use non-gpl and closed together if you write some libraries, and
> make the GPL work call your libraries. This seems wrong. (Obviously, LGPL
> addresses this). By contrast, I fully understand that having written
> something and given it away, one might not want to allow someone to make
> large amounts of money from merely writing a thin layer atop your work
> (Although only where your work is significantly innovative - if I write a
> hello world implementation, protecting it with the gpl seems smallminded; if
> I write a successful AI core, I might want to see a significant benefit from
> any commercial application.)
I think LGPL is for what you want.
But regardless, you always have the option ont to use the GPL'd stuff.
I personally don't like the GPL. But that doesn't mean it injures me that
it exists. I use GPL'd software sometimes even. I just wouldn't attach
that agreement to my own software. And it keeps me from using GPL'd
software in some things I do. Such is life. I can live with it. It's the
job of the person who makes the software to dictate acceptable use; that's
the irony of the GPL. It wants to talk about freedom, while at the same
time strongly dictating modes of use... Oh well. Again, being somewhat
internally contradictory philosophically doesn't mean its not legally binding
nor that it's immoral.
Kent M Pitman <······@world.std.com> writes:
> I personally don't like the GPL. But that doesn't mean it injures me that
> it exists. I use GPL'd software sometimes even. I just wouldn't attach
> that agreement to my own software. And it keeps me from using GPL'd
> software in some things I do. Such is life. I can live with it. It's the
> job of the person who makes the software to dictate acceptable use; that's
> the irony of the GPL. It wants to talk about freedom, while at the same
> time strongly dictating modes of use... Oh well. Again, being somewhat
> internally contradictory philosophically doesn't mean its not legally binding
> nor that it's immoral.
I don't know that it's really contradictory. It's a really clear
expression of a certain strain of petty-bourgeois
values-about-freedom / interests. It sits in the world view of the
competant ocmputer user who can modify his/her software, and may be an
author from time to time, but who doesn't need to derive his/her
income from that authorship. It's an attempt to maximize the
liberties of that user. Of course there are trade-offs, but there are
trade-offs in everything in life. I think most people's problems with
the GPL come from one of two sources:
1. They are in a different class of computer user than that for
which the GPL was written. These people tend to object to it to
the extent that their perception of their own interests diverge
from that of the intended beneficiary of the GPL. For example,
especially small-time software authors who rely on this for their
income (I think I'm looking in the direction of KMP here) have
quite different interests than what the GPL is trying to protect
(eg, a university student). (This is why I said the GPL is a
clear expression of a *certain* strain of petty-gourgeois
interests -- this would be a different strain here)
2. They are idealists. This cuts both ways, of course. Some users
whose interests are well expressed by the GPL object to it on an
ideological basis. And some users whose interests are
contradicted by the GPL favor it on an ideological basis. I
think it's funny when people accuse the GPL of being ideological.
Certainly it wraps itself in a certain rhetoric, but it's a very
clear expression of a certain class interest. Not good nor bad,
no more no less.
Thomas F. Burdick <···@apocalypse.OCF.Berkeley.EDU> wrote in message
····················@apocalypse.OCF.Berkeley.EDU...
> I
> think it's funny when people accuse the GPL of being ideological.
> Certainly it wraps itself in a certain rhetoric, but it's a very
> clear expression of a certain class interest. Not good nor bad,
> no more no less.
Although I do agree with the class-interest point, I do think that the
GPL embodies a certain ideology that all software should be both monetarily
free and intellectually free, a sort of softhippy idealism. This is of
course doomed to fail for the same reason that musical recordings can't be
free until everything is free(ly given) - both are valuable, and the
specialists who make them need an income.
Marcin Tustin wrote:
> Thomas F. Burdick <···@apocalypse.OCF.Berkeley.EDU> wrote in message
> ····················@apocalypse.OCF.Berkeley.EDU...
>
> > I
> > think it's funny when people accuse the GPL of being ideological.
> > Certainly it wraps itself in a certain rhetoric, but it's a very
> > clear expression of a certain class interest. Not good nor bad,
> > no more no less.
>
> Although I do agree with the class-interest point, I do think that the
> GPL embodies a certain ideology that all software should be both monetarily
> free and intellectually free, a sort of softhippy idealism. This is of
> course doomed to fail for the same reason that musical recordings can't be
> free until everything is free(ly given) - both are valuable, and the
> specialists who make them need an income.
I don't agree here. There is a lot of "incidental" software or at least small-scale in the world. Such software does not necessarily need a company
or an owner backing it. You can look at B-school case studies that basically read "Joe Blow wrote a nice little utility that hundreds of people could
use, on his own time, but his agreement with his company is such that he was legally bound to offer it up to them. But, his company, Megacorp, had no
interest or practical ability to exploit to make an acceptable return on the investement to market and distribute it. What should Joe and Megacorp
Management do next?"
Before GPL, the answer was often "throw the utility in the trash." There was often no acceptable way to even give it away as something Joe did on his
own time thanks to various concerns (e.g. corporate image, potentially enriching competitors, cost of maintenance, etc.).
With the GPL, there is now a legal framework for Joe to do this stuff on his home PC and give it away with his boss' blessings if it is this sort of
thing, especially if the main concern was enriching competitors in some way (including unforeseen).
Anyway, there are such things as cooperatives for apartments and grocery stores. I see GPL and LGPL as a kind of "coop" model for the software
business. Unlike grocery stores, it is likely that not every sort of software will be practical to distribute under GPL. But, it will be practical
to distribute a lot of things under such a model.
Larry -- speaking on his own as usual
Larry Loen <······@rchland.vnet.ibm.com> wrote in message
······················@rchland.vnet.ibm.com...
> Anyway, there are such things as cooperatives for apartments and grocery
stores. I see GPL and LGPL as a kind of "coop" model for the software
> business. Unlike grocery stores, it is likely that not every sort of
software will be practical to distribute under GPL. But, it will be
practical
> to distribute a lot of things under such a model.
Yes.
"Marcin Tustin" <·······@GUeswhatthisbitisfor.mindless.com> writes:
> Thomas F. Burdick <···@apocalypse.OCF.Berkeley.EDU> wrote in message
> ····················@apocalypse.OCF.Berkeley.EDU...
>
> > I
> > think it's funny when people accuse the GPL of being ideological.
> > Certainly it wraps itself in a certain rhetoric, but it's a very
> > clear expression of a certain class interest. Not good nor bad,
> > no more no less.
>
> Although I do agree with the class-interest point, I do think that the
> GPL embodies a certain ideology that all software should be both monetarily
> free and intellectually free, a sort of softhippy idealism. This is of
> course doomed to fail for the same reason that musical recordings can't be
> free until everything is free(ly given) - both are valuable, and the
> specialists who make them need an income.
>
>
The GPL in no way encourages software to be monetarily free. Moral and
intellectual *freedom* -- not zero-cost software -- is the point of
the GPL. If you carefully read the GPL, it *specifically* says you can
sell GPLed software, as long as the software *is not proprietary*.
BTW, I *disagree* with the class-interest point. The GPL is
general-purpose as well as generally-public: everyone from university
students, to small software companies, to Ximian-size companies, to
IBM-style companies, all use the GPL. It is not specfic to a group and
was not actually designed with university students in mind any more
than companies and organizations.
--
BPT <···@hobbiton.org>
backronym for Linux: Linux Is Not Unix
BPT <···@hobbiton.org> writes:
> "Marcin Tustin" <·······@GUeswhatthisbitisfor.mindless.com> writes:
>
> > Thomas F. Burdick <···@apocalypse.OCF.Berkeley.EDU> wrote in message
> > ····················@apocalypse.OCF.Berkeley.EDU...
> >
> > > I
> > > think it's funny when people accuse the GPL of being ideological.
> > > Certainly it wraps itself in a certain rhetoric, but it's a very
> > > clear expression of a certain class interest. Not good nor bad,
> > > no more no less.
> >
> > Although I do agree with the class-interest point, I do think that the
> > GPL embodies a certain ideology that all software should be both monetarily
> > free and intellectually free, a sort of softhippy idealism. This is of
> > course doomed to fail for the same reason that musical recordings can't be
> > free until everything is free(ly given) - both are valuable, and the
> > specialists who make them need an income.
> >
> >
>
> The GPL in no way encourages software to be monetarily free. Moral and
> intellectual *freedom* -- not zero-cost software -- is the point of
> the GPL. If you carefully read the GPL, it *specifically* says you can
> sell GPLed software, as long as the software *is not proprietary*.
That's not freedom. Freedom is placement into the public domain.
The GPL is an enticement to share. It offers cooperation only to those
who agree to a certain behavior. Surely the party is free in the sense
that they can choose not to accept the agreement, but the software is not
itself freely offered nor is the recipient, having accepted, free to choose
how to use it.
Kent M Pitman <······@world.std.com> writes:
> BPT <···@hobbiton.org> writes:
>
> > "Marcin Tustin" <·······@GUeswhatthisbitisfor.mindless.com> writes:
> >
> > > Thomas F. Burdick <···@apocalypse.OCF.Berkeley.EDU> wrote in message
> > > ····················@apocalypse.OCF.Berkeley.EDU...
> > >
> > > > I
> > > > think it's funny when people accuse the GPL of being ideological.
> > > > Certainly it wraps itself in a certain rhetoric, but it's a very
> > > > clear expression of a certain class interest. Not good nor bad,
> > > > no more no less.
> > >
> > > Although I do agree with the class-interest point, I do think that the
> > > GPL embodies a certain ideology that all software should be both monetarily
> > > free and intellectually free, a sort of softhippy idealism. This is of
> > > course doomed to fail for the same reason that musical recordings can't be
> > > free until everything is free(ly given) - both are valuable, and the
> > > specialists who make them need an income.
> > >
> > >
> >
> > The GPL in no way encourages software to be monetarily free. Moral and
> > intellectual *freedom* -- not zero-cost software -- is the point of
^^^^^^^^^^^^
mistake -- ``pragmatic'' might be a more appropriate term here
> > the GPL. If you carefully read the GPL, it *specifically* says you can
> > sell GPLed software, as long as the software *is not proprietary*.
>
> That's not freedom. Freedom is placement into the public domain.
>
I will agree that the GPL does not technically offer complete freedom.
However, it is designed to maximize freedom while making it difficult
to reduce freedom. What you probably meant was ``That's not complete
freedom'', because the GPL attempts to give you as much freedom as
possible without making it possible for someone to take away the
freedom you already have. I think there's a slight mistake in the
previous sentence but I hope that the intended meaning is not
obscured.
> The GPL is an enticement to share.
Sharing and freedom are the two primary goals of the GPL (not
necessarily in that order).
> It offers cooperation only to those
> who agree to a certain behavior.
>
Like all licenses, including the BSD license (I would guess you like
BSD-style licenses). Only public domain is 100% free, but the bad
thing about public-domain software is that someone can make it 100%
non-free if they can hide the source code well enough.
> Surely the party is free in the sense
> that they can choose not to accept the agreement, but the software is not
> itself freely offered nor is the recipient, having accepted, free to choose
> how to use it.
Hmm. More ``quibbling over semantics'' ahead...
I would say that the software is freely offered. However, ``the
software is not itself freely offered'' is rather ambiguous and your
opinion on the validity of the statement depends on how you interpret
it, so I will not argue the point further except to say that from my
interpretation, ``the software is not freely offered'' is about 95%
false IMO.
*Sigh*. More quibbling. There are no restrictions on how the recipient
may *use* the software. For example, you can use GNU software to start
the launch of atomic weapons that are going to blow up
<country-or-continent>, but you may not use MacOS to design nuclear
weapons (I'm serious! read their license!). There are some
restrictions on how you may distribute software -- which may be what
you are complaining about.
--
BPT <···@hobbiton.org>
backronym for Linux: Linux Is Not Unix
BPT <···@hobbiton.org> writes:
> I will agree that the GPL does not technically offer complete freedom.
> However, it is designed to maximize freedom while making it difficult
> to reduce freedom.
I'm sorry, but I think this is quite a non-objective analysis.
You might as well say "you have the freedom to sell things, but not to
make any money on the sale" because the logical consequence of having
to sell something with a tag on it saying "you can get this free next door"
is to drive the price down very close to zero.
I'm not saying that's somehow improper, but please don't confuse this with
maximizing freedom since you are removing an important freedom--the freedom
to add value and to charge a reasonable markup for it. The very manner in
which a GPL'd item is packaged precludes freedom on this point.
It's fine to have the GPL, but please do not say it "maximizes all kinds of
freedom". It merely maximizes certain kinds of freedom that you care about
and it doesn't give a care in the world about other freedoms that other people
might care about.
That is the nature of capitalism. And we capitalists all accept that.
But the GPL is nothing more than one more selfish application of capitalism
wrapped in inappropriate nomenclature that tries to make it sound more giving
than it in fact is.
That's not to say the GPL has nothing to offer in the way of "giving"; only
that it "takes" as well as "gives", and it does not acknowledge the "take"
part fairly or honestly.
In article <···············@world.std.com>, Kent M Pitman wrote:
>BPT <···@hobbiton.org> writes:
>
>> I will agree that the GPL does not technically offer complete freedom.
>> However, it is designed to maximize freedom while making it difficult
>> to reduce freedom.
>
>I'm sorry, but I think this is quite a non-objective analysis.
>
>You might as well say "you have the freedom to sell things, but not to
>make any money on the sale" because the logical consequence of having
>to sell something with a tag on it saying "you can get this free next door"
>is to drive the price down very close to zero.
>
>I'm not saying that's somehow improper, but please don't confuse this with
>maximizing freedom since you are removing an important freedom--the freedom
>to add value and to charge a reasonable markup for it.
By doing this, you are taking away the freedom of others. You are taking
what is shared, and making it proprietary. You forgot to mention that
addition to the ``added value'', and the markup, you have also made the
modified source code inaccessible. Also, you probably have placed some
license on the binary code, which carries greater restrictions than the
free source code you used. So in other words, you have availed yourself
of the freedom to add restrictions, and make less than the complete
work available, thereby reducing freedom. Even the ``value added''
claim can be disputed; the code has value to the community because its
free, so if you put restrictions on it, it is really ``value subtracted''.
The notion of public domain is simply a necessary feature of copyright
law. Copyright doesn't extend forever; once it passes, a work permanently
enters that public domain. But the public domain concept doesn't apply
to source code very well, because source code is open to parasitism
regardless of copyright. Public domain is great for things like music,
literature, visual art. Nobody can hold you hostage with an
embraced-and-extended a Bach fugue.
Really, it should be a rule of trade, independent of any copyright
considerations, that binary code must be distributed with the
corresponding source code, so that no software license agreement can be
valid in which source code did not change hands.
High level programming languages were invented to simplify computer
programming, not to divide users into those who have the source code,
and those who are at the mercy of the former. The ability to do this is
simply an unfortunate sideeffect of the technology.
>The very manner in
>
>It's fine to have the GPL, but please do not say it "maximizes all kinds of
>freedom". It merely maximizes certain kinds of freedom that you care about
>and it doesn't give a care in the world about other freedoms that other people
>might care about.
Freedom isn't absolute; my freedom to swing my fist ends where someone's nose
begins. That's an expression of a value; someone who disagrees with
that value might say that this idea ignores the freedom to break noses,
and therefore isn't true freedom.
>That's not to say the GPL has nothing to offer in the way of "giving"; only
>that it "takes" as well as "gives", and it does not acknowledge the "take"
>part fairly or honestly.
There is nothing fair or honest about keeping users hostage with binary
code. Furthermore, if you do that using free source code, you are but a
common parasite.
···@ashi.footprints.net (Kaz Kylheku) writes:
> In article <···············@world.std.com>, Kent M Pitman wrote:
> >BPT <···@hobbiton.org> writes:
> >
> >> I will agree that the GPL does not technically offer complete freedom.
> >> However, it is designed to maximize freedom while making it difficult
> >> to reduce freedom.
> >
> >I'm sorry, but I think this is quite a non-objective analysis.
> >
> >You might as well say "you have the freedom to sell things, but not to
> >make any money on the sale" because the logical consequence of having
> >to sell something with a tag on it saying "you can get this free next door"
> >is to drive the price down very close to zero.
> >
> >I'm not saying that's somehow improper, but please don't confuse this with
> >maximizing freedom since you are removing an important freedom--the freedom
> >to add value and to charge a reasonable markup for it.
>
> By doing this, you are taking away the freedom of others. You are taking
> what is shared, and making it proprietary. You forgot to mention that
> addition to the ``added value'', and the markup, you have also made the
> modified source code inaccessible.
But the only difference between the accessible part and the inaccessible part
is MY contribution. And therefore, it is only MY right to control what *I*
have contributed that has been constrained. And it's GPL that did the
restraining. It's legally fine for GPL to do this--it can make whatever
restrictions it wants on its creation. It's not morally fine, however, for
it to assert that I am uniquely the one who is restricting liberty, because
I am not. And it is not morally fine for GPL to assert that what it is
promoting is the only valid use of the word freedom, because it takes as well
as giving, making me not clear that it's really "jsut freedom", and because
others that take as well as give are denied their legitimate moral right to
the use of the same term.
In article <···············@world.std.com>, Kent M Pitman wrote:
>···@ashi.footprints.net (Kaz Kylheku) writes:
>> By doing this, you are taking away the freedom of others. You are taking
>> what is shared, and making it proprietary. You forgot to mention that
>> addition to the ``added value'', and the markup, you have also made the
>> modified source code inaccessible.
>
>But the only difference between the accessible part and the inaccessible part
>is MY contribution.
Nonsense. When you compile the whole thing, it is mingled together.
So whatever restrictions you have chosen to place on your part apply
to the whole thing. There may be a clear difference at the source code
level, but the binary is monolithic. If your part is so cleanly separated,
then it should be possible to package it as a separate binary which
(for instance) dynamically links to the free work so that people have
the same freedom over the free part with your contribution, as without.
Anyway, how could you even call something like that a ``contribution''
is beyond me. What characterizes it better is that you have taken the
free program and decided to ``contribute'' that to your own proprietary
project.
>restrictions it wants on its creation. It's not morally fine, however, for
>it to assert that I am uniquely the one who is restricting liberty, because
>I am not.
What, it's not morally fine to express a justifiable opinion now?
> And it is not morally fine for GPL to assert that what it is
>promoting is the only valid use of the word freedom, because it takes as well
Can you cite the portion of the GPL where it asserts that it is promoting
the only valid use of the word? http://www.fsf.org/copyleft/gpl.html
···@ashi.footprints.net (Kaz Kylheku) writes:
> Can you cite the portion of the GPL where it asserts that it is promoting
> the only valid use of the word? http://www.fsf.org/copyleft/gpl.html
I was choosing to refer to GPL as a political party. I didn't mean the
document itself.
I don't choose to respond to the rest of your message. I find this a
fruitless debate. I've made my point. You've either heard me or you
have not.
In article <···············@world.std.com>, Kent M Pitman wrote:
>···@ashi.footprints.net (Kaz Kylheku) writes:
>
>> Can you cite the portion of the GPL where it asserts that it is promoting
>> the only valid use of the word? http://www.fsf.org/copyleft/gpl.html
>
>I was choosing to refer to GPL as a political party. I didn't mean the
>document itself.
But the GPL is not a political party. So you must be referring to
Stallman and the rest of the Free Software Foundation as ``GPL''.
These people simply want everyone to understand what they mean when *they*
use the term ``free software''. They also encourage that definition within
the community of free software users and developers; this is all explained
at http://www.fsf.org/philosophy/free-sw.html . Here, a definition is
given, but it doesn't appear to be prescribing a definition of ``free''
for the rest of the English-speaking world, in contexts such as ``free
variable'', ``free beer'', ``free fall'' or ``free energy''; nor does
it assert that ``free software'' is to be always interpreted according
to the FSF's definition, regardless of who utters it in what context.
Also note that they apply the term to some code that is not under a
GPL-type license, which they call ``non-copylefted free software''. See
http://www.fsf.org/philosophy/categories.html#Non-CopyleftedFreeSoftware
Non-copylefted free software comes from the author with
permission to redistribute and modify, and also to add additional
restrictions to it.
So the specific term for GPL-type software is ``copylefted software''.
Kaz Kylheku <···@ashi.footprints.net> wrote in message
··························@news1.rdc1.bc.home.com...
> In article <···············@world.std.com>, Kent M Pitman wrote:
> >I'm not saying that's somehow improper, but please don't confuse this
with
> >maximizing freedom since you are removing an important freedom--the
freedom
> >to add value and to charge a reasonable markup for it.
>
> By doing this, you are taking away the freedom of others. You are taking
> what is shared, and making it proprietary. You forgot to mention that
> addition to the ``added value'', and the markup, you have also made the
> modified source code inaccessible.
Yes, but I can't even take the unmodified source code and link against
it, or link against open modified code, and then sell the whole application.
> Also, you probably have placed some
> license on the binary code, which carries greater restrictions than the
> free source code you used. So in other words, you have availed yourself
> of the freedom to add restrictions, and make less than the complete
> work available, thereby reducing freedom. Even the ``value added''
> claim can be disputed; the code has value to the community because its
> free, so if you put restrictions on it, it is really ``value subtracted''.
The original code is still available.
> The notion of public domain is simply a necessary feature of copyright
> law. Copyright doesn't extend forever; once it passes, a work permanently
> enters that public domain. But the public domain concept doesn't apply
> to source code very well, because source code is open to parasitism
> regardless of copyright. Public domain is great for things like music,
> literature, visual art. Nobody can hold you hostage with an
> embraced-and-extended a Bach fugue.
>
> Really, it should be a rule of trade, independent of any copyright
> considerations, that binary code must be distributed with the
> corresponding source code, so that no software license agreement can be
> valid in which source code did not change hands.
Why? If this bothers you, prepare to pay for access to the source.
"Marcin Tustin" <·······@GUeswhatthisbitisfor.mindless.com> writes:
> > Really, it should be a rule of trade, independent of any copyright
> > considerations, that binary code must be distributed with the
> > corresponding source code, so that no software license agreement can be
> > valid in which source code did not change hands.
Sigh.
> Why? If this bothers you, prepare to pay for access to the source.
Indeed. I've spent a lot of time in a source-available world with the
Symbolics systems and it's not all roses.
Seeing source means smart people shoot themselves in the foot all the time
by not reading the documentation. They think they can get something cool
from the source but they can't always get "this function will be gone
next week" or "this function is to be used only in conjunction with this
other function and never on its own because to do so exposes a representation
that may be changed without notice" or "we're planning to americanize the
britishised spellings next week, so don't rely on internal functions with 'ize'
or 'ise' in their names" or "we've only debugged the internal functions for
the set of cases the UI can generate and the more general functionality you
think you see is not QA'd" or ...
Source-available systems creates an unnecessary burden on the vendor to
maintain things they never intended to offer. The only reliable way to keep
macho users from shooting themselves in the foot and then suing the company
(rather than themselves) for it is not to allow them the sources.
Exposing the sources may also expose not-yet-released functionality (functions
that never get called and need logically not be included)... even things
in comments that have been commented out or never commented in. Storing those
same functions in another file might create needless source skews. Yet
distributing them with the product might violate trade secret by prematurely
exposing code not related to the binary and allowing competitors a chance to
release the see and exploit this stuff before it was ever intended to be
released by the proper owner.
Exposing sources can also force certain people who use a lot of colorful
language in talking about the bugs they've fixed for their clients to get in
trouble, including possibly losing those clients. Yes, you could argue
they shouldn't be talking about them, but that would mean not keeping good
records. And you could argue they be polite, but that might lose important
information about the intensity of a problem. The truth is that code is the
conceptual equivalent of "things in your brain" and saying "you must transfer
source code with binary" is the same as saying "you must submit to a polygraph
or maybe a surgical operation any time you speak". I don't buy it. It's
Big-Brotherish and bad.
And required "source-available" implies there IS a source. This would
give programs with a source a tactical advantage in the market over people,
which is bad, because programs already put people out of jobs all the time
anyway. It would also create needless haggling over borderline situations
like "what is the source code for a neural net" and "is it enough different
than the binary to be worth transmitting".
And, just as was found with "symbol tables" for programs that are compiled
and debugged, some people just don't need them. I happily run source-free
emacs in some contexts just to save disk space, and don't want the
responsibility of buying sources only to discard. You can say "the vendor
must provide access" but now you are turning the vendor's job from "source
code provider" to "service provider that must have an 800 number or web site
constantly on tap", and that's a very differnt kind of business...
So economic arguments aside, there are some quite practical reasons for
not requiring source with all binary.
From: Sam Steingold
Subject: Re: Engineering Envy [was: Re: CL and UML]
Date:
Message-ID: <uk80yq9v4.fsf@xchange.com>
> * In message <···············@world.std.com>
> * On the subject of "Re: Engineering Envy [was: Re: CL and UML]"
> * Sent on Tue, 24 Jul 2001 14:25:51 GMT
> * Honorable Kent M Pitman <······@world.std.com> writes:
>
> Seeing source means smart people shoot themselves in the foot all the
> time by not reading the documentation.
_smart_ people _do_ RTFM.
This might mean, unfortunately, that there are _no_ smart people in the
world, but this is a different issue... :-)
Oh, wait! You said "all the time"!
There is a Russian proverb: "The smart ones learn from the mistakes of
the others, the stupid ones cannot learn even from their own mistakes".
People who "shoot themselves in the foot all the time" by making the
same mistake deserve what they get, right?
--
Sam Steingold (http://www.podval.org/~sds)
Every day above ground is a good day.
Sam Steingold <···@gnu.org> writes:
> > * In message <···············@world.std.com>
> > * On the subject of "Re: Engineering Envy [was: Re: CL and UML]"
> > * Sent on Tue, 24 Jul 2001 14:25:51 GMT
> > * Honorable Kent M Pitman <······@world.std.com> writes:
> >
> > Seeing source means smart people shoot themselves in the foot all the
> > time by not reading the documentation.
>
> _smart_ people _do_ RTFM.
But really smart people don't let otehrs shoot themselves in the foot
in spite of this in a society that is becoming ever-more-letigious.
Remember this thread began with the assertion that CS needed to be more
like other engineering and people needed to be able to sue each other a
lot when software did wrong things. I argued that "warranty" should be
explicit, i.e., software does what it is warrantied to do. Others have
argued that software should have an implied warranty just by virtue of
its existence. My contention is that that model is NOT compatible with
open source and any notion of sharing, since everything you share is a
spontaneous invitation to lawsuit.
On Tue, 24 Jul 2001, Kent M Pitman wrote:
>
> Indeed. I've spent a lot of time in a source-available world with the
> Symbolics systems and it's not all roses.
>
> Seeing source means smart people shoot themselves in the foot all the time
> by not reading the documentation. They think they can get something cool
> from the source but they can't always get "this function will be gone
> next week" or "this function is to be used only in conjunction with this
> other function and never on its own because to do so exposes a representation
> that may be changed without notice" or "we're planning to americanize the
> britishised spellings next week, so don't rely on internal functions with 'ize'
> or 'ise' in their names" or "we've only debugged the internal functions for
> the set of cases the UI can generate and the more general functionality you
> think you see is not QA'd" or ...
This all sounds like a big communication problem, which is typical of
closed source source access, wherein customers get source access but
aren't allowed to share it (could Symbolics licensees share source changes
with others?) Everyone who has source access, including the original
vendor, are viewed as potential competitors, so changes and the hint of
changes are kept secret. Otherwise, when contemplating using some
undocumented internal function of package FOO, why wouldn't the users
simply ask the company what the plans were for it?
> Source-available systems creates an unnecessary burden on the vendor to
> maintain things they never intended to offer. The only reliable way to keep
> macho users from shooting themselves in the foot and then suing the company
> (rather than themselves) for it is not to allow them the sources.
Can you tell us, or even drop a hint, of one instance where this happened
to Symbolics? Not "shooting themselves in the foot," I can believe that,
but threatening to sue over an internal interface change?
>
> Exposing the sources may also expose not-yet-released functionality (functions
> that never get called and need logically not be included)... even things
> in comments that have been commented out or never commented in. Storing those
> same functions in another file might create needless source skews. Yet
In the absence of a version control system, this might be a problem.
> distributing them with the product might violate trade secret by prematurely
> exposing code not related to the binary and allowing competitors a chance to
> release the see and exploit this stuff before it was ever intended to be
> released by the proper owner.
Yup yup, keeping trade secrets, yours or others', in publicly available
source is a problem. No doubt about it. Yessiree.
> And required "source-available" implies there IS a source. This would
> give programs with a source a tactical advantage in the market over people,
> which is bad, because programs already put people out of jobs all the time
> anyway. It would also create needless haggling over borderline situations
Uhhh... what? Are you saying it's a good thing that programmers who have
access to the closed source (i.e., the original vendor) can artificially
inflate their value at the expense of the customer?
Tim
Tim Moore <·····@herschel.bricoworks.com> writes:
> On Tue, 24 Jul 2001, Kent M Pitman wrote:
> >
> > Indeed. I've spent a lot of time in a source-available world with the
> > Symbolics systems and it's not all roses.
> >
> > Seeing source means smart people shoot themselves in the foot all
> > the time by not reading the documentation. They think they can
> > get something cool from the source but they can't always get "this
> > function will be gone next week" or "this function is to be used
> > only in conjunction with this other function and never on its own
> > because to do so exposes a representation that may be changed
> > without notice" or "we're planning to americanize the britishised
> > spellings next week, so don't rely on internal functions with
> > 'ize' or 'ise' in their names" or "we've only debugged the
> > internal functions for the set of cases the UI can generate and
> > the more general functionality you think you see is not QA'd" or
> > ...
>
> This all sounds like a big communication problem, which is typical of
> closed source source access, wherein customers get source access but
> aren't allowed to share it (could Symbolics licensees share source changes
> with others?) Everyone who has source access, including the original
> vendor, are viewed as potential competitors, so changes and the hint of
> changes are kept secret. Otherwise, when contemplating using some
> undocumented internal function of package FOO, why wouldn't the users
> simply ask the company what the plans were for it?
Because programmers are lazy and vendors are slow to respond, ESPECIALLY
about undocumented features. It's hard eough keeping the doc group apprised
of documented features. This is why charging for sources makes good sense--
not just because the sources are extra value, but also because the having
them makes it much more likely the customer is going to cause you additional
support headaches, either up front in demanding guidance or after-the-fact
if he blunders ahead.
> > Source-available systems creates an unnecessary burden on the
> > vendor to maintain things they never intended to offer. The only
> > reliable way to keep macho users from shooting themselves in the
> > foot and then suing the company (rather than themselves) for it is
> > not to allow them the sources.
>
> Can you tell us, or even drop a hint, of one instance where this
> happened to Symbolics? Not "shooting themselves in the foot," I can
> believe that, but threatening to sue over an internal interface
> change?
Lawsuit? No, not offhand. I'm mostly there responding to upthread remarks
where people are advocating holding programmers to a higher standards where
such lawsuits would be more common, and observing that these various threads
of social engineering are headed for a bad collision.
But irate customers who had used an internal interface and then complained
when it went away? I think that was routine, though I can't cite a specific
instance at this late date. I'm pretty sure it's the reason I evoled the
notion in my mind of "source-on-demand" which I wanted the Macsyma group
(which I worked for) to do, where our open source policy would be replaced
with the idea of revealing tracked pieces of source to certain people in
exchange for their telling us what they were using it for and letting us
track the fact that they had a dependency we might need to ask about.
Even that wasn't a perfect solution, but struck me as better than the
situation we had.
When translating Macsyma from Maclisp/FranzLisp/Zetalisp to Common Lisp,
I had a MAJOR problem in that I knew people had relied upon all manner of
internals (since Macsyma had always been open-source) and there was virtually
nothing I could change that wasn't sure to break something in user source
code (since I wasn't upgrading tha code, nor was there any record of who
had such code nor of what dependencies they had). Figuring out what could
safely be reimplemented and what should be left alone was very complicated.
> > Exposing the sources may also expose not-yet-released
> > functionality (functions that never get called and need logically
> > not be included)... even things in comments that have been
> > commented out or never commented in. Storing those same functions
> > in another file might create needless source skews. Yet
>
> In the absence of a version control system, this might be a problem.
It's more compoicated than that. Even with most source control systems
I can think of, this problem would still happen.
> > distributing them with the product might violate trade secret by
> > prematurely exposing code not related to the binary and allowing
> > competitors a chance to release the see and exploit this stuff
> > before it was ever intended to be released by the proper owner.
>
> Yup yup, keeping trade secrets, yours or others', in publicly available
> source is a problem. No doubt about it. Yessiree.
>
> > And required "source-available" implies there IS a source. This
> > would give programs with a source a tactical advantage in the
> > market over people, which is bad, because programs already put
> > people out of jobs all the time anyway. It would also create
> > needless haggling over borderline situations
>
> Uhhh... what? Are you saying it's a good thing that programmers who
> have access to the closed source (i.e., the original vendor) can
> artificially inflate their value at the expense of the customer?
I don't understand the meaning of artificial in this context. They
can't raise the price higher than what the market will bear, which
presumably has an upper bound at the point where someone else could
afford to implement it. The term "artificially inflate" suggests some
undue control of the market, which I don't think a true free market
ever really allows.
In fact, I think to some extent requiring source release would
artificially increase the cost because the inability to hold any value
close to one's vest would require requesting higher prices up front
before the value of "time to market" (one of the few remaining values)
was lost.
On Tue, 24 Jul 2001, Kent M Pitman wrote:
> Tim Moore <·····@herschel.bricoworks.com> writes:
>
> > On Tue, 24 Jul 2001, Kent M Pitman wrote:
> > > [power users shoot themselves in the foot with the source to
internals]
> > This all sounds like a big communication problem, which is typical of
> > closed source source access, wherein customers get source access but
> > aren't allowed to share it (could Symbolics licensees share source changes
> > with others?) Everyone who has source access, including the original
> > vendor, are viewed as potential competitors, so changes and the hint of
> > changes are kept secret. Otherwise, when contemplating using some
> > undocumented internal function of package FOO, why wouldn't the users
> > simply ask the company what the plans were for it?
>
> Because programmers are lazy and vendors are slow to respond, ESPECIALLY
> about undocumented features. It's hard eough keeping the doc group apprised
> of documented features. This is why charging for sources makes good sense--
> not just because the sources are extra value, but also because the having
> them makes it much more likely the customer is going to cause you additional
> support headaches, either up front in demanding guidance or after-the-fact
> if he blunders ahead.
My point is that in Symbolics' model there was little motivation, in fact
quite the opposite, for customers to communicate openly with Symbolics
about their interest in and use of the internal interfaces. Those
interfaces were therefore almost guaranteed to stay brittle and unstable,
except perhaps for random improvements when Symbolics' own developers
found them useful enough to improve.
>
> But irate customers who had used an internal interface and then complained
> when it went away? I think that was routine, though I can't cite a specific
Well duh, of course people will bitch given a chance :) But what did they
expect? How could they reasonably complain?
> instance at this late date. I'm pretty sure it's the reason I evoled the
> notion in my mind of "source-on-demand" which I wanted the Macsyma group
> (which I worked for) to do, where our open source policy would be replaced
> with the idea of revealing tracked pieces of source to certain people in
> exchange for their telling us what they were using it for and letting us
> track the fact that they had a dependency we might need to ask about.
> Even that wasn't a perfect solution, but struck me as better than the
> situation we had.
>
This gets to the heart of the problem with the "shared source" model.
Your customers probably viewed other Symbolics customers with source, and
possibly Symbolics too, as competitors who would get an unfair leg up if
bug fixes, feature enhancements, requests, etc. were transmitted back to
Symbolics and then out to everybody. Actually, The original vendor would
be viewed with extreme distrust because they have license to sell the
code with contributed enhancements. Therefore, everything is kept secret
and everyone is unhappy when things break.
This pattern doesn't happen in true open source ecologies in which the
source code is ubiquitous, not some grudgingly released secret. Either
changes and enhancements are for better or worse compelled to be
contributed back, in the GPL model, or in more laid back environments
they're contributed back anyway because the maintenance burden is lowered
and debugging effort is spread around.
> When translating Macsyma from Maclisp/FranzLisp/Zetalisp to Common Lisp,
> I had a MAJOR problem in that I knew people had relied upon all manner of
> internals (since Macsyma had always been open-source) and there was virtually
> nothing I could change that wasn't sure to break something in user source
> code (since I wasn't upgrading tha code, nor was there any record of who
> had such code nor of what dependencies they had). Figuring out what could
> safely be reimplemented and what should be left alone was very complicated.
That sounds like an inevitable condition in a long-lived, rapidly
evolving program in which the internal/external differences are fuzzy.
> > > And required "source-available" implies there IS a source. This
> > > would give programs with a source a tactical advantage in the
> > > market over people, which is bad, because programs already put
> > > people out of jobs all the time anyway. It would also create
> > > needless haggling over borderline situations
> >
> > Uhhh... what? Are you saying it's a good thing that programmers who
> > have access to the closed source (i.e., the original vendor) can
> > artificially inflate their value at the expense of the customer?
>
> I don't understand the meaning of artificial in this context. They
> can't raise the price higher than what the market will bear, which
> presumably has an upper bound at the point where someone else could
> afford to implement it. The term "artificially inflate" suggests some
> undue control of the market, which I don't think a true free market
> ever really allows.
"Artificial" from the point of view of the customer who has to pay more
for support of a closed source program than an open one. I won't argue
strongly that the price differential is in fact artifical; it's more a
matter of perception. However, I will assert that the value of the
original author does not drop to anything close to zero when source is
open.
Also, I don't understand your comment that programs with open source have
a tactical advantage over "people." By "people" do you mean the authors
of closed source programs?
In summary, I'm not trying to argue that all programs should be open
source (and I doubt I could persuade you of that :). Rather, I'm saying
that the "closed open source" model that seems to have been offered by
Symbolics is bad, perhaps worse than closed source, for a bunch of
reasons that don't hold for open source in general.
Tim
Tim Moore <·····@herschel.bricoworks.com> writes:
> On Tue, 24 Jul 2001, Kent M Pitman wrote:
>> instance at this late date. I'm pretty sure it's the reason I
>> evoled the notion in my mind of "source-on-demand" which I wanted
>> the Macsyma group (which I worked for) to do, where our open source
>> policy would be replaced with the idea of revealing tracked pieces
>> of source to certain people in exchange for their telling us what
>> they were using it for and letting us track the fact that they had
>> a dependency we might need to ask about. Even that wasn't a
>> perfect solution, but struck me as better than the situation we
>> had.
> This gets to the heart of the problem with the "shared source"
> model. Your customers probably viewed other Symbolics customers
> with source, and possibly Symbolics too, as competitors who would
> get an unfair leg up if bug fixes, feature enhancements, requests,
> etc. were transmitted back to Symbolics and then out to everybody.
> Actually, The original vendor would be viewed with extreme distrust
> because they have license to sell the code with contributed
> enhancements. Therefore, everything is kept secret and everyone is
> unhappy when things break.
I've sat inside the "ecology" of SAP R/3 implementations which have
_exactly_ the same sort of "shared source" model.
The R/3 application consists of a "kernel," written in C/C++, which
provides an engine for code written in a bytecoded language called
ABAP/4.
Developers have access to the source code to all parts of the system
aside from the kernel itself.
It _doesn't_ seem lead to this situation of "extreme distrust;" in a
whole lot of cases, I've seen code head back to SAP AG for the express
purpose of having it enter the "central ecology" so that there is not
a need for customers to continue to maintain their own "separate
ecology."
Having a code "fork" is pretty expensive; if you have your own custom
version of one of SAP's programs, you've got to track the similarities
and differences against _any_ change that comes in from the vendor.
If you're [for instance] running Payroll, it is _unbelievably
mandatory_ to pull in changes, because there are so many changes
driven by changes in government regulations, and it's far cheaper to
let the maintenance head over to SAP, if at all possible.
Now, it's fair to say that there are some big differences between this
and Symbolics; with Symbolics, all you get is the "framework," on
which a whole lot of stuff gets built, whereas with R/3, there's
"framework+application," and the amount of customer-specific code
deployed is much smaller. That doesn't diminish that there are a lot
of parallels...
> This pattern doesn't happen in true open source ecologies in which
> the source code is ubiquitous, not some grudgingly released secret.
> Either changes and enhancements are for better or worse compelled to
> be contributed back, in the GPL model, or in more laid back
> environments they're contributed back anyway because the maintenance
> burden is lowered and debugging effort is spread around.
There lies the question:
How much of the effort is maintenance and debugging, versus developing
brand new stuff?
If the burden is in "new stuff," GPL isn't _all_ that valuable, but if
the burden is in "maintenance and testing," the sharing of effort _is_
valuable.
> "Artificial" from the point of view of the customer who has to pay
> more for support of a closed source program than an open one. I
> won't argue strongly that the price differential is in fact
> artifical; it's more a matter of perception. However, I will assert
> that the value of the original author does not drop to anything
> close to zero when source is open.
The value of the original author doesn't have to drop; the author
still has intimate knowledge of:
a) What design decisions were made, and
b) What the system is intended to do.
Those are quite valuable even if many other people have access to
source code.
> In summary, I'm not trying to argue that all programs should be open
> source (and I doubt I could persuade you of that :). Rather, I'm
> saying that the "closed open source" model that seems to have been
> offered by Symbolics is bad, perhaps worse than closed source, for a
> bunch of reasons that don't hold for open source in general.
I'm not sure it's necessarily the "source access model" that's bad;
the challenge is that Symbolics had a complex product that evolved
over time.
That evolution, combined with source access, resulted in the exposure
of "brittle bits" of the system to users.
It seems to me that it's not an argument against access to source, but
rather an argument against people using parts of systems that are in
extreme flux.
For quite a long time, wise C++ developers avoided using templates
because the quality of implementations of that feature had, um,
"considerable variation." That's not an "open source" issue, but
rather an issue that part of the language was quite brittle.
--
(concatenate 'string "cbbrowne" ·@ntlug.org")
http://vip.hex.net/~cbbrowne/internet.html
Rules of the Evil Overlord #127. "Prison guards will have their own
cantina featuring a wide variety of tasty treats that will deliver
snacks to the guards while on duty. The guards will also be informed
that accepting food or drink from any other source will result in
execution." <http://www.eviloverlord.com/>
Tim Moore <·····@herschel.bricoworks.com> writes:
> Well duh, of course people will bitch given a chance :) But what did they
> expect? How could they reasonably complain?
Because they were all on support. It entitled them to complain. They
claimed it was not onl a problem that the item had broken, but an
error that it hadn't been previously released.
> > instance at this late date. I'm pretty sure it's the reason I evoled the
> > notion in my mind of "source-on-demand" which I wanted the Macsyma group
> > (which I worked for) to do, where our open source policy would be replaced
> > with the idea of revealing tracked pieces of source to certain people in
> > exchange for their telling us what they were using it for and letting us
> > track the fact that they had a dependency we might need to ask about.
> > Even that wasn't a perfect solution, but struck me as better than the
> > situation we had.
> >
> This gets to the heart of the problem with the "shared source" model.
> Your customers probably viewed other Symbolics customers with source, and
> possibly Symbolics too, as competitors who would get an unfair leg up if
> bug fixes, feature enhancements, requests, etc. were transmitted back to
> Symbolics and then out to everybody. Actually, The original vendor would
> be viewed with extreme distrust because they have license to sell the
> code with contributed enhancements. Therefore, everything is kept secret
> and everyone is unhappy when things break.
This is really all nonsense and distorts the truth substantially. I
said they complained, and they did. I did not say they were unhappy
with the system or the distribution mechanism. The number of serious
users of Lisp Machines who were unhappy with the experience was tiny.
To this day, nearly all who experienced it look back on the experience
with longing.
> This pattern doesn't happen in true open source ecologies in which the
> source code is ubiquitous, not some grudgingly released secret.
I think you're extrapolating beyond all usefulness of the data.
Moreover, I think if it doesn't happen in the present systems it's not
because people are dreamy and ideological about the GPL, it's because
no company has been screwed enough by a failure to want to stick it to
someone who is distributing open source. If the option exists, and I
daresay it does, it will eventually get used.
I'm going to cut my losses on this branch of the conversation and just
stop here. I don't feel the comparisons made are fair and the
conversational energy required to mend them is more than I have
available to offer.
I merely raised some "issues" that stand as "points of concern" under
a certain paradigm. They can happen. They are things I would take into
account. If you are comfortable not taking them into account, that's what
makes a diverse world. However, it does not prove they were not worth
taking into account; and even your getting away with not taking them into
account doesn't prove that someone else's concern over them was wasted.
I return to my point about "wisdom" vs "dogma". Wisdom is about
making decisions on the basis of a knowledge of the things that can
happen and then choosing what's appropriate to you. Dogma is about
being taught that you don't have to worry about certain things because
someone else has pre-computed a solution for you. I'm not suggesting
a precomputed solution but I'm smelling others telling me there are
precomputed solutions to be had. I don't buy it. I hope people who
are standing on the outside just watching this conversation go by will
have the good sense to keep asking questions and not to assume the
answers are ever easy in this realm. What is right or wrong is
determined on a case-by-case basis--there is no "grand world view" in
which people treat each other kindly if only they adopt The Good Way.
People are largely predisposed to treat each other badly or goodly in
whatever paradigm; the paradigm only chooses what tools they will have
available. I like the capitalistic money-grubbing software is owned
by somebody model because it leads to my having money and that enables
me to battle not only "the forces of good and evil software" but
sometimes also other forces of good and evil that have nothing to do
with software. Your mileage may, and almost surely does, vary.
On Tue, 24 Jul 2001, Kent M Pitman wrote:
> Tim Moore <·····@herschel.bricoworks.com> writes:
>
> > This gets to the heart of the problem with the "shared source" model.
> > Your customers probably viewed other Symbolics customers with source, and
> > possibly Symbolics too, as competitors who would get an unfair leg up if
> > bug fixes, feature enhancements, requests, etc. were transmitted back to
> > Symbolics and then out to everybody. Actually, The original vendor would
> > be viewed with extreme distrust because they have license to sell the
> > code with contributed enhancements. Therefore, everything is kept secret
> > and everyone is unhappy when things break.
>
> This is really all nonsense and distorts the truth substantially. I
> said they complained, and they did. I did not say they were unhappy
> with the system or the distribution mechanism. The number of serious
> users of Lisp Machines who were unhappy with the experience was tiny.
> To this day, nearly all who experienced it look back on the experience
> with longing.
They were apparently unhappy with their code breaking when interfaces
changed. I have not said anything about the Lisp Machine experience being
unhappy; I'm only trying to explore why the code sharing experience was
unhappy for them and you.
> > This pattern doesn't happen in true open source ecologies in which the
> > source code is ubiquitous, not some grudgingly released secret.
>
> I think you're extrapolating beyond all usefulness of the data.
>
> Moreover, I think if it doesn't happen in the present systems it's not
> because people are dreamy and ideological about the GPL, it's because
> no company has been screwed enough by a failure to want to stick it to
> someone who is distributing open source. If the option exists, and I
> daresay it does, it will eventually get used.
Be sure to get back to us when it does.
Tim
Tim Moore <·····@herschel.bricoworks.com> wrote in message news:<············@216.39.145.192>...
> > Source-available systems creates an unnecessary burden on the vendor to
> > maintain things they never intended to offer. The only reliable way to keep
> > macho users from shooting themselves in the foot and then suing the company
> > (rather than themselves) for it is not to allow them the sources.
>
> Can you tell us, or even drop a hint, of one instance where this happened
> to Symbolics? Not "shooting themselves in the foot," I can believe that,
> but threatening to sue over an internal interface change?
I didn't see a lawsuit threat, and I wasn't at Symbolics, but I saw
customers demand that they be protected from the consequence of their
reliance on internal/undocumented/not-for-customer-use code.
When that code disappeared/changed in a new release, they couldn't upgrade.
Since the upgrade had things that they needed, they insisted that the
those things be backported. What a deal - a customer-forced code fork.
I suspect that the actual threat was "if you don't do this, we'll find
another vendor". That's a somewhat strange threat, as the other vendor
didn't have that internal/undocumented/not-for-customer-use code. In
other words, either way the customer was going to end up rewriting the
offending code.
-andy
From: Friedrich Dominicus
Subject: Re: Engineering Envy [was: Re: CL and UML]
Date:
Message-ID: <87wv4yi8mc.fsf@frown.here>
Kent M Pitman <······@world.std.com> writes:
> "Marcin Tustin" <·······@GUeswhatthisbitisfor.mindless.com> writes:
>
> > > Really, it should be a rule of trade, independent of any copyright
> > > considerations, that binary code must be distributed with the
> > > corresponding source code, so that no software license agreement can be
> > > valid in which source code did not change hands.
>
> Sigh.
>
> > Why? If this bothers you, prepare to pay for access to the source.
>
> Indeed. I've spent a lot of time in a source-available world with the
> Symbolics systems and it's not all roses.
I disagree I would say it's all roses. Just remember the thorns ;-) I
would not tell me extraordinary smart, but I have a pleasant feeling
if I have the sources. Not that I want to dig through it to find
hidden perls. Just the feeling in an case of "emergency" to fall back
to the sources gives me a safety belt.
I would say too that freedom is a good thing, it can be misused as
anything else.
And having the sources means having access to so much knowledge and
helps IMHO tremendous to learn how things work. So I take the rose
with those thorns ;-)
>
> Source-available systems creates an unnecessary burden on the vendor to
> maintain things they never intended to offer. The only reliable way to keep
> macho users from shooting themselves in the foot and then suing the company
> (rather than themselves) for it is not to allow them the sources.
Now I do not think that any company offering the sources says. If you
do changes yourself you can not sue us for anything.
>
> Exposing sources can also force certain people who use a lot of colorful
> language in talking about the bugs they've fixed for their clients to get in
> trouble, including possibly losing those clients. Yes, you could argue
> they shouldn't be talking about them, but that would mean not keeping good
> records.
That is IMHO too not an argument. Because some people do or misuse
something does not mean that "all" the people do that. How many people
do you think write some code for the Linux Kernel? Now if there are a
millions of users you hardly will find more than some handful really
working with the code and there are probably even less "misuing"
whatever.
> So economic arguments aside, there are some quite practical reasons for
> not requiring source with all binary.
Of course there are, but you don't have to follow the trend to give
you source away. If you decide not to do that's fine, if someone
argues against that I would say, he/she better shout up. It's you
personal decision, now if you do not think it's good to distribute
source, stay away from all Licenses that require that. Do not use
their softwar and that's fine. If people want your sources, you are
free to sell them. So I don't think "practical" reasons (whatever that
are) come into play here. You can call it "political" reasons if you
like or "matter of taste" or whatever.
Regards
Friedrich
Friedrich Dominicus <·····@q-software-solutions.com> writes:
> I have a pleasant feeling
> if I have the sources.
Of course YOU do. But it's code *I* wrote. And I can smell a lawsuit
against me on that flower you're handling if you get the thorns with it.
Remember a separate thread in which people are proposing that the mere act
of writing code should imply a warranty, regardless of disclaimers.
> And having the sources means having access to so much knowledge and
> helps IMHO tremendous to learn how things work.
In other words, I am helping you to put me out of business.
Another negative I forgot to list.
> > Exposing sources can also force certain people who use a lot of colorful
> > language in talking about the bugs they've fixed for their clients to get in
> > trouble, including possibly losing those clients. Yes, you could argue
> > they shouldn't be talking about them, but that would mean not keeping good
> > records.
> That is IMHO too not an argument. Because some people do or misuse
> something does not mean that "all" the people do that.
You misunderstand the directionality of the arrows in a graph of
liability that my lawyers will draw. One does not insure one's house
because everyone will break into it, one insures one's house because
SOME people might break in, and because even one such is enough.
> > So economic arguments aside, there are some quite practical reasons for
> > not requiring source with all binary.
> Of course there are, but you don't have to follow the trend to give
> you source away.
The discussion was in the context of requiring the giving away of source
in order to sell binary, so yes I do.
On Tue, 24 Jul 2001, Kent M Pitman wrote:
> Friedrich Dominicus <·····@q-software-solutions.com> writes:
>
> > And having the sources means having access to so much knowledge and
> > helps IMHO tremendous to learn how things work.
>
> In other words, I am helping you to put me out of business.
> Another negative I forgot to list.
Aren't you helping to put yourself out of business every time you write a
helpful article or answer a question correctly on comp.lang.lisp?
Might there be some benefit to you in there existing a body of programmers
(who may someday be managers) whose knowledge comes in part from you and
may be aligned with your interests?
Tim
In article <···············@world.std.com>, Kent M Pitman wrote:
>Friedrich Dominicus <·····@q-software-solutions.com> writes:
>
>> I have a pleasant feeling
>> if I have the sources.
>
>Of course YOU do. But it's code *I* wrote. And I can smell a lawsuit
>against me on that flower you're handling if you get the thorns with it.
>
>Remember a separate thread in which people are proposing that the mere act
>of writing code should imply a warranty, regardless of disclaimers.
If your code is so bad that a lawsuit will follow from it, maybe
it shouldn't be released in binary *or* source form.
What are you saying? That compiling is a tool for hiding engineering
bugs, to fend off lawsuits?
I think I'm going to save this thread, because it contains a lot of
entertaining FUD against open source code; especially the prior
article by Kent.
From: Friedrich Dominicus
Subject: Re: Engineering Envy [was: Re: CL and UML]
Date:
Message-ID: <87r8v5wo30.fsf@frown.here>
Kent M Pitman <······@world.std.com> writes:
> Remember a separate thread in which people are proposing that the mere act
> of writing code should imply a warranty, regardless of disclaimers.
Now I do not have seen any lawsuit till now which suggest such an
interpretation.
>
> > And having the sources means having access to so much knowledge and
> > helps IMHO tremendous to learn how things work.
>
> In other words, I am helping you to put me out of business.
> Another negative I forgot to list.
That is a very limiting view of what learning means. Now than I can
ask why do people have learn to read. They will probably drive others
out of the business which could stay otherwise. Scientific progress is
impossible with that attitude. Most of the time you rely on thing
others have developed before.
>
> You misunderstand the directionality of the arrows in a graph of
> liability that my lawyers will draw. One does not insure one's house
> because everyone will break into it, one insures one's house because
> SOME people might break in, and because even one such is enough.
As mentioned before I do not have seen any case which has turned out
the way you describe it. Your lawyer can draw whatever he/she likes,
before it wasn't handeled in court it fiction.
>
> The discussion was in the context of requiring the giving away of source
> in order to sell binary, so yes I do.
No-one can force you to give away what you do not want to give
away. And if the ask you for that, you simply answer. No, you do not
get it or Yes you can get it for $ xxx....
Regards
Friedrich
In article <··············@frown.here>, Friedrich Dominicus wrote:
>Kent M Pitman <······@world.std.com> writes:
>> The discussion was in the context of requiring the giving away of source
>> in order to sell binary, so yes I do.
Note that although I introduced this idea, it was not worded in terms of
``giving away'' anything. That is merely Kent's comprehension of what I
wrote. The idea I set forth is that the source is disclosed as part
of the transaction, I was not specific about the terms. (Ideally,
I would like to also see a provision that licensed users of the program
can share source patches with each other, without having to require
special permission from the vendor).
>No-one can force you to give away what you do not want to give
>away.
Is that so?
I want to manufacture cars, but I don't want to provide seat belts!
I want to sell a new prescription drug, but I don't want to
tell anyone what's in it!
I want to build a downtown highrise, but nobody outside of my
organization can see the plans!
From: Friedrich Dominicus
Subject: Re: Engineering Envy [was: Re: CL and UML]
Date:
Message-ID: <871yn4jl6f.fsf@frown.here>
···@ashi.footprints.net (Kaz Kylheku) writes:
>
> Is that so?
>
> I want to manufacture cars, but I don't want to provide seat belts!
>
> I want to sell a new prescription drug, but I don't want to
> tell anyone what's in it!
>
> I want to build a downtown highrise, but nobody outside of my
> organization can see the plans!
I deserve that for writing such unspecific stuff. Nobody can force you
to give away your sources. Is that better?
Friedrich
Friedrich Dominicus <·····@q-software-solutions.com> writes:
> ···@ashi.footprints.net (Kaz Kylheku) writes:
>
> I deserve that for writing such unspecific stuff.
No you don't. Everyone understood the implicit context except one who
pretended not to. Please don't help to turn this newsgroup into
comp.lang.c++.
Friedrich Dominicus <·····@q-software-solutions.com> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > Exposing sources can also force certain people who use a lot of colorful
> > language in talking about the bugs they've fixed for their clients to get in
> > trouble, including possibly losing those clients. Yes, you could argue
> > they shouldn't be talking about them, but that would mean not keeping good
> > records.
> That is IMHO too not an argument. Because some people do or misuse
> something does not mean that "all" the people do that. How many people
> do you think write some code for the Linux Kernel?
About once a year some concerned fellow finds the swear words in the
Linux kernel source and proposes to remove them because it isn't
professional/to protect the children/...
--
Lieven Marchand <···@wyrd.be>
You can drag any rat out of the sewer and teach it to get some work done in
Perl, but you cannot teach it serious programming. Erik Naggum
Lieven Marchand <···@wyrd.be> writes:
> Friedrich Dominicus <·····@q-software-solutions.com> writes:
>
> > Kent M Pitman <······@world.std.com> writes:
> >
> > > Exposing sources can also force certain people who use a lot of colorful
> > > language in talking about the bugs they've fixed for their clients to get in
> > > trouble, including possibly losing those clients. Yes, you could argue
> > > they shouldn't be talking about them, but that would mean not keeping good
> > > records.
> > That is IMHO too not an argument. Because some people do or misuse
> > something does not mean that "all" the people do that. How many people
> > do you think write some code for the Linux Kernel?
>
> About once a year some concerned fellow finds the swear words in the
> Linux kernel source and proposes to remove them because it isn't
> professional/to protect the children/...
At LMI we once had someone spend the time to remove those phrases that
contained correctly spelled swear words.
Nonetheless, we apparently left in some words that have an impolite
meaning to francophones.
>
> --
> Lieven Marchand <···@wyrd.be>
> You can drag any rat out of the sewer and teach it to get some work done in
> Perl, but you cannot teach it serious programming. Erik Naggum
In article <············@news6.svr.pol.co.uk>, Marcin Tustin wrote:
>
>Kaz Kylheku <···@ashi.footprints.net> wrote in message
>··························@news1.rdc1.bc.home.com...
>> In article <···············@world.std.com>, Kent M Pitman wrote:
>> >I'm not saying that's somehow improper, but please don't confuse this
>with
>> >maximizing freedom since you are removing an important freedom--the
>freedom
>> >to add value and to charge a reasonable markup for it.
>>
>> By doing this, you are taking away the freedom of others. You are taking
>> what is shared, and making it proprietary. You forgot to mention that
>> addition to the ``added value'', and the markup, you have also made the
>> modified source code inaccessible.
>
> Yes, but I can't even take the unmodified source code and link against
>it, or link against open modified code, and then sell the whole application.
That depends on what kind of free software we are talking about here.
I was speaking in the context of free software which does allow this
kind of use.
>> Also, you probably have placed some
>> license on the binary code, which carries greater restrictions than the
>> free source code you used. So in other words, you have availed yourself
>> of the freedom to add restrictions, and make less than the complete
>> work available, thereby reducing freedom. Even the ``value added''
>> claim can be disputed; the code has value to the community because its
>> free, so if you put restrictions on it, it is really ``value subtracted''.
>
> The original code is still available.
That is perfectly true, and pertinent.
However in this imperfect world, there exist reluctant users of
proprietary software; users who are forced to use proprietary programs
for various reasons having nothing to do with their freedom of choice.
Moreover, proprietary programs can be connected together with proprietary
protocols and data formats to create entire proprietary platforms.
So people end up coerced into using entire platforms, from the
applications on down.
Some developers of free software do not want to see their free software
being incorporated into someone's plan to reduce choice.
···@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > I personally don't like the GPL. But that doesn't mean it injures me that
> > it exists. I use GPL'd software sometimes even. I just wouldn't attach
> > that agreement to my own software. And it keeps me from using GPL'd
> > software in some things I do. Such is life. I can live with it. It's the
> > job of the person who makes the software to dictate acceptable use; that's
> > the irony of the GPL. It wants to talk about freedom, while at the same
> > time strongly dictating modes of use... Oh well. Again, being somewhat
> > internally contradictory philosophically doesn't mean its not legally binding
> > nor that it's immoral.
>
I believe that RMS used to prefer public-domain software, along with
password-less operating systems (using the Honor System for security).
However, once the hackers at MIT were forced out of their AI Lab
(either going to Symbolics or losing their funding), they were no
longer in a Utopian environment. They were out in the real world, and
in the real world, there are lots of people who take advantage of
public-domain software, thus nullifying the point of making it public
domain in the first place (freedom). I think that RMS saw what
happened at Berkeley (``pirating'' of essentially public-domain
software), and took steps to correct this loophole in the GPL, which
is not neccessarily designed to encourage a very high number of users,
but rather to promote freedom and cooperation. It sounds ironic, but
in order to preserve freedom, he had to restrict the software
somewhat, but the GPL restricts you only from making the software less
free. I do not know what you mean about ``strongly dictating modes of
use''; yes, the GPL prevents you from making the GPLed software
proprietary, but it allows you to sell the software, modify it,
redistribute modifications... contrast the single freedom-preserving
restriction in the GPL to Apple's license, which states that you may
not design nuclear weapons with Apple software (or something similar,
I remember that from a several-year-old license, so it may no longer
apply).
Here's a metaphor: The GPL's restriction against making free software
proprietary is similar to the ``securitizing'' of the AI Lab at the
threat of a protest, except this time the protest is anti-freedom
instead of anti-research. RMS knows that if the most radical
anti-freedom protestors get into the lab, they will blow up the PDP-6.
So he must lock out the anti-freedom protesters to prevent the
destruction of the PDP-6. It is not a sacrifice willingly made,
because the locks that he hates so much will also keep two or three
non-protesters out, but the hated locks are now necessary since he is
in the real world now. This is actually a rather good metaphor since
the actual situations are similar.
> I don't know that it's really contradictory. It's a really clear
> expression of a certain strain of petty-bourgeois
> values-about-freedom / interests. It sits in the world view of the
> competant ocmputer user who can modify his/her software, and may be an
> author from time to time, but who doesn't need to derive his/her
> income from that authorship. It's an attempt to maximize the
> liberties of that user. Of course there are trade-offs, but there are
> trade-offs in everything in life. I think most people's problems with
> the GPL come from one of two sources:
>
> 1. They are in a different class of computer user than that for
> which the GPL was written. These people tend to object to it to
> the extent that their perception of their own interests diverge
> from that of the intended beneficiary of the GPL. For example,
> especially small-time software authors who rely on this for their
> income (I think I'm looking in the direction of KMP here) have
> quite different interests than what the GPL is trying to protect
> (eg, a university student). (This is why I said the GPL is a
> clear expression of a *certain* strain of petty-gourgeois
> interests -- this would be a different strain here)
>
The GPL is not really designed to protect the interests of a
university student. The GPL was written on the theory that maximum
freedom is morally and pragmatically correct. Personally, I think
that, morally and pragmatically, freedom is required for truly good
software design -- something both powerful and stable. (And with GNOME
and KDE, easy to use, also.) In fact, that last note is a very good
example of how the GPL is not anti-commercial -- consider Ximian,
which hacks on GNOME and distributes a pre-packaged,
easily-installable version of GNOME, called (suprise!) Ximian GNOME.
Ximian was founded by some of the leaders of the GNOME project. It is
quite successful. Also consider Progeny, Debian, Mandrake, LinuxPPC,
Red Hat, etc, and finally, IBM.
> 2. They are idealists. This cuts both ways, of course. Some users
> whose interests are well expressed by the GPL object to it on an
> ideological basis. And some users whose interests are
> contradicted by the GPL favor it on an ideological basis. I
> think it's funny when people accuse the GPL of being ideological.
> Certainly it wraps itself in a certain rhetoric, but it's a very
> clear expression of a certain class interest. Not good nor bad,
> no more no less.
There are different types of freedom. Consider the GNU General Public
License and the BSD-style license. The BSD license grants total
freedom -- basically copyrighted yet public domain software. The GPL
does not grant total freedom. However, the GPL is designed to promote
freedom itself, while BSD-style licenses merely grant freedom. So the
technically less free license could be said to generate more freedom
than the technically more free license. But they are both free
software licenses -- one idealistic, one extremely pragmatic. They are
suitable for different tasks, different software development styles --
but both free. One is not better than the other -- and if the world
was a huge AI Lab, perhaps RMS would be hacking BSD code right now.
--
BPT <···@hobbiton.org>
backronym for Linux: Linux Is Not Unix
BPT <···@hobbiton.org> writes:
> I think that RMS saw what
> happened at Berkeley (``pirating'' of essentially public-domain
> software),
One cannot pirate that which can be freely used. RMS wanted to
control the use and realized that public domain did not allow him that
control. As I understand it, from personal covnersations with him, he
feels there are good and bad uses of things, and specifically wants as
much personal control over good guys getting stuff and bad guys not
getting it.
There is nothing wrong with this. However, there is something
peculiar about co-opting the term "free" for this purpose.
In my experience in talking to him, RMS will freely admit that his
interests are selfish. Others speaking for him tend to paint his
motives as more purist. As I see it, though, and he's as much as said
this explicitly in conversations I've had with him, he's just trying
to protect his OWN freedom to do certain things he wants to do--he
doesn't really worry how that affects others. He seems shamelessly
selfish on this point.
Nothing wrong with that either. I just don't plan to vote for him as
a saint like others seem to want to.
I had a conversation one day where he criticized the CL HyperSpec for
not being "free". I said "what are you talking about? it can be
copied at no cost and serves the community well." He said he didn't
care that it served the community--that wasn't a goal of his. He was
annoyed that HE wasn't allowed to use it in ways HE wanted to. Funny
that he felt this was bad since I feel the same about software he
writes, except I think it's his right to decide how his software is
used, and I'd have expected him to think it was my right to set my own
terms.
Kent M Pitman <······@world.std.com> writes:
> BPT <···@hobbiton.org> writes:
>
> > I think that RMS saw what
> > happened at Berkeley (``pirating'' of essentially public-domain
> > software),
>
> One cannot pirate that which can be freely used. RMS wanted to
> control the use and realized that public domain did not allow him that
> control. As I understand it, from personal covnersations with him, he
> feels there are good and bad uses of things, and specifically wants as
> much personal control over good guys getting stuff and bad guys not
> getting it.
>
> There is nothing wrong with this. However, there is something
> peculiar about co-opting the term "free" for this purpose.
>
> In my experience in talking to him, RMS will freely admit that his
> interests are selfish.
All human beings are almost completely selfish. ``Altruistic'' people
act ``unselfishly'' to make them feel better and convince themselves
that they are better than non-altruistic people. I consider myself to
be quite selfish on a basic level, and if I am told that someone is
selfish it will be no surprise to me, and I will not count that as a
negative trait. What is usually meant by ``selfish'' in conventional
society is ``something that hampers progress'' or ``something which
harms the community whilst improving the situation of he who performed
whatever action is being discussed'' or ``something that someone did
that annoys me and is related to sharing''.
> Others speaking for him tend to paint his
> motives as more purist.
He is honest and he defends freedom and sharing. That's good enough
for me. Like I said above, most people are very selfish but are
dishonest about their selfishness. I usually respect people who will
admit that in many ways they are very selfish, at least more than an
equivalent person who claims that he or she is ``altruistic'' and
``unselfish''.
> As I see it, though, and he's as much as said
> this explicitly in conversations I've had with him, he's just trying
> to protect his OWN freedom to do certain things he wants to do--he
> doesn't really worry how that affects others. He seems shamelessly
> selfish on this point.
>
Oh no, *more* ``quibbling over semantics''... :)
I am not sure that he only wants to protect his own freedom. On a
basic level that is his goal (because humans are selfish); but he
worries about his actions affect others. In particular, he wants to
change society to accept hacker-style sharing as normal, because then
he will have more freedom to do what he wants, or perhaps I should say
that when most software is free he will not be impeded by non-free
software, software patents, etc. So your statement was technically
correct, but if I grok the intended meaning it is incorrect in some
ways. I think that perhaps he was referring to his *motivations*, not
his actions (but of course I may be wrong since I have never spoken to
him). However, it does not change my opinion that the thoughts that
are behind these statements are somewhat incorrect. (Very
interestingly, they are completely correct if you take them
literally!)
> Nothing wrong with that either. I just don't plan to vote for him as
> a saint like others seem to want to.
>
I wouldn't vote for him as a saint. However, I would vote him tied
with several other people for first or second place as ``Most Skilled
Software Developer Ever'', and tied with Linus Torvalds and a few
others as ``Person Who Changed Society Most in the Twentieth and
Twenty-First Centuries''.
> I had a conversation one day where he criticized the CL HyperSpec for
> not being "free". I said "what are you talking about? it can be
> copied at no cost and serves the community well." He said he didn't
> care that it served the community--that wasn't a goal of his. He was
> annoyed that HE wasn't allowed to use it in ways HE wanted to. Funny
> that he felt this was bad since I feel the same about software he
> writes, except I think it's his right to decide how his software is
> used, and I'd have expected him to think it was my right to set my own
> terms.
If the HyperSpec is public-domain or BSD-licensed it is free, but it
is not free if you cannot modify it. Being free and serving the
community well are completely seperate issues -- it could be argued
that SunOS, IRIX, etc, and Motif, CDE, etc, served the Unix community
well for many years. Being copied at no cost also has nothing to do
with freedom in this sense (I refer to things that do not cost money
as zero-cost, and things that can be copied without charge as
redistributable, to avoid confusion with ``free''.)
RMS certainly knows that it is your right (if I am correct that you
are the author as you imply) to decide how your software is
used^H^H^H^Hlicensed, but he also is allowed to be annoyed that it is
not licensed the way he would like it to be licensed (perhaps he wants
it released under the GFDL (GNU Free Documentation License)?). You are
allowed to be annoyed that GNU software isn't public-domain, aren't
you? Of course he *knows* that it is your right to set your own terms,
but judging from the rest of your explanation he would prefer that it
was released under the GFDL or something. And I am not RMS so although
I sound almost like he told me his opinion, he hasn't and these are my
opinions on what his opinions are.
PS. Are you the author of the CL Hyperspec? (Just wondering as I don't
know the author and don't know where to find it, but have heard a lot
about it. (and you imply this in the above paragraph.))
--
BPT <···@hobbiton.org>
backronym for Linux: Linux Is Not Unix
BPT <···@hobbiton.org> wrote in message news:<··············@lupus.i-did-not-set--mail-host-address--so-shoot-me>...
> What is usually meant by ``selfish'' in conventional
> society is ``something that hampers progress'' or ``something which
> harms the community whilst improving the situation of he who performed
> whatever action is being discussed'' or ``something that someone did
> that annoys me and is related to sharing''.
Since, in many cases where "selfish" is used, the meaning of "progress",
"harm", "community", etc. are actually under debate, "selfish" actually
means "that person is a poopy-head".
> He is honest and he defends freedom and sharing.
Stallman defends the "freedom" and "sharing" that he believes in. That's
a very different thing from what most of us think that "freedom" means.
There's a difference between my believing in your "freedom" to say
things that I agree with and my believing in your "freedom" to say
things that I vehemently disagree with. They are two very different
"freedoms".
FWIW - I find it interesting that many people act as if the reason
someone disagrees is that they don't understand. I find that most
of my stronger/better disagreements come when I really do understand.
-andy
BPT <···@hobbiton.org> writes:
> If the HyperSpec is public-domain or BSD-licensed it is free, but it
> is not free if you cannot modify it.
Check your dictionary. There is more than one meaning of free.
That the "free software" movement wnats to use one of these
definitions for its own purposes wouldn't bother me. All uses of
words use only one definition at a time, except deliberate puns.
That the "free software" movement likes to deprecate the other meaning of
free is an annoying and disingenuous. It attempts to paint the users of
legitimate other meanings of "free" as doing something bad, and that is
inappropriate.
> PS. Are you the author of the CL Hyperspec? (Just wondering as I don't
> know the author and don't know where to find it, but have heard a lot
> about it. (and you imply this in the above paragraph.))
I am the author but not for legal purposes (even though I wrote the
legalese, too). It was my idea to create the HyperSpec from the ANSI
CL spec, it was code I wrote (for Harlequin) that did the translation,
and it was my idea how to package the HyperSpec for free distribution
to the community. Harlequin, my employer at the time, legally owns
the resulting HTML markup of the HyperSpec; see legal notices in the
Help section of the HyperSpec for the more detailed version of all of
this. The underlying TeX markup has ownership that is legally less
clear; most of the community believes the TeX sources are in the
public domain, which was always the intent. The intent could have
been made legally plainer and was not, so a conservative lawyer might
tell you otherwise. We did some incredibly weird legal games in order
to assure that Harlequin had a proper title to claim it was a
derivative work of the ANSI CL standard. Franz has a derivative
document of the TeX sources but not of the ANSI CL standard. The
actual technical difference is NIL because there is nothing but
headers and frontmatter different between the document they based
their pedigree on and what Harlequin based their document on.
No one ever said the world of copyright was easy... but I still prefer
it to a world without copyright.
> My name is quoted here but the text being replied to is not mine, in spite
> of the mixed up levels of anglebrackets. I think it's andy talking.
>
> > > >······@earthlink.net (Andy Freeman) writes:
>
> > > It winds up in the same sort of thing as internal use of GPLed
Nope. Andy rarely posts about the GPL, and didn't post that.
(Andy occasionally points out that the beast of Redmond implemented
Stallman's dream, and, like most people who get what they want,
Stallman doesn't see it and is pissed because it didn't work out
as he intended. Who'd have ever thought that he wouldn't be
deciding how the hardware tax revenues were allocated to software
developers.)
However, this is the sort of quote confusion that Andy uses as a
reason to delete attribution lines.
-andy
Andy Freeman <······@earthlink.net> wrote in message
·································@posting.google.com...
> Nope. Andy rarely posts about the GPL, and didn't post that.
> (Andy occasionally points out that the beast of Redmond implemented
> Stallman's dream,
How so?
Kent M Pitman <······@world.std.com> wrote in message
····················@world.std.com...
> My name is quoted here but the text being replied to is not mine, in spite
> of the mixed up levels of anglebrackets. I think it's andy talking.
Whoever, much of the articles posted by me at the same time (as indeed
this was) were more along the lines of ranting monologues than contributions
to discussion or argument.
> I think LGPL is for what you want.
>
> But regardless, you always have the option ont to use the GPL'd stuff.
>
> I personally don't like the GPL. But that doesn't mean it injures me that
> it exists. I use GPL'd software sometimes even. I just wouldn't attach
> that agreement to my own software. And it keeps me from using GPL'd
> software in some things I do. Such is life. I can live with it. It's
the
> job of the person who makes the software to dictate acceptable use; that's
> the irony of the GPL. It wants to talk about freedom, while at the same
> time strongly dictating modes of use... Oh well. Again, being somewhat
> internally contradictory philosophically doesn't mean its not legally
binding
> nor that it's immoral.
I use GPL'd stuff all the time - Linux is my primary operating system.
(Before anyone goes looking at the X- headers: say winmodem). The stuff
itself is great - it's being used in the "bazaar" development model, which
harnesses many more people than would be with any other extant model.
As you say, it is the owner's prerogative to dictate use of his work,
and I fully applaud this (as I said I was ranting somewhat). To the extent
that there was a point, it was that I believe that the LGPL would encourage
commercial companies to use free software, improve them as necessary, and
make those improvements publicly available. At the very least, we'd get well
designed systems, if many people wanted to modify or extend them.
From: George Neuner
Subject: Re: Engineering Envy [was: Re: CL and UML]
Date:
Message-ID: <3b3cc432.2577134663@helice>
On Fri, 29 Jun 2001 16:50:20 GMT, Kent M Pitman <······@world.std.com>
wrote:
>
>Er, I don't *think* you can patent an idea. I think it has to be a process.
>
Technically that is true, but IMO a lot of recent patent grants walk a
razor thin line ...
>> Mind you, I think patents should be irradicated or SEVERELY reformed.
>
>Yep.
Not eradicated, I think, but most definitely reformed.
George
·······@dyn.com (George Neuner) wrote
> It doesn't matter that your field of expertise is unwarrantied. The
> law says that you may be held liable for harm simply by virtue of
> "being an expert". The world is full of people who act on hearsay,
> mostly to their own detriment. To their credit, most don't think to
> sue.
and previously
> The law recognizes the idea of a "conspicuous expert" and gives more
> weight to the casual utterances of such a person when remarks having
> basis in that person's expert knowledge are made in "mixed" company,
> ie. in the company of non-experts.
Umm, did Neuner also previously write that independent yet subsequent
invention is a viable defense against patent infringment? (It isn't
in the US or any of the major European countries, or Japan. It may
be somewhere else.) If so, I'd look elsewhere for legal advice ....
-andy
From: George Neuner
Subject: Re: Engineering Envy [was: Re: CL and UML]
Date:
Message-ID: <3b3cc0e5.2576289939@helice>
On 28 Jun 2001 17:38:54 -0700, ······@earthlink.net (Andy Freeman)
wrote:
>·······@dyn.com (George Neuner) wrote
>> It doesn't matter that your field of expertise is unwarrantied. The
>> law says that you may be held liable for harm simply by virtue of
>> "being an expert". The world is full of people who act on hearsay,
>> mostly to their own detriment. To their credit, most don't think to
>> sue.
>
>and previously
>
>> The law recognizes the idea of a "conspicuous expert" and gives more
>> weight to the casual utterances of such a person when remarks having
>> basis in that person's expert knowledge are made in "mixed" company,
>> ie. in the company of non-experts.
>
>Umm, did Neuner also previously write that independent yet subsequent
>invention is a viable defense against patent infringment? (It isn't
>in the US or any of the major European countries, or Japan. It may
>be somewhere else.) If so, I'd look elsewhere for legal advice ....
>
I have contacts for about 30 patent attorneys if you'd like to talk to
one.
By sure to ask about "clean rooms" and "black boxes".
George
------------------------------------------------------------
Disclaimer: I am not a patent attorney. My father, sister,
and a dozen or so family friends are.
George Neuner wrote:
[snippo]
>
>
> I have contacts for about 30 patent attorneys if you'd like to talk to
> one.
>
> By sure to ask about "clean rooms" and "black boxes".
>
> George
> ------------------------------------------------------------
> Disclaimer: I am not a patent attorney. My father, sister,
> and a dozen or so family friends are.
Interesting. I thought the Phoenix BIOS trick (which I assume you are referencing here) was a defense against copyright violation only. How did
Alexander Graham Bell or the Wright Brothers enforce their patents? There were bona-fide "clean room" competitors in at least the Bell case and to a
greater or lesser extent in the Wright case.
I'm not a patent lawyer either (but I get to talk to them sometimes). This is a fascinating wrinkle if it works.
Larry -- speaking on his own
From: George Neuner
Subject: Re: Engineering Envy [was: Re: CL and UML]
Date:
Message-ID: <3b3cc363.2576927806@helice>
And if you had paid attention you would know that I recommended that
anyone with questions should talk to an attorney.
George
------------------------------------------------------------
Disclaimer: I am not a patent attorney. My father, sister,
and a dozen or so family friends are.
David Thornley wrote:
[snip]
> Nor do I know all that much about the contents of the bill.
> It says "any other engineering discipline", and the engineers that
> I know don't seem to think that their legal responsibility is
> intolerable. (I did casually assume that "no less liable" probably
> implied "no more liable", and based my comments on that. If this
> is wrong, then the bill would be a serious mistake.)
>
The issue here is that other engineers seem to understand and bound their liability. I know of no software designer in a comparable
position.
A stress failure of a bolt is fundamentally different from a mistake in a line of code. They behave differently and have different
certification consequences. The latter, in particular, has entirely unpredictable ramifications in the current state of the art. The
ME, by contrast, just makes sure enough bolts are there so that if a couple break, ordinary maintenance will replace them. If someone
screws up and uses uncertified bolts from the local hardware store, and they all break, he has at least some amount of legal defense
because they visibly departed from his design and specifications. Some jury may fall for a sob story and dock the engineer for not
being omniscient enough to design for fraud, but the judge can usually straighten it out on appeal.
I don't know of an analogy in software for these situations; when code is wrong it is absolutely wrong -- it goes from being a
certified bolt to a cheapie that breaks. I don't think our liability system is going to have it down pat as to how to assign blame in
this set of circumstances for some time. Not when you have a system where failure is downright inevitable and the effects of failure
are entirely unpredictable in advance.
Larry
David Thornley wrote:
> In article <···············@world.std.com>,
> Kent M Pitman <······@world.std.com> wrote:
>>Larry Loen <······@us.ibm.com> writes:
>>
>>> I was told at a conference that a bill was introduced in Texas to
>>> make programmers no less liable than any other engineering
>>> discipline. Never heard if it passed, but we won't forever get to
>>> call ourselves "artists" whilst our products cause airplanes to fall
>>> out of the sky.
>>
>>It would be a severe error to do this.
>>
> From where I sit, any means to make commercial software vendors
> accept more responsibility can't be all wrong.
>
>>This would be like introducing a bill to suggest that those who speak
>>should be no less liable for their words than lawyers. After all, we
>>won't forever get to call ourselves "poets" while our words cause
>>contracts to fail.
>>
> What's the difference between my words and a lawyer's words? If
> either of us writes a contract, it's a contract, and the words are
> important regardless of who wrote them. The lawyer is much more
> likely to get the words right than I am, just as I'm much more
> likely to get a program to work than he or she is.
>
>>Programming is neither art nor engineering. It is just words with
>>meaning.
>>
> A blueprint for a bridge, or a circuit schematic, is lines, symbols,
> and words with meaning. These things are often considered part
> of engineering. The guy who does the actual rivetting is often
> not an engineer.
>
>>When meaning is held to an engineering task, it should perhaps be done
>>with appropriate legal weight.
>
> Right.
>
> But such a statement should not be confused with
>>saying that the only possible use of programming is engineering, without
>>the
>>loss of other disciplines. Just as human language should not be limited
>>nerely to lawyering.
>>
> I think we need to divide programming, here, into cases where there are
> serious consequences of program failure (in a general sense) and cases
> where there are not.
>
> If there are serious consequences, then somebody needs to be held
> responsible. The idea of a world where something can be commissioned
> for a task, and that thing can fail and kill somebody, and nobody's
> responsible, frightens me. We've moved away from that with the
> idea of engineering responsibility in most disciplines, but if I
> screw up in programming and kill somebody there's no legal way to
> hold me responsible, and I think that's bad.
You're right - but it is a bit more difficult to do that with software. If
Person A writes a little library that does nothing special but contains a
bug and some other developer B uses (besides of much much more other parts
this small library in the software of an aircraft - who should be
responsible?
I'm rather sure you'll now say A is responsible because he caused the bug,
but this means that you have to do _all_ work as if you would code for an
aircraft or a Space Shuttle because you never know if someone uses it later
for something like this.
ciao,
Jochen
Jochen Schmidt <···@dataheaven.de> writes:
> David Thornley wrote:
> > If there are serious consequences, then somebody needs to be held
> > responsible. The idea of a world where something can be commissioned
> > for a task, and that thing can fail and kill somebody, and nobody's
> > responsible, frightens me. We've moved away from that with the
> > idea of engineering responsibility in most disciplines, but if I
> > screw up in programming and kill somebody there's no legal way to
> > hold me responsible, and I think that's bad.
>
> You're right - but it is a bit more difficult to do that with software. If
> Person A writes a little library that does nothing special but contains a
> bug and some other developer B uses (besides of much much more other parts
> this small library in the software of an aircraft - who should be
> responsible?
It's no more difficult to do that with software than with hardware.
For eaxmple, what if Person A manufactures an O-ring that is faulty,
and Person B uses that O-ring in a spacecraft and that spacecraft
blows up in flight, who is responsible?
How about this one: If Person A manufactures a tire and Person B uses
that tire in the manufacture of an SUV, and that SUV crashes and kills
people, who is responsible?
Duane Rettig (Still-living owner of an SUV made by Person B)
In article <·············@beta.franz.com>,
Duane Rettig <·····@franz.com> wrote:
>Jochen Schmidt <···@dataheaven.de> writes:
>
>> David Thornley wrote:
>> > If there are serious consequences, then somebody needs to be held
>> > responsible. The idea of a world where something can be commissioned
>> > for a task, and that thing can fail and kill somebody, and nobody's
>> > responsible, frightens me. We've moved away from that with the
>> > idea of engineering responsibility in most disciplines, but if I
>> > screw up in programming and kill somebody there's no legal way to
>> > hold me responsible, and I think that's bad.
>>
>> You're right - but it is a bit more difficult to do that with software. If
>> Person A writes a little library that does nothing special but contains a
>> bug and some other developer B uses (besides of much much more other parts
>> this small library in the software of an aircraft - who should be
>> responsible?
>
>It's no more difficult to do that with software than with hardware.
>
>For eaxmple, what if Person A manufactures an O-ring that is faulty,
>and Person B uses that O-ring in a spacecraft and that spacecraft
>blows up in flight, who is responsible?
>
>How about this one: If Person A manufactures a tire and Person B uses
>that tire in the manufacture of an SUV, and that SUV crashes and kills
>people, who is responsible?
>
>Duane Rettig (Still-living owner of an SUV made by Person B)
Common Lispers drive SUVs...?! :-)
--d
Jochen Schmidt <···@dataheaven.de> writes:
> You're right - but it is a bit more difficult to do that with software. If
> Person A writes a little library that does nothing special but contains a
> bug and some other developer B uses (besides of much much more other parts
> this small library in the software of an aircraft - who should be
> responsible?
Person B. The If Person A sells balsa wood, and person B uses this balsa
wood and other materials to make an aeroplane, and the wings snap off
in flight, whose fault is it? Unless the balsa wood came in a bag
labelled "warranted for aircraft wings", that is.
(Yes, I know, analogy is the rusty blunt hacksaw of Usenet)
It may presently be socially acceptable for the systems integrator to
blame the supplier of some component ("oh, it's microsoft windows, you
know what that's like") instead of admitting liability, but I don't
think that's the situation we want to be in.
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Jochen Schmidt <···@dataheaven.de> writes:
>
> You're right - but it is a bit more difficult to do that with software. If
> Person A writes a little library that does nothing special but contains a
> bug and some other developer B uses (besides of much much more other parts
> this small library in the software of an aircraft - who should be
> responsible?
> I'm rather sure you'll now say A is responsible because he caused the bug,
> but this means that you have to do _all_ work as if you would code for an
> aircraft or a Space Shuttle because you never know if someone uses it later
> for something like this.
I think that this rather overstates the case.
In physical engineering there are various levels of quality and
certification. I can go to my local hardware store and buy some cheap
screws. These work well on small repairs and home projects, but Boeing
or Airbus Industries would not use the same parts in their aircraft.
They are required to use appropriately certified parts.
One could easily imagine a similar system for software. There are many
general purpose libraries with no particular guarantee, as well as some
others that have been appropriately certified. If you don't want to go
through the effort to have your library certified, then it would seem
that someone who uses it in preference to a certified library would be
taking on the liability.
The US Food and Drug Administration has guidelines for evaluating
software in life-critical medical devices. I'm not familiar with the
details, but there are ways of making certain software adhere to more
formal standards.
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu
> > You're right - but it is a bit more difficult to do that with software. If
> > Person A writes a little library that does nothing special but contains a
> > bug and some other developer B uses (besides of much much more other parts
> > this small library in the software of an aircraft - who should be
> > responsible?
> > I'm rather sure you'll now say A is responsible because he caused the bug,
> > but this means that you have to do _all_ work as if you would code for an
> > aircraft or a Space Shuttle because you never know if someone uses it later
> > for something like this.
>
> I think that this rather overstates the case.
>
> In physical engineering there are various levels of quality and
> certification. I can go to my local hardware store and buy some cheap
> screws. These work well on small repairs and home projects, but Boeing
> or Airbus Industries would not use the same parts in their aircraft.
> They are required to use appropriately certified parts.
This discussion started out when someone noted an effort to "certify"
programmers AND make them personally liable and made some comparisons
to engineering disciplines where such liability exists.
I'm confused. If a Braniff 747 drops onto my house, what's the point
of individual liability on the part of the guy who may have mis-designed
the rudder, the "certified plane refueler" who may have filled the tanks
with fire-retardant gell, the pilot who may have confused my street for
a runway, etc? Why do I care what caused the injury? What good will
it do for me to take some guy's house? Why isn't this completely Braniff's
problem?
KMP alluded to a similar question some time back and never really got
an responsive answer. We long ago figured out that end-to-end solutions
are the ones that work, that intermediate ecc is merely a possible
performance enhancer, so why the obsession with exposing these innards
to someone past the end?
-andy
······@earthlink.net (Andy Freeman) writes:
> I'm confused. If a Braniff 747 drops onto my house, what's the point
> of individual liability on the part of the guy who may have mis-designed
> the rudder, the "certified plane refueler" who may have filled the tanks
> with fire-retardant gell, the pilot who may have confused my street for
> a runway, etc? Why do I care what caused the injury? What good will
> it do for me to take some guy's house? Why isn't this completely Braniff's
> problem?
The fairest reading is to say that Braniff needs someone to sue, too,
recursively.
Eventually, it will be the person with the mis-designed part IF it was
sold with a warranty. What I'm suggesting is that it ought not be the
fact of having made a thing which implies a warranty, but rather a separate
step of having offered a warranty.
Pitman's Two-Bit Rule applies here:
Do not use a single bit to represent two bits worth of data.
(Explanation: It is a common design error to assume that two closely
correlated events happen enough that the presence of one implies the other.
Don't do this, if there is any chance at all that there might need to be a
divergence of the two. There is a definite need to separate the notion
of "writing a program" from "offering a program as suitable for a purpose".
The latter should not be something you do accidentally.)
> KMP alluded to a similar question some time back and never really got
> an responsive answer. We long ago figured out that end-to-end solutions
> are the ones that work, that intermediate ecc is merely a possible
> performance enhancer, so why the obsession with exposing these innards
> to someone past the end?
I'm assuming the innards are exposed to the company that's getting the
external suit, and that it has to resolve the problem. The part I find
non-responsive is that no one has answered as to why the act of writing
program text should, of necessity, imply a warranty. If it doesn't, this
whole discussion is moot.
Presently, lots of software is offered with "no warranty of any kind".
That practice is gradually changing in subtle ways, but it's only by
consumers refusing to buy it that way that it's likely to change much.
Geez, if you can sell it with no warranty, why NOT? Offering a
warranty will drive up the price and maybe the market doesn't want the
price driven up. Maybe it does trust the product and prefers the
price. Nothing wrong with that. Just don't let them talk out of both
sides of their mouth, saying they trust it but suing after the fact
anyway because an overactive legal system lets them.
Kent M Pitman <······@world.std.com> wrote in message news:<···············@world.std.com>...
> ······@earthlink.net (Andy Freeman) writes:
>
> > I'm confused. If a Braniff 747 drops onto my house, what's the point
> > of individual liability on the part of the guy who may have mis-designed
>
> The fairest reading is to say that Braniff needs someone to sue, too,
> recursively.
Iff that's the deal that Braniff made with its suppliers. Braniff may
well realize that being able to sue fuelers is a waste of time because
their resources are insufficient to cover the consequences of their
mistakes. In that case, Braniff may choose to require insurance, to
buy general coverage itself, or to self-insure.
> Eventually, it will be the person with the mis-designed part IF it was
> sold with a warranty. What I'm suggesting is that it ought not be the
> fact of having made a thing which implies a warranty, but rather a separate
> step of having offered a warranty.
Yup. There's a huge difference between Braniff's relationship with its
suppliers and my relationship (as the target of planes dropping out of the
sky) and Braniff, so it's rather silly that we play by the same rules wrt
supplier error.
> Pitman's Two-Bit Rule applies here:
>
> Do not use a single bit to represent two bits worth of data.
>
> (Explanation: It is a common design error to assume that two closely
> correlated events happen enough that the presence of one implies the other.
> Don't do this, if there is any chance at all that there might need to be a
> divergence of the two. There is a definite need to separate the notion
> of "writing a program" from "offering a program as suitable for a purpose".
> The latter should not be something you do accidentally.)
Of course, this is not software specific.
-andy
······@earthlink.net (Andy Freeman) writes:
> > Pitman's Two-Bit Rule applies here:
> >
> > Do not use a single bit to represent two bits worth of data.
> >
> > (Explanation: It is a common design error to assume that two closely
> > correlated events happen enough that the presence of one implies the other.
> > Don't do this, if there is any chance at all that there might need to be a
> > divergence of the two. There is a definite need to separate the notion
> > of "writing a program" from "offering a program as suitable for a purpose".
> > The latter should not be something you do accidentally.)
>
> Of course, this is not software specific.
Nor is the failure to apply billions of other lessons learned about
describing "process" or "information" to the real world. Such a pity
non-programmers don't at least have our vocabulary available when it's
relevant. :-(
Kent M Pitman <······@world.std.com> wrote in message
····················@world.std.com...
> Presently, lots of software is offered with "no warranty of any kind".
> That practice is gradually changing in subtle ways, but it's only by
> consumers refusing to buy it that way that it's likely to change much.
> Geez, if you can sell it with no warranty, why NOT? Offering a
> warranty will drive up the price and maybe the market doesn't want the
> price driven up. Maybe it does trust the product and prefers the
> price. Nothing wrong with that. Just don't let them talk out of both
> sides of their mouth, saying they trust it but suing after the fact
> anyway because an overactive legal system lets them.
No other product may be sold without warranty (In the UK, AFAIK)
- It certainly isn't common practice to do so, and definitely not in markets
where significant loss is possible from use of the product. Given how
crucial software is in our society, crap products are unacceptable.
"Marcin Tustin" <·······@GUeswhatthisbitisfor.mindless.com> writes:
> Kent M Pitman <······@world.std.com> wrote in message
> ····················@world.std.com...
>
> > Presently, lots of software is offered with "no warranty of any kind".
> > That practice is gradually changing in subtle ways, but it's only by
> > consumers refusing to buy it that way that it's likely to change much.
> > Geez, if you can sell it with no warranty, why NOT? Offering a
> > warranty will drive up the price and maybe the market doesn't want the
> > price driven up. Maybe it does trust the product and prefers the
> > price. Nothing wrong with that. Just don't let them talk out of both
> > sides of their mouth, saying they trust it but suing after the fact
> > anyway because an overactive legal system lets them.
>
> No other product may be sold without warranty (In the UK, AFAIK)
> - It certainly isn't common practice to do so, and definitely not in markets
> where significant loss is possible from use of the product. Given how
> crucial software is in our society, crap products are unacceptable.
The discussion wasn't originally about SELLING software. It was about
MAKING software. It was about the idea that I could be sued for making
someting in my kitchen and leaving it laying around and having someone else
use it and claim there was a warranty made just by its CREATION.
I do think it is wrong for there to be an implied warranty upon sale, but
that's very different and less threatening than one created upon creation
or upon giving as a gift.
Kent M Pitman <······@world.std.com> wrote in message
····················@world.std.com...
> I do think it is wrong for there to be an implied warranty upon sale, but
> that's very different and less threatening than one created upon creation
> or upon giving as a gift.
Later reading made this clear. However, I do think it wrong that
(to take an extreme example) MS can sell Windows without
warranty - there is no way that they can claim that their packaging
and advertising does not imply that it is an OS; I also think that one
can expect certain things from an OS, like a process, once started,
will not terminate unpredictably, as long as the OS is used correctly.
"Marcin Tustin" <·······@GUeswhatthisbitisfor.mindless.com> writes:
> Kent M Pitman <······@world.std.com> wrote in message
> ····················@world.std.com...
>
> > I do think it is wrong for there to be an implied warranty upon sale, but
> > that's very different and less threatening than one created upon creation
> > or upon giving as a gift.
>
> Later reading made this clear. However, I do think it wrong that
> (to take an extreme example) MS can sell Windows without
> warranty - there is no way that they can claim that their packaging
> and advertising does not imply that it is an OS; I also think that one
> can expect certain things from an OS, like a process, once started,
> will not terminate unpredictably, as long as the OS is used correctly.
I don't know. "Using an OS correctly" is remarkably hard to define.
I'm willing to be a little forgiving on this point. I'd get out of the
OS market if someone was going to hold me to a warranty like that.
I might be willing to warranty that I'd help look for the bug if it came
up, and that I'd try to have this as a goal, but I would not want lawsuits
if someone found a problem.
I think it injures the space of available options by scaring of good people
to require them to warranty any more than they want to offer. I think the
consumer should read the warranty and say "I don't like the price" if they
don't like what's warrantied. The contract of sale is already adequate to
deal with this. I think it is undue government interference for there to be
anything else.
I *don't* mind the government making certain modifying terms that they
regulate. Saying I market a "grade A safe" operating system, for example,
where maybe the government monitors various grades of safety.
But that shouldn't keep me from selling an "operating system", unqualified,
to whomever might buy it and not care.
Kent M Pitman <······@world.std.com> wrote in message
····················@world.std.com...
> I don't know. "Using an OS correctly" is remarkably hard to define.
> I'm willing to be a little forgiving on this point. I'd get out of the
> OS market if someone was going to hold me to a warranty like that.
> I might be willing to warranty that I'd help look for the bug if it came
> up, and that I'd try to have this as a goal, but I would not want lawsuits
> if someone found a problem.
Correct and reasonable use would be running the manufacturers default
setup, plus one user process, and have several hours of using that program
consistently kill the os to the point where it spontaneously reboots, and
have that problem go away when doing the same thing under the industrial
version of that OS (assuming that the program in question wasn't memory
leaking, or doing anything else foolish. My suspicion is that win9x memory
management is so poor that all processes are liable to leak memory, however
well they're written, if they allocate and deallocate enough of it.).
> I think it injures the space of available options by scaring of good
people
> to require them to warranty any more than they want to offer. I think the
> consumer should read the warranty and say "I don't like the price" if they
> don't like what's warrantied. The contract of sale is already adequate to
> deal with this. I think it is undue government interference for there to
be
> anything else.
I'm sympathetic to this, but it goes a little too close to caveat emptor
in a market where most purchasers totally unqualified and lacking in
confidence. The purchaser often doesn't actually know what they want to buy.
Of course, in this case, they shouldn't be doing anything with the kit where
they might suffer substantial loss, and hence want to sue anyone. I do think
that having used the software, and finding it to be unsuitable, the customer
should be able to get their money back, or a fixed version (in that case).
Of course, even if that were the case, MS has never sold it's 9x OS as being
suitable for much other than word processing, games etc..
Essentially I support the status quo in the UK - if advertising could
lead a reasonable person to believe something to be true about a product,
then that is implicitly included in the contract of sale. I also don't
believe that this should be disclaimable in any smallprint on the packaging
or inside the packaging - any disclaimer should be unmissable to the average
customer (eg it's up to the blind to ask to have anything unusual on the box
described to them), and easily comprehensible (eg not entirely written in a
foreign language, transcribed in a script totally unlike that used for that
language, and employing strange colloquialisms from a culture unrelated to
the country of sale, language, and script.)
Certification, of course, does not require the state - and involvement of
institutions like the state is to be reduced wherever sensible alternatives
are provided.
"Marcin Tustin" <·······@GUeswhatthisbitisfor.mindless.com> writes:
> I'm sympathetic to this, but it goes a little too close to caveat emptor
> in a market where most purchasers totally unqualified and lacking in
> confidence.
Anything other than "caveat emptor" breeds an audience of idiots.
Free markets work not at all if the consumer relies on the vendor to be
the one with all the brains.
In article <···············@world.std.com>, Kent M Pitman
<······@world.std.com> wrote:
>"Marcin Tustin" <·······@GUeswhatthisbitisfor.mindless.com> writes:
>
>> I'm sympathetic to this, but it goes a little too close to caveat emptor
>> in a market where most purchasers totally unqualified and lacking in
>> confidence.
>
>Anything other than "caveat emptor" breeds an audience of idiots.
>
>Free markets work not at all if the consumer relies on the vendor to be
>the one with all the brains.
Free markets don't work in general (there are few if any unregulated markets)
because one party (usually the seller) has access to far more information than
the other, and acquiring equivalent information is either infeasible (trade
secrets) or worth more than the cost of the transaction (most mass-market
items including software and hardware). You can say "just don't do the
transaction" then, but if a manufacturer's business plan requires (for
sufficient volume) that the vast majority of its customers be uninformed,
then the alternative to regulation would seem to be _per se_ fraud.
Even back in 1900, tests for chalk in milk were easy to perform, but that
doesn't mean pure food laws were a bad idea....
paul
··@panix.com (Paul Wallich) writes:
> In article <···············@world.std.com>, Kent M Pitman
> <······@world.std.com> wrote:
>
> >"Marcin Tustin" <·······@GUeswhatthisbitisfor.mindless.com> writes:
> >
> >> I'm sympathetic to this, but it goes a little too close to caveat emptor
> >> in a market where most purchasers totally unqualified and lacking in
> >> confidence.
> >
> >Anything other than "caveat emptor" breeds an audience of idiots.
> >
> >Free markets work not at all if the consumer relies on the vendor to be
> >the one with all the brains.
>
> Free markets don't work in general (there are few if any unregulated
> markets)
Agreed, though there's sure to be some quibbling about what those regulated
markets need to be. [My understanding is that it's mostly things for which
demand is relatively inelastic (like health care, fuel oil, and so on)
that really require this. I don't see software as being part of that space.]
> because one party (usually the seller) has access to far
> more information than the other,
I don't agree that the reason for necessary regulation typically relates to
this. I think it's common to regulate on this basis, but we can quibble
again on whether such regulation is necessary. I'd say it's generally a
political division here.
I think there's a fundamental, qualitative (not just quantitative)
difference between "You have a disease and I know how to cure you and
you'll die if you don't pay me a million dollars". and "I have a
device here which I claim will perform a certain function, but you'll
have to test it yourself".
> and acquiring equivalent
> information is either infeasible (trade secrets) or worth more than
> the cost of the transaction (most mass-market items including
> software and hardware). You can say "just don't do the transaction"
> then, but if a manufacturer's business plan requires (for sufficient
> volume) that the vast majority of its customers be uninformed, then
> the alternative to regulation would seem to be _per se_ fraud.
I would have thought the Internet would be quickly flooded with
hucksters who did a lot of the second, and surely there are some, but
I have been surprised to see that "advertising dollars" are more of a
trust mark than I'd have expected. Speaking approximately, now, I
think no one who invests millions in promoting themselves is going to
be selling vaporware because they are going to waste that ad
investment on making a bad name for themselves. Trust marks are VERY
hard to create, and people do not throw them away lightly. So in fact
the market does not tend toward fraud as a basic element of business
unless, perhaps, it also utterly controls the media so that consumers
cannot share information with one another. I don't see lack of info
sharing being the problem on the web.
> Even back in 1900, tests for chalk in milk were easy to perform, but that
> doesn't mean pure food laws were a bad idea....
Nothing wrong with testing and labeling. But no reason it has to be done
by governments. Thing that are of no value will be naturally removed by
the market unless the person can't afford otherwise. And then it didn't
have no value.
You're stuck at sea with no fresh water. You come upon a small island
with a river. You have no matches to boil the water. You (a) drink
it anyway, figuring it's better than sea water or (b) continue to drink
sea water waiting for a government health inspector to tell you that the
river water is safe?
I feel bad for people who have to live on the margin. But there are
many people in the world for whom the choice isn't "good food" or
nothing, it's "food of any kind" or nothing. You see them picking
through the dumpsters for half-eaten burgers all the time. How can
getting day-old bread from a bakery, even if the bakery doesn't have
the ability to test it or offer a warranty, be worse? Why should I have
to throw it in the trash in order to (pardon the pun) "legally launder" it
for them to eat?
Software is the same thing. A lot of people want tools at cheap prices.
Enough that they'll routinely steal it. THey don't get a warranty that way
anyway--if they expose how they got it, they're in trouble.. Why is it worse
to allow someone to sell it with a partial warranty at a price they can
afford, making them non-criminals and offering money to someone who can maybe
give them what they want at a price they can afford? Whether they can
actually keep the customer base happy is something markets can sort out.
Maybe people will go back to stealing. If they do, the person offering the
low-priced item will go out of business. If not, then why should the
low-price/low-warranty item be disallowed?
In article <···············@world.std.com>, Kent M Pitman
<······@world.std.com> wrote:
>··@panix.com (Paul Wallich) writes:
>
>> In article <···············@world.std.com>, Kent M Pitman
>> <······@world.std.com> wrote:
>>
>> >"Marcin Tustin" <·······@GUeswhatthisbitisfor.mindless.com> writes:
>> >
>> >> I'm sympathetic to this, but it goes a little too close to caveat emptor
>> >> in a market where most purchasers totally unqualified and lacking in
>> >> confidence.
>> >
>> >Anything other than "caveat emptor" breeds an audience of idiots.
>> >
>> >Free markets work not at all if the consumer relies on the vendor to be
>> >the one with all the brains.
>>
>> Free markets don't work in general (there are few if any unregulated
>> markets)
>
>Agreed, though there's sure to be some quibbling about what those regulated
>markets need to be. [My understanding is that it's mostly things for which
>demand is relatively inelastic (like health care, fuel oil, and so on)
>that really require this. I don't see software as being part of that space.]
>
>> because one party (usually the seller) has access to far
>> more information than the other,
>
>I don't agree that the reason for necessary regulation typically relates to
>this. I think it's common to regulate on this basis, but we can quibble
>again on whether such regulation is necessary. I'd say it's generally a
>political division here.
>
>I think there's a fundamental, qualitative (not just quantitative)
>difference between "You have a disease and I know how to cure you and
>you'll die if you don't pay me a million dollars". and "I have a
>device here which I claim will perform a certain function, but you'll
>have to test it yourself".
...
Ah, yes, but that's not really what we've got in the software industry.
It's "I have a device here which I claim will perform a certain function,
but you'll have to test it yourself, and you have to buy it to test it, and
oh, by the way, i bought the competing company last week,"
>> Even back in 1900, tests for chalk in milk were easy to perform, but that
>> doesn't mean pure food laws were a bad idea....
>
>Nothing wrong with testing and labeling. But no reason it has to be done
>by governments. Thing that are of no value will be naturally removed by
>the market unless the person can't afford otherwise. And then it didn't
>have no value.
That's assuming minor details like no barriers to entry for competition, and
no barriers to market exit for the consumer. Oh, and no inducements for
"independent" reviewers to slant their reports depending on who's buying
ad space this year...
>You're stuck at sea with no fresh water. You come upon a small island
>with a river. You have no matches to boil the water. You (a) drink
>it anyway, figuring it's better than sea water or (b) continue to drink
>sea water waiting for a government health inspector to tell you that the
>river water is safe?
Someone else is on the island already, and says, "you can drink from the
river, but my outhouse empties into it just below this spring I've roped
off. So really, you'd better just promise to work for me in return for a
ready supply of water that I promise I've boiled." It all depends on which
analog you're willing to use.
>I feel bad for people who have to live on the margin. But there are
>many people in the world for whom the choice isn't "good food" or
>nothing, it's "food of any kind" or nothing. You see them picking
>through the dumpsters for half-eaten burgers all the time. How can
>getting day-old bread from a bakery, even if the bakery doesn't have
>the ability to test it or offer a warranty, be worse? Why should I have
>to throw it in the trash in order to (pardon the pun) "legally launder" it
>for them to eat?
Oddly enough, bakeries do offer day-old bread. But once again, it's
a question of analogy -- if the bakery mixed floor sweepings in with
the old bread, and offered it up front rather than in the dumpster,
you might be pretty annoyed with them for pretending to feed people
when they're actually just trying to reduce their carting bill..
>Software is the same thing. A lot of people want tools at cheap prices.
>Enough that they'll routinely steal it. THey don't get a warranty that way
>anyway--if they expose how they got it, they're in trouble.. Why is it worse
>to allow someone to sell it with a partial warranty at a price they can
>afford, making them non-criminals and offering money to someone who can maybe
>give them what they want at a price they can afford? Whether they can
>actually keep the customer base happy is something markets can sort out.
>Maybe people will go back to stealing. If they do, the person offering the
>low-priced item will go out of business. If not, then why should the
>low-price/low-warranty item be disallowed?
I'm not saying that the low-price low-warranty item should be disallowed,
_as long as that's very explicitly what it is_. What we have now in the
software biz is a large quantity of high-price low-warranty products, which
look like high-warranty products until your sunk costs are high enough to
discourage tossing them and going for replacement. And (Gresham's Law)
those products, having higher margins and hence more money available for
influencing purchasing decisions at all levels, tend to drive out not only
high-priced, high-warranty items but also low-price, low-warranty ones.
paul
··@panix.com (Paul Wallich) writes:
> >I think there's a fundamental, qualitative (not just quantitative)
> >difference between "You have a disease and I know how to cure you and
> >you'll die if you don't pay me a million dollars". and "I have a
> >device here which I claim will perform a certain function, but you'll
> >have to test it yourself".
> ...
> Ah, yes, but that's not really what we've got in the software industry.
> It's "I have a device here which I claim will perform a certain function,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Not at CREATION time of the device we do not. We might have that at time of
a sale in a commercial environment, but if so, that *is* a warranty.
> but you'll have to test it yourself, and you have to buy it to test it, and
> oh, by the way, i bought the competing company last week,"
This is NOT a statement about free markets and ought not be mixed in here.
This is a statement about finite universes and companies that have gotten so
big that they threaten to own the entire space. In an infinitely large
space, where you know you can't possibly suppress all the competition, you are
not motivated to try. In a space where competition can come in many forms,
you must arm yourself against things, not try to suppress the competition.
This is an upper-bound effect that occurs when the market is finite and it has
specific solutions special to it, but is not about "free markets". I'm not
even going to discuss this further if it degrades to an I-hate-Microsoft fest.
I have as much reason to dislike Microsoft as anyone, but the fact is that
Microsoft's big problem is just that it is (a) "too big" ["trivially" fixed by
a population or court with the will to do so] and (b) has allegedly done other
illegal things ["trivially" fixed by punishing it appropriately using existing
laws already on the books].
> >> Even back in 1900, tests for chalk in milk were easy to perform, but that
> >> doesn't mean pure food laws were a bad idea....
> >
> >Nothing wrong with testing and labeling. But no reason it has to be done
> >by governments. Thing that are of no value will be naturally removed by
> >the market unless the person can't afford otherwise. And then it didn't
> >have no value.
>
> That's assuming minor details like no barriers to entry for competition, and
> no barriers to market exit for the consumer.
Cease and desist. This is already illegal.
> Oh, and no inducements for "independent" reviewers to slant their
> reports depending on who's buying ad space this year...
>
> >You're stuck at sea with no fresh water. You come upon a small island
> >with a river. You have no matches to boil the water. You (a) drink
> >it anyway, figuring it's better than sea water or (b) continue to drink
> >sea water waiting for a government health inspector to tell you that the
> >river water is safe?
>
> Someone else is on the island already, and says, "you can drink from the
> river, but my outhouse empties into it just below this spring I've roped
> off. So really, you'd better just promise to work for me in return for a
> ready supply of water that I promise I've boiled." It all depends on which
> analog you're willing to use.
He has no compulsion to sell me the water in any case. And present law gives
me a defense if I storm his house and take the water by force in order to
survive after he makes such a statement, I believe. If not a defense, at
least a mitigating circumstance. In any case, this is nto responsive to
the scenario I cited, which does occur. Once again it is singlemindedly
addressing a problem of improper single-individual control of
finite resources, which is not the property of a free market. Any free
market must reset when one person owns the market, or it is no longer free.
As a consequence, it must have controls on people buying too much of the
market.
> >I feel bad for people who have to live on the margin. But there are
> >many people in the world for whom the choice isn't "good food" or
> >nothing, it's "food of any kind" or nothing. You see them picking
> >through the dumpsters for half-eaten burgers all the time. How can
> >getting day-old bread from a bakery, even if the bakery doesn't have
> >the ability to test it or offer a warranty, be worse? Why should I have
> >to throw it in the trash in order to (pardon the pun) "legally launder" it
> >for them to eat?
>
> Oddly enough, bakeries do offer day-old bread. But once again, it's
> a question of analogy -- if the bakery mixed floor sweepings in with
> the old bread, and offered it up front rather than in the dumpster,
> you might be pretty annoyed with them for pretending to feed people
> when they're actually just trying to reduce their carting bill..
Depends on whether someone offered me better at a better price.
> >Software is the same thing. A lot of people want tools at cheap prices.
> >Enough that they'll routinely steal it. THey don't get a warranty that way
> >anyway--if they expose how they got it, they're in trouble.. Why is it worse
> >to allow someone to sell it with a partial warranty at a price they can
> >afford, making them non-criminals and offering money to someone who can maybe
> >give them what they want at a price they can afford? Whether they can
> >actually keep the customer base happy is something markets can sort out.
> >Maybe people will go back to stealing. If they do, the person offering the
> >low-priced item will go out of business. If not, then why should the
> >low-price/low-warranty item be disallowed?
>
> I'm not saying that the low-price low-warranty item should be disallowed,
> _as long as that's very explicitly what it is_. What we have now in the
> software biz is a large quantity of high-price low-warranty products, which
> look like high-warranty products until your sunk costs are high enough to
> discourage tossing them and going for replacement. And (Gresham's Law)
> those products, having higher margins and hence more money available for
> influencing purchasing decisions at all levels, tend to drive out not only
> high-priced, high-warranty items but also low-price, low-warranty ones.
It *is* explicitly what it is. When there is no warranty, there is no
warranty. Can you see how neatly isomorphic that is? When you say there
is a warranty but there is not, you end up creating the odd situation that if
you say a little warranty, you don't know if you have done so additively to
the warranty that was there with the null warranty or not. If ad money can
influence purchase decisions even over a warranty, the warranty was not,
by definition, important. The existence of the "pet rock" is not just a
victory of people with advertising dollars over people with good sense about
what pets need to be, it is an observation about what the core value of a pet
is.
> >Free markets work not at all if the consumer relies on the vendor to be
> >the one with all the brains.
>
> Free markets don't work in general (there are few if any unregulated markets)
The popularity of market regulation does not imply that regulation is
beneficial, just that it is politically successful.
> because one party (usually the seller) has access to far more information than
> the other, and acquiring equivalent information is either infeasible (trade
> secrets) or worth more than the cost of the transaction (most mass-market
> items including software and hardware). You can say "just don't do the
> transaction" then, but if a manufacturer's business plan requires (for
> sufficient volume) that the vast majority of its customers be uninformed,
> then the alternative to regulation would seem to be _per se_ fraud.
Not at all. Consumers who care can insist on whatever safeguards they
feel appropriate; suppliers who don't go along will have to do without
those customers. (Kosher food labelling is an existence proof.) Note
that the cost of these measures is unlikely to be higher than the costs
imposed by govt regulation, so .... (KMP has discussed how mandatory
universal regulation doesn't help the people who need it the most.)
BTW - I am confused how the manufacturer's biz plan is supposed to
drive my knowledge or my preferences. I've seen a number of biz plans
that "required" my participation, yet those folks failed because I
(and almost all of the rest of their target market) didn't behave
as "required". Am I doing something wrong? Do I owe them something?
-andy
··@panix.com (Paul Wallich) writes:
> In article <···············@world.std.com>, Kent M Pitman
> <······@world.std.com> wrote:
>
> >"Marcin Tustin" <·······@GUeswhatthisbitisfor.mindless.com> writes:
> >
> >> I'm sympathetic to this, but it goes a little too close to caveat emptor
> >> in a market where most purchasers totally unqualified and lacking in
> >> confidence.
> >
> >Anything other than "caveat emptor" breeds an audience of idiots.
> >
> >Free markets work not at all if the consumer relies on the vendor to be
> >the one with all the brains.
> Free markets don't work in general (there are few if any unregulated
> markets) because one party (usually the seller) has access to far
> more information than the other, and acquiring equivalent
> information is either infeasible (trade secrets) or worth more than
> the cost of the transaction (most mass-market items including
> software and hardware). You can say "just don't do the transaction"
> then, but if a manufacturer's business plan requires (for sufficient
> volume) that the vast majority of its customers be uninformed, then
> the alternative to regulation would seem to be _per se_ fraud.
> Even back in 1900, tests for chalk in milk were easy to perform, but
> that doesn't mean pure food laws were a bad idea....
It doesn't mean, by the same token, that "pure food laws" were a
necessity, either, or even necessarily useful.
Walkerton, Ontario got hit with a "pure water" problem where the fact
that the municpal government had a law, and even an administrator,
didn't help one bit. [The administrator was a political appointee
with a drinking problem who had no idea what "e coli" was.]
People died, despite the government having a law.
The notion of duality in Operations Research offers a fairly
meaningful way of looking at this; a law is a constraint, whilst
economic forces tend to provide "price function" effects.
Duality provides the insight that in a mathematical programming
formulation, there's always an alternative view of the problem where
the price components become contraints, and constraints are
transformed into prices. There's a really important sense in which
they _are_ equivalent; a constraint/law is equivalent to setting a
price, and vice-versa.
We see that industrial designs are often driven by the "constraints"
that insurance companies will not provide insurance unless systems
conform to their requirements. [This is especially true for fire
insurance...] It is by no means obvious that governments are
universally better at soliciting conformance with requirements than
are the private sector equivalents.
--
(reverse (concatenate 'string ········@" "enworbbc"))
http://vip.hyperusa.com/~cbbrowne/spreadsheets.html
Rules of the Evil Overlord #135. "My doomsday machine will have the
advanced technological device called a capacitor just in case someone
inconveniently pulls the plug at the last moment. (If I have access to
REALLY advanced technology, I will include the even better back-up
device known as the "battery.")" <http://www.eviloverlord.com/>
From: Ray Blaak
Subject: OT: walkerton (was Re: Engineering Envy [was: Re: CL and UML])
Date:
Message-ID: <uae2arqzk.fsf_-_@infomatch.com>
········@hex.net writes:
> Walkerton, Ontario got hit with a "pure water" problem where the fact
> that the municpal government had a law, and even an administrator,
> didn't help one bit. [The administrator was a political appointee
> with a drinking problem who had no idea what "e coli" was.]
There is some more context to this that sheds some light, however:
The government had cut its provincial water testers, pushing the testing to
the municipality. This is considered by many to be the root cause of the
problem.
So even with a law, one needs compentent people to ensure it is adhered to
properly.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@infomatch.com The Rhythm has my soul.
In article <···············@world.std.com>,
Kent M Pitman <······@world.std.com> wrote:
>
>I don't know. "Using an OS correctly" is remarkably hard to define.
>I'm willing to be a little forgiving on this point. I'd get out of the
>OS market if someone was going to hold me to a warranty like that.
>I *don't* mind the government making certain modifying terms that they
>regulate. Saying I market a "grade A safe" operating system, for example,
>where maybe the government monitors various grades of safety.
>But that shouldn't keep me from selling an "operating system", unqualified,
>to whomever might buy it and not care.
>
I can think of one consumer product right now that can have catastrophic
failures under normal use: the automobile. These things kill tens
of thousands of people each year in the US, and yet companies turn
them out by the millions and make a profit doing so.
If we as a society can make this possible, we can surely come up with
a way of warranting operating systems that doesn't scare away all
the good systems guys.
The government does have grounds for regulating stuff that can cause
physical injury or death if it fails, and enforcing assorted
restrictions on what a vendor can say about a product, and what
a purchaser is allowed to assume given what the vendor says.
The latter is very useful to allow consumers to make some kind
of informed decision. I can't think of government regulations that
prevent me from buying whatever junk I want for my own use. There
are market effects that will, since it's sometimes not worthwhile
to make junk just to sell it cheap.
(I have a friend who has a stamp for a mini-contract on the back of
his checks, saying that by accepting the check the vendor is warranting
that the product will have a certain mean time between failures, and
he has returned software successfully when it failed too often. I
don't know what would happen if this became common practice, rather
than one guy who it's cheaper to cooperate with than risk litigation.)
--
David H. Thornley | If you want my opinion, ask.
·····@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
········@visi.com (David Thornley) writes:
> I can think of one consumer product right now that can have catastrophic
> failures under normal use: the automobile. These things kill tens
> of thousands of people each year in the US, and yet companies turn
> them out by the millions and make a profit doing so.
>
> If we as a society can make this possible, we can surely come up with
> a way of warranting operating systems that doesn't scare away all
> the good systems guys.
>
> The government does have grounds for regulating stuff that can cause
> physical injury or death if it fails,
But software is more like "metal" than like "cars". It might be used for
something life-threatening or for something innocuous. Regulating all
uses of metal (e.g., so you had to have a license to put tin foil around
leftover food) is what I fear whenever anyone talks about implied warranties.
Sometimes covered leftover food goes bad, but people don't have a cause
of action against the tin foil companies.
> and enforcing assorted
> restrictions on what a vendor can say about a product, and what
> a purchaser is allowed to assume given what the vendor says.
There is a political division here. Can you not see it? Some of us think
it's the job of government to protect us from all evils. Some of us think
it's not even the job of government to know what we care about and what we
don't. Some of us want the government to tell us what to worry about.
I want the consumer to tell us. If the consumer does not care, why should
government. To quote (well, paraphrase--wish I had the exact quote) Jesse
Ventura--`Government should do for people only what they cannot do for
themselves.'
> The latter is very useful to allow consumers to make some kind
> of informed decision.
IF the consumer wants to pay for it. And otherwise NOT. If the restrictions
are not something I need or want to know, then the government regulation
merely raises the price needlessly.
> I can't think of government regulations that
> prevent me from buying whatever junk I want for my own use.
YES, ABSOLUTELY YOU CAN. People do decline to get involved in giving
out free stuff or selling low-cost stuff because of worry of the
liability issues. Just the other day, I had a conversation with a
friend about selling her birds (finches) at a yard sale. We concluded
she couldn't sell them for fear of warranty issues, and that she'd
just have to give them away, or, in the spirit of the free software
movement, make up the money by increasing the cost of the cage.
(sigh) They're finches. What kind of idiot would buy them thinking I
could warranty they'd live another day? God can't do that. Yet I had
to concede it was a reasonable concern just because laws are stupid on
this issue of warranty.
> There are market effects that will, since it's sometimes not worthwhile
> to make junk just to sell it cheap.
It's stupider than that. You can't give away things that might be
syntactically confused with toys for small kids any more without
worrying about liability. Suddenly it's not up to the parent, as it
once was, to keep the kid from bad things. Now it's up to each and
every producer of any kind of small plastic thing to see it's labeled
"not for kids". I wonder why we bother with such labeling, since in
the US we no loner educate the dumbed-down public to read, anyway.
And there was a certain Darwinian value in having kids that like to eat
marbles and choke on them get genetically screened out. At some point
that lack of screening is going to come home to haunt us too.
> (I have a friend who has a stamp for a mini-contract on the back of
> his checks, saying that by accepting the check the vendor is warranting
> that the product will have a certain mean time between failures, and
> he has returned software successfully when it failed too often. I
> don't know what would happen if this became common practice, rather
> than one guy who it's cheaper to cooperate with than risk litigation.)
Yeah, vendors do that kind of nonsense too--with switching phone
services by offering checks that have that stupidity on the back. I
think a good lawyer could probably beat those stupid back-of-check
contracts, though I'm sure no one is motivated to try. Proves nothing.
A proper contract is one that involves a meeting of the minds, not a snuck
in bit of wording. People in the US these days often want to have
the convenience of having the government decide everything for them, not
realizing the resulting financial cost. If they saw the cost itemized,
they might think twice.
- - - - -
To bring this back at least a little to the computer forum, if not to the
lisp forum, contracts will one day probably work electronically. It will
be VERY BAD if the thing we have to code up is not a nice simple additive
list of agreements starting from zero and adding constraints each for
a price, but instead starts with a set of defaults agreements that have to
be laboriously and unreliably whittled away to get back to an acceptable
base from which business can be done. Monotonicity has its place, and
government is not an exercise in that. I'd hate to have to reliably
program that contract system, and no doubt I'll end up having not only
to do it but to have it covered by some implied warranty. Ugh.
Kent M Pitman <······@world.std.com> writes:
> And there was a certain Darwinian value in having kids that like to
> eat marbles and choke on them get genetically screened out. At some
> point that lack of screening is going to come home to haunt us too.
It is interesting how there is so much public "lipservice" to
Darwinism, whilst rejecting this sort of thing.
If Darwinism be real, then our societies should certainly _not_ be
putting such efforts into protecting the "weak." If it's all about
"survival of the fittest," then there should be fewer stairs, and more
ladders with pits underneath to catch the "less-than-fit."
--
(concatenate 'string "cbbrowne" ·@acm.org")
http://vip.hyperusa.com/~cbbrowne/spreadsheets.html
Rules of the Evil Overlord #86. "I will make sure that my doomsday
device is up to code and properly grounded."
<http://www.eviloverlord.com/>
········@hex.net writes:
> Kent M Pitman <······@world.std.com> writes:
> > And there was a certain Darwinian value in having kids that like to
> > eat marbles and choke on them get genetically screened out. At some
> > point that lack of screening is going to come home to haunt us too.
>
> It is interesting how there is so much public "lipservice" to
> Darwinism, whilst rejecting this sort of thing.
It's likely because we cannot reliably predict which genes will
actually survive going forward. Mother nature is not beholden to
aesthetics. For all we know, kids who eat marbles have a winning
trait when our sole food source becauses giant horse pills. I think
keeping the gene pool as diverse as possible is a good thing.
--
Craig Brozefsky <·····@red-bean.com>
http://www.red-bean.com/~craig
"Indifference is the dead weight of history." -- Antonio Gramsci
········@hex.net writes:
> Kent M Pitman <······@world.std.com> writes:
> > And there was a certain Darwinian value in having kids that like to
> > eat marbles and choke on them get genetically screened out. At some
> > point that lack of screening is going to come home to haunt us too.
>
> It is interesting how there is so much public "lipservice" to
> Darwinism, whilst rejecting this sort of thing.
>
> If Darwinism be real, then our societies should certainly _not_ be
> putting such efforts into protecting the "weak." If it's all about
> "survival of the fittest," then there should be fewer stairs, and more
> ladders with pits underneath to catch the "less-than-fit."
I didn't reply to kmp's post because I assumed it was a joke (I
laughed, anyway). But since cbbrowne seems to be taking it seriously,
here is what I thought:
It is a well established _fact_ that small children learn through
experimentation. (Actually, most unfossilised adults do this too.)
It is also a well established _fact_ that small children experience
the world through _all_ their senses, and that slobbering on small
objects is part of the way they learn about the world.
Tiny bits of plastic, glass and metal tend to be smoother (more easily
swallowed) than natural objects, like twigs, stones, and bones.
Probably all of the instinctual part of our (human) nature evolved
long before we had the smooth, artificial, child-strangulators in mass
production. Children who chew on little things are doing what they
are supposed to. If children didn't, the human race as a whole would
probably have much _poorer_ survival chances.
If we ever get close to building artificial intelligence (which I
doubt) it will probably have to learn things the way real
sentient beings do: through experimentation.
So what are you going to do when your multi-billion dollar infant
super-intelligence chokes on a marble? Sue the marble seller, of course!
Regards,
Peter
Ps. I think social darwinism is pretty thoroughly discredited as a
respectable scientific theory.
Peter Wood <··········@worldonline.dk> writes:
> ········@hex.net writes:
>
> > Kent M Pitman <······@world.std.com> writes:
> > > And there was a certain Darwinian value in having kids that like to
> > > eat marbles and choke on them get genetically screened out. At some
> > > point that lack of screening is going to come home to haunt us too.
> ...
> I didn't reply to kmp's post because I assumed it was a joke (I
> laughed, anyway).
It was both.
> But since cbbrowne seems to be taking it seriously,
> here is what I thought:
>
> It is a well established _fact_ that small children learn through
> experimentation. (Actually, most unfossilised adults do this too.)
You bet. But the question is simply one of responsibility: is it the
person who makes an item or is it the parent who leaves it laying in
reach? I claim this is for parents to worry about, not vendors.
A perfect example was the move to make medicine bottles kid-safe. Some
elderly had huge difficulties getting these open. Eventually the vendors
got smart and started marketing easy-open bottles because they finally
got it that some households have no kids. Of course, those easy-open
bottles are dangerous to kids. But how can you hold the bottle maker
liable? Not without putting an AI computer onboard with every bottle.
Ugh. What a stupid expense. The right decision at the right time.
And really--some kids don't get the hint about running in the street.
Do I want to see those kids run over? No. But do I want the driver
blamed? The car vendor? Again, no. If the kid is stupid and the parent
doesn't lock them up until they get smarter, I can't see putting liability
on everyone in society except the kid and the parent.
> If we ever get close to building artificial intelligence (which I
> doubt) it will probably have to learn things the way real
> sentient beings do: through experimentation.
>
> So what are you going to do when your multi-billion dollar infant
> super-intelligence chokes on a marble? Sue the marble seller, of course!
I hope THIS is finally a joke.
> Regards,
> Peter
>
> Ps. I think social darwinism is pretty thoroughly discredited as a
> respectable scientific theory.
Kent M Pitman wrote:
>
> Peter Wood <··········@worldonline.dk> writes:
[snip]
> > I didn't reply to kmp's post because I assumed it was a joke (I
> > laughed, anyway).
>
> It was both.
>
> > But since cbbrowne seems to be taking it seriously,
> > here is what I thought:
> >
> > It is a well established _fact_ that small children learn through
> > experimentation. (Actually, most unfossilised adults do this too.)
>
> You bet. But the question is simply one of responsibility: is it the
> person who makes an item or is it the parent who leaves it laying in
> reach? I claim this is for parents to worry about, not vendors.
>
This whole "responsibility" line has been a fun read, but it misses the fundamental point.
On this line of reasoning, programming is probably best compared to building cathedrals in the middle ages. It was all done with
craftsmen who needed calculus to do a good job. Unfortunately, calculus was not invented yet and therefore, there was no engineering
available.
But, people wanted churches. And so, the craftsmen crafted. Sometimes, cathedral ceilings collapsed.
Bizzare, but beautiful procedures like the famous "flying buttresses" evolved. However, beautiful, they represent the equivalent of
code patches. Not all cathedrals need them nor need them at the same places.
In short, the issue here is not really who gets to sue whom, but how society procedes when it does not, at some fundamental level, know
how to produce what is needed. Eveyone wants bug free code. I assert you can't really get it. But, we do get some interesting
software "cathedrals" with greater or lesser amounts of "buttresses" in them.
And, we can throw software stone masons in jail when their programs (vaults) collapse, but while that may satisfy someone's idea of
accountability, is it at some deep level (on the current state of the art) anything more than visiting random punishment (e.g.
scapegoating)?
Larry
>>>>> "ll" == Larry Loen <······@us.ibm.com> writes:
ll> In short, the issue here is not really who gets to sue whom, but
ll> how society procedes when it does not, at some fundamental
ll> level, know how to produce what is needed. Eveyone wants bug
ll> free code. I assert you can't really get it. But, we do get some
ll> interesting software "cathedrals" with greater or lesser amounts
ll> of "buttresses" in them.
in mass-market software (and software-intensive devices like PDAs and
cell phones) being bug free is apparently of low priority for users --
features and ease of use and the case's color are more important.
Otherwise people would use older, stabler versions rather than
"upgrading" all the time. They would also pay extra for ECC RAM.
As for "you can't get bug free code": some industries manage to obtain
very low rates of software faults, and deploy error detection,
recovery and masking techniques which make the system dependable even
in the presence of faults. Examples are nuclear control systems,
embedded code in aviation and rail systems. These sectors have very
strict certification authorities, which is one way for society to
protect itself against engineers' quest for novelty.
Even sectors where systems are less critical, like telecoms, use
techniques such as replication (either in hardware using machines like
the Tandem Himalaya, or in software), and periodic refreshing of RAM
to mask the effects of single event upsets (bitflips due to heavy ion
radiation).
So techniques to build dependable systems do exist, and they work, but
they increase costs and development time substantially.
--
Eric Marsden <URL:http://www.laas.fr/~emarsden/>
Eric Marsden wrote:
[snip description of how to certify important software systems]
>
> So techniques to build dependable systems do exist, and they work, but
> they increase costs and development time substantially.
>
>
I think we're in violent agreement here. I am not all that sanguine about the magic word "certification" (a word you used that I snipped) but I agree
that you can always boost costs by doing more of the same of what we've always done (test-and-review), with procedures for doing it more thoroughly
and therefore more accurately. In another posting, I described the man spaced program code which has similar disciplines to those you described. In
the end, though, this is an argument about how many flying buttresses must be added to what kind of cathedral, not something more fundamental like
"finding a useful subset of all programs that can be provably bug free."
Larry
Larry Loen <······@rchland.vnet.ibm.com> writes:
> Eric Marsden wrote:
> [snip description of how to certify important software systems]
>
> > So techniques to build dependable systems do exist, and they work, but
> > they increase costs and development time substantially.
>
> I think we're in violent agreement here. I am not all that sanguine
> about the magic word "certification" (a word you used that I
> snipped) but I agree that you can always boost costs by doing more
> of the same of what we've always done (test-and-review), with
> procedures for doing it more thoroughly and therefore more
> accurately. In another posting, I described the man spaced program
> code which has similar disciplines to those you described. In the
> end, though, this is an argument about how many flying buttresses
> must be added to what kind of cathedral, not something more
> fundamental like "finding a useful subset of all programs that can
> be provably bug free."
The most robust computational device we know (the human brain) was acreted
over time without certification, and arguably could not have been done
otherwise.
I don't make this remark to be flip. Lisp is often cited for being "unsafe"
(with Java defining "safe"). Yet there are all kinds of task that people
routinely give up on as "too ahrd" in those "safe" languages which Lisp does
not give up on. I suggest that the space of "things people might ever
conceivably be willing to certify" is different in nature than the space of
things people would. In the rush for certification, making it required as
opposed to an option therefore, I think, very likely forces certain things
to never happen. That we cannot enumerate what those things are nor figure
out "when they don't happen" (as it were) does not mean it's not true.
Kent M Pitman <······@world.std.com> writes:
> I don't make this remark to be flip. Lisp is often cited for being
> "unsafe" (with Java defining "safe").
Um, I'm a little confused here. Which sense of "safe" are you
indicating here?
Two seem logical:
a) Lisp is not "safe" in that it might be hard to find staff to
support a Lisp-based system, where, in contrast, it's pretty easy to
throw a stone and cause several Java programmers to say "ow!"
This sense doesn't seem to be what you're applying, but does seem to
be a pretty legitimate risk.
b) Some sense of "system safety" whereby, due to GC and other "good
stuff," the system is relatively robust and won't need to be rebooted
very often.
.. And this sense seems rather more nonsensical, as Lisp systems have
similar properties, with the possible added merit that "LVMs"
(speaking _really_ loosely :-)) have a great deal more history and
maturity than "JVMs," and thus are likely to be more robust.
Or are you indicating some other sense of "safe" that I'm not
grasping? [Fairly possible...]
--
(concatenate 'string "cbbrowne" ·@acm.org")
http://vip.hex.net/~cbbrowne/
For example, if errors are detected in one of the disk drives, the system
will allow read-only access to memory until the problem is resolved. This,
PE claimed, prohibits a damaged disk drive from entering errors into the
system.
-- Computerworld 8 Nov 82 page 4.
<········@hex.net> wrote in message
····························@news20.bellglobal.com...
> Kent M Pitman <······@world.std.com> writes:
> > I don't make this remark to be flip. Lisp is often cited for being
> > "unsafe" (with Java defining "safe").
>
> Um, I'm a little confused here. Which sense of "safe" are you
> indicating here?
>
> Two seem logical:
>
> a) Lisp is not "safe" in that it might be hard to find staff to
> support a Lisp-based system, where, in contrast, it's pretty easy to
> throw a stone and cause several Java programmers to say "ow!"
>
> This sense doesn't seem to be what you're applying, but does seem to
> be a pretty legitimate risk.
>
> b) Some sense of "system safety" whereby, due to GC and other "good
> stuff," the system is relatively robust and won't need to be rebooted
> very often.
>
> .. And this sense seems rather more nonsensical, as Lisp systems have
> similar properties, with the possible added merit that "LVMs"
> (speaking _really_ loosely :-)) have a great deal more history and
> maturity than "JVMs," and thus are likely to be more robust.
>
> Or are you indicating some other sense of "safe" that I'm not
> grasping? [Fairly possible...]
I suspect he means "safe" in the sense "is java", or possibly "Has a
large marketing budget". Java does have extra safety features, like security
managers, which do add a certain amount of safety when running applets, but
this is the only thing I can think of that java actually has that Lisp
doesn't.
From: Tim Bradshaw
Subject: Re: Engineering Envy [was: Re: CL and UML]
Date:
Message-ID: <ey3ofqn7sb8.fsf@cley.com>
* cbbrowne wrote:
> b) Some sense of "system safety" whereby, due to GC and other "good
> stuff," the system is relatively robust and won't need to be rebooted
> very often.
The other notion of safe that I often come across is the type-safe
one. `If this system gets through the compiler then it will have no
runtime type errors'. ML people are beloved of this, but C/C++ people
also come out with it. Not sure about Java.
--tim
Tim Bradshaw <···@cley.com> wrote in message news:<···············@cley.com>...
> The other notion of safe that I often come across is the type-safe
> one. `If this system gets through the compiler then it will have no
> runtime type errors'. ML people are beloved of this, but C/C++ people
> also come out with it. Not sure about Java.
It seems strange to say that C is type-safe because it cannot have
run-time type errors. It is true, of course, but only in the trivial/
by definition sense, as C does not do run-time type checking.
However, it is false in the useful sense because C programs can have type
errors in them, type errors that are not ever detected as such. (A program
may crash or otherwise misbehave as a result of a type error, but C won't
let you know about the type error, let alone the connection between the
error and the misbehavior.)
-andy
From: Tim Bradshaw
Subject: Re: Engineering Envy [was: Re: CL and UML]
Date:
Message-ID: <ey3k8197whl.fsf@cley.com>
* Andy Freeman wrote:
> It seems strange to say that C is type-safe because it cannot have
> run-time type errors. It is true, of course, but only in the trivial/
> by definition sense, as C does not do run-time type checking.
Well I think that depends on your definition of error. I'd argue that
C can have run-time type errors but they are not detected. This is
quibbling over semantics.
I agree that it's kind of odd to hear C/C++ people coming out with the
type-safety thing, but I've heard it.
--tim
Tim Bradshaw <···@cley.com> writes:
> * Andy Freeman wrote:
> > It seems strange to say that C is type-safe because it cannot have
> > run-time type errors. It is true, of course, but only in the trivial/
> > by definition sense, as C does not do run-time type checking.
>
> Well I think that depends on your definition of error. I'd argue that
> C can have run-time type errors but they are not detected.
In the terminology of my paper on condition systems, we say that an error
"situation" has occurred but that not all situations are detected
nor are all situations that are detected represented (as conditions)
or signaled (invoking the handling mechanism).
> This is quibbling over semantics.
People often use this phrase, but I claim this is not "semantics".
Semantics is the behavior you are trying to describe, and which must be
held constant while you search for terminology to describe that fixed thing.
Of course, this is quibbling over meta-... uh, nevermind.
Tim Bradshaw <···@cley.com> wrote in message news:<···············@cley.com>...
> * Andy Freeman wrote:
> > It seems strange to say that C is type-safe because it cannot have
> > run-time type errors. It is true, of course, but only in the trivial/
> > by definition sense, as C does not do run-time type checking.
>
> Well I think that depends on your definition of error. I'd argue that
> C can have run-time type errors but they are not detected. This is
> quibbling over semantics.
I suppose that one could define a meaning/semantics for "type-safe" that
allows C's behavior, but .... If C can have undetected type errors, at
run-time, on tuesday, whenever, in what sense is it "type-safe"?
I'm not sophisticated in such matters, so I don't see how that passes
the giggle test.
> I agree that it's kind of odd to hear C/C++ people coming out with the
> type-safety thing, but I've heard it.
Well, it's probably not the most erroneous thing they've said.
-andy
From: Tim Bradshaw
Subject: Re: Engineering Envy [was: Re: CL and UML]
Date:
Message-ID: <ey3lmlog6hq.fsf@cley.com>
* Andy Freeman wrote:
> I suppose that one could define a meaning/semantics for "type-safe" that
> allows C's behavior, but .... If C can have undetected type errors, at
> run-time, on tuesday, whenever, in what sense is it "type-safe"?
I may have been confus(ed,ing): I don't think C is type-safe!
--tim
Tim Bradshaw wrote:
>
> * cbbrowne wrote:
>
> > b) Some sense of "system safety" whereby, due to GC and other "good
> > stuff," the system is relatively robust and won't need to be rebooted
> > very often.
>
> The other notion of safe that I often come across is the type-safe
> one. `If this system gets through the compiler then it will have no
> runtime type errors'. ML people are beloved of this, but C/C++ people
> also come out with it. Not sure about Java.
>
> --tim
Java is pretty strong on type safety. It might be what the author had in mind. Also, Java has a very clever and fairly explicit
notion of exception handing/error handling built-in. It does so without being absolutist about it (some exceptions have to be
monitored for "no matter what" and others you can optionally monitor for; they got the mix about right).
If Lisp has either of these, this newbie missed it. And no, I don't mean "recover in the debugger" when I mean exception handling ;-).
Larry
On Sun, 15 Jul 2001, Larry Loen wrote:
> Java is pretty strong on type safety. It might be what the author had in mind. Also, Java has a very clever and fairly explicit
> notion of exception handing/error handling built-in. It does so without being absolutist about it (some exceptions have to be
> monitored for "no matter what" and others you can optionally monitor for; they got the mix about right).
>
> If Lisp has either of these, this newbie missed it. And no, I don't mean "recover in the debugger" when I mean exception handling ;-).
>
I'd say you missed it :) While Lisp does not have strong compile-time
type safety (in general; at least one implementation, CMUCL, does do a
great deal of compile-time type checking and inference), its run time type
safety is in a sense absolute. Except perhaps at some speed/safety
settings, you can't mistakenly confuse one type for another.
As far as exception handling goes, I refer you the "The Condition System"
portion of the Hyperspec,
http://www.xanalys.com/software_tools/reference/HyperSpec/Body/chap-9.html.
Tim
Larry Loen <······@us.ibm.com> writes:
> Tim Bradshaw wrote:
> >
> > * cbbrowne wrote:
> >
> > > b) Some sense of "system safety" whereby, due to GC and other "good
> > > stuff," the system is relatively robust and won't need to be rebooted
> > > very often.
> >
> > The other notion of safe that I often come across is the type-safe
> > one. `If this system gets through the compiler then it will have no
> > runtime type errors'. ML people are beloved of this, but C/C++ people
> > also come out with it. Not sure about Java.
> >
> > --tim
>
> Java is pretty strong on type safety. It might be what the author
> had in mind.
> Also, Java has a very clever and fairly explicit notion of exception
> handing/error handling built-in. It does so without being
> absolutist about it (some exceptions have to be monitored for "no
> matter what" and others you can optionally monitor for; they got the
> mix about right).
>
> If Lisp has either of these, this newbie missed it. And no, I don't
> mean "recover in the debugger" when I mean exception handling ;-).
With regard to your second paragraph, I think you did miss something.
CL calls these "conditions", not "exceptions", maybe that's how it went
by you.
The designers of Java were quite familiar with the Common Lisp condition
system and seem to have based the parts of the condition system they made
on a subset of CL's--an impoverished subset if you ask me. Some MAJOR
pieces of CL's condition (i.e., exception) handling functionality are
absent in Java.
The only thing Java has that Lisp does not, and it's of questionable
value (meaning some people like it and some people hate it) is the
notion of the exception being part of the type signature. As someone
who has spent his career studying exception handling, I have to say I
think it is not something I want and it is not an accident that it's
not in CL. We could, if we as a community wanted it, make such a
thing. However, if we did, I'd be the first one out of the door of
this community to form a competing community where it was not so.
Kent M Pitman <······@world.std.com> wrote in message
····················@world.std.com...
> The only thing Java has that Lisp does not, and it's of questionable
> value (meaning some people like it and some people hate it) is the
> notion of the exception being part of the type signature. As someone
> who has spent his career studying exception handling, I have to say I
> think it is not something I want and it is not an accident that it's
> not in CL. We could, if we as a community wanted it, make such a
> thing. However, if we did, I'd be the first one out of the door of
> this community to form a competing community where it was not so.
I remember, but not precisely, many cases where it has annoyed me;
considering it abstractly, it seems like a good idea (Compiler able to tell
you about what errors may be signalled where). I should be able to say
exactly where it is annoying, given that I have about 9 months to do my Java
Certification. Oh dear.
"Marcin Tustin" <·······@GUeswhatthisbitisfor.mindless.com> writes:
> Kent M Pitman <······@world.std.com> wrote in message
> ····················@world.std.com...
>
> > The only thing Java has that Lisp does not, and it's of questionable
> > value (meaning some people like it and some people hate it) is the
> > notion of the exception being part of the type signature. As someone
> > who has spent his career studying exception handling, I have to say I
> > think it is not something I want and it is not an accident that it's
> > not in CL. We could, if we as a community wanted it, make such a
> > thing. However, if we did, I'd be the first one out of the door of
> > this community to form a competing community where it was not so.
>
> I remember, but not precisely, many cases where it has annoyed me;
> considering it abstractly, it seems like a good idea (Compiler able to tell
> you about what errors may be signalled where). I should be able to say
> exactly where it is annoying, given that I have about 9 months to do my Java
> Certification. Oh dear.
Where Java is annoying or where CL is?
One place it is definitely more annoying than I can bear in Java is where
you have
try { bar(x) }
catch (FooException e)
but you need to debug a clause in bar that signals FooException so you
momentarily comment out the signal. That results in the need to edit every
try that surrounds because it's considered a signature mismatch if
you handle too MANY exceptions. You can't just leave it there harmlessly
as unreachable code.
Kent M Pitman <······@world.std.com> wrote in message
····················@world.std.com...
> Where Java is annoying or where CL is?
Java
> try { bar(x) }
> catch (FooException e)
>
> but you need to debug a clause in bar that signals FooException so you
> momentarily comment out the signal. That results in the need to edit
every
> try that surrounds because it's considered a signature mismatch if
> you handle too MANY exceptions. You can't just leave it there harmlessly
> as unreachable code.
True, but you can still declare to throw an exception you don't, eg
public class Foo
{
void bar() throws IndexOutOfBoundsException
{}
}
class Baz extends Foo
{
void bar()
{}
void Qux()
{
try{super.bar();}
catch(IndexOutOfBoundsException e){}
}
}
········@hex.net writes:
> Kent M Pitman <······@world.std.com> writes:
> > I don't make this remark to be flip. Lisp is often cited for being
> > "unsafe" (with Java defining "safe").
>
> Or are you indicating some other sense of "safe" that I'm not
> grasping? [Fairly possible...]
- Lisp is dynamically typed, Java is statically typed.
- Java methods must declare all the exceptions they throw. You can look
at the source for a method and say whether it will run to
completion.
- The java compiler will look up all your class and method invocations
at compile time and complain if it can't find something: no runtime
errors from misspelling method names
- The java compiler works on files, so you always know that your
output corresponds to the sources you have: contrast Lisp where you
can define functions at the repl and dump a core, to deliver an
application that doesn't correspond to the lisp files it was
allegedly built from.
Just a few of java's more annoying features. I guess I have the
artistic temperament even if I don't qualify as an artist ...
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Daniel Barlow <···@telent.net> writes:
> - The java compiler will look up all your class and method invocations
> at compile time and complain if it can't find something: no runtime
> errors from misspelling method names
Right. A subtle but important implication of this is that it can never be
surprised. That doesn't mean the world can't contain surprises. It just
means you can't write programs that accomodate surprises without shoehorning
them into existing types.
Lisp code written for a certain set of types can meaningfully accept new types
and either (a) code to deal with those types dynamically added as well or
(b) can reflectively run code that might add appropriate handlers itself.
I think the Java people think that's bad. I guess it's wonderful if
you can idealize your universe in such a way and get away with it...
Personally, I prefer not to idealize the world. I like to confront the way
it really is. Saves continually rewriting and recompiling.
Larry Loen <······@us.ibm.com> writes:
> On this line of reasoning, programming is probably best compared to
> building cathedrals in the middle ages. It was all done with
> craftsmen who needed calculus to do a good job. Unfortunately,
> calculus was not invented yet and therefore, there was no
> engineering available.
>
> But, people wanted churches. And so, the craftsmen crafted.
> Sometimes, cathedral ceilings collapsed.
This is a side-track from the original thread, I guess..
Interestingly, there are speculations that there existed a "science" of
cathedral construction, among the few initiated masters, now lost.
I find there's a nice analogy between architectural concepts like Ad
Quadratum and Ad Triangulum, and lisp's sexpr syntax: Using very
simple ("god-given", more or less) abstract concepts as the basis for
constructing huge, complex, aesthetically pleasing things.
BTW Richard Gabriel talks quite a bit about the similarities between
architecture and programming in his book.
--
Frode Vatvedt Fjeld
On 12 Jul 2001, Frode Vatvedt Fjeld wrote:
> BTW Richard Gabriel talks quite a bit about the similarities between
> architecture and programming in his book.
Plus, it has the added bonus of lots of juicy gossip about Lucid!
Tim
From: Tim Bradshaw
Subject: Re: Engineering Envy [was: Re: CL and UML]
Date:
Message-ID: <ey3k81e7ydx.fsf@cley.com>
* Larry Loen wrote:
> In short, the issue here is not really who gets to sue whom, but how
> society procedes when it does not, at some fundamental level, know
> how to produce what is needed. Eveyone wants bug free code. I
> assert you can't really get it. But, we do get some interesting
> software "cathedrals" with greater or lesser amounts of "buttresses"
> in them.
I think this is a really good point. It's hard to base a whole
guarantee-of-merchantability framework around something that no-one
knows how to do, and which might just be intractably difficult. That
would be like suing people because steel table knives rusted before
stainless-steel was discovered.
--tim
Peter Wood <··········@worldonline.dk> writes:
> ········@hex.net writes:
>
[...]
> It is a well established _fact_ that small children learn through
> experimentation. (Actually, most unfossilised adults do this too.)
>
Yes. And the hacker ethic as presented in _Hackers_ (by Steven Levy)
includes the sentence ``Always yield to the Hands-On Imperative!'' (on
page 40).
> It is also a well established _fact_ that small children experience
> the world through _all_ their senses, and that slobbering on small
> objects is part of the way they learn about the world.
>
> Tiny bits of plastic, glass and metal tend to be smoother (more easily
> swallowed) than natural objects, like twigs, stones, and bones.
> Probably all of the instinctual part of our (human) nature evolved
> long before we had the smooth, artificial, child-strangulators in mass
> production. Children who chew on little things are doing what they
> are supposed to. If children didn't, the human race as a whole would
> probably have much _poorer_ survival chances.
>
(this section is a joke, just so no one replies seriously to it)
<joke>
Well, before plastic, metal, and glass, there were *mostly* only
twigs, stones, and bones. But what about areas near rivers and oceans?
Pebbles found in an ocean or river are often very smooth, and
marble-like. So before plastic, etc, children that lived near moving
water had a higher rate of death from choking. That gets rid of the
children who are too stupid to chew on dirty sticks and bones instead
of clean pebbles. It's proof that Darwinism is true: look at the
percentage of population in the US that lives near the coast! ;)
</joke>
> If we ever get close to building artificial intelligence (which I
> doubt) it will probably have to learn things the way real
> sentient beings do: through experimentation.
>
> So what are you going to do when your multi-billion dollar infant
> super-intelligence chokes on a marble? Sue the marble seller, of course!
>
No, they would file a bug report and add an option to make it chew on
sticks.
> Regards,
> Peter
>
> Ps. I think social darwinism is pretty thoroughly discredited as a
> respectable scientific theory.
>
Indeed. Consider that the Holocaust indirectly resulted from
Darwinism. Blindly supporting Darwinism without carefully considering
billions of equally important factors is madness. However, we do not
yet know whether or not Darwinism is true when all factors are
considered, as that is a matter of empirical evidence.
--
BPT <···@hobbiton.org>
backronym for Linux: Linux Is Not Unix
<········@hex.net> wrote in message
····························@news20.bellglobal.com...
> It is interesting how there is so much public "lipservice" to
> Darwinism, whilst rejecting this sort of thing.
>
> If Darwinism be real, then our societies should certainly _not_ be
> putting such efforts into protecting the "weak." If it's all about
> "survival of the fittest," then there should be fewer stairs, and more
> ladders with pits underneath to catch the "less-than-fit."
Why? This has just shown that those whose genetic line could not be
guaranteed to generate descendants who could avoid doing stupid things have
found a way to preserve their genes. Pressures come in other forms, like
selecting for those who tend to be Religious, or incapable of
understanding contraception.
In article <·······················@news20.bellglobal.com>, cbbrowne
wrote:
> If Darwinism be real, then our societies should certainly _not_ be
> putting such efforts into protecting the "weak." If it's all about
> "survival of the fittest," then there should be fewer stairs, and more
> ladders with pits underneath to catch the "less-than-fit."
Darwinism needs diversity to work. Since the 'weak' today may be
the fitter of tommorow, protecting the weak does make sense from
the Darwinian point of view.
On Wed, 11 Jul 2001 15:27:04 GMT,
cbbrowne <········@hex.net> wrote:
> If Darwinism be real, then our societies should certainly _not_ be putting
> such efforts into protecting the "weak."
What utter bollocks. Societies, arising from us being social animals,
ultimately do whatever is in our genes, namely (to some extent) protecting
the weak. The 'social genes' must have proven useful in the ape lineage, and
comes with more benefits than the drawbacks of 'wasting' energy on 'the weak'
as well as furthering the occasional 'less fit' genes.
I hope you're not implying that you can determine from Darwinism what you, or
societies _should_ do. That is a complete fallacy, responsible for much of
the discrediting of Darwinism.
The human race^Wspecies is not bound solely by strict biological/genetical
selection; culture (read: science, technology, knowledge) is now a big part
of our survival. This part is intimately tied with this thing called society
(the existence of which was denied by Thatcher et al.), so telling society
'what to do' is not 'second-guessing' Darwinism, but just another form of
varation that will be selected upon. And that is just one reason why
Darwinism cannot ever be normative.
Philip
--
If you have a procedure with 10 parameters, you probably missed some. (Kraulis)
-----------------------------------------------------------------------------
Philip Lijnzaad, ········@ebi.ac.uk \ European Bioinformatics Institute,rm A2-08
+44 (0)1223 49 4639 / Wellcome Trust Genome Campus, Hinxton
+44 (0)1223 49 4468 (fax) \ Cambridgeshire CB10 1SD, GREAT BRITAIN
On 12 Jul 2001 09:29:39 +0100, Philip Lijnzaad <········@ebi.ac.uk> wrote:
>What utter bollocks. Societies, arising from us being social animals,
>ultimately do whatever is in our genes, namely (to some extent) protecting
>the weak. The 'social genes' must have proven useful in the ape lineage, and
>comes with more benefits than the drawbacks of 'wasting' energy on 'the weak'
>as well as furthering the occasional 'less fit' genes.
>
>I hope you're not implying that you can determine from Darwinism what you, or
>societies _should_ do. That is a complete fallacy, responsible for much of
>the discrediting of Darwinism.
What is also responisble for the discrediting
of Darwinism are the countless idiotic things
Darwinists say on a routine basis. Magisterial
pronouncements like "[societies] ultimately do
whatever is in our genes" confidently repeated
as if they mean something.
--
Don't think you are. Know you are.
In article <···············@world.std.com>,
Kent M Pitman <······@world.std.com> wrote:
>········@visi.com (David Thornley) writes:
>
>> The government does have grounds for regulating stuff that can cause
>> physical injury or death if it fails,
>
>But software is more like "metal" than like "cars". It might be used for
>something life-threatening or for something innocuous.
Right. There are uses of software that are potentially life-threatening
and a good deal more that aren't (I believe that the majority of
computrons in the world are devoted to games and word processing).
It is possible for regulations to affect only life-threatening
uses. There are different laws about what you can drive on your
own property than what you can drive on the city streets, for
example.
Regulating all
>uses of metal (e.g., so you had to have a license to put tin foil around
>leftover food) is what I fear whenever anyone talks about implied warranties.
>Sometimes covered leftover food goes bad, but people don't have a cause
>of action against the tin foil companies.
>
Of course, if Alcoa had a manufacturing process that left botulism
spores on the foil, that would be worthy of a lawsuit. (Is there
such a thing as a botulism spore?) Aluminum foil probably carries
an implied warranty that it is itself safe for use with food
unless labelled otherwise.
>> and enforcing assorted
>> restrictions on what a vendor can say about a product, and what
>> a purchaser is allowed to assume given what the vendor says.
>
>There is a political division here. Can you not see it? Some of us think
>it's the job of government to protect us from all evils. Some of us think
>it's not even the job of government to know what we care about and what we
>don't. Some of us want the government to tell us what to worry about.
>I want the consumer to tell us. If the consumer does not care, why should
>government. To quote (well, paraphrase--wish I had the exact quote) Jesse
>Ventura--`Government should do for people only what they cannot do for
>themselves.'
>
Right. What is it I cannot do for myself?
I can make informed choices, but I need some sort of reliable
information to make them. If I can't trust anything a manufacturer
says, I can't make an informed choice. Suppose I order a computer
over the web, given a description, and am then sent a sack of
potatos. Should this be allowed? If you remove any legal reason
for a manufacturer to be truthful, and remove any implied warranties
of merchantibility (or whatever that is), what's to stop the
computer vendor from doing that?
(BTW, I saw a major vendor's web site whose legal disclaimer
seemed to imply they could in fact send me a sack of potatos
instead of a computer if I ordered a computer. Don't remember
who it was anymore.)
This hurts the truthful companies as well as the liars. If I
buy a $1500 sack of potatos once, I'm not likely to trust a
computer vendor again.
On a more mundane level, I can't test every food item I buy for
wholesomeness before I buy it. I have to assume that it is
indeed suitable for human consumption. I can't conduct a stress
test on a hammer or stereo before buying it. I just have to
believe some of what I am told.
>> The latter is very useful to allow consumers to make some kind
>> of informed decision.
>
>IF the consumer wants to pay for it. And otherwise NOT. If the restrictions
>are not something I need or want to know, then the government regulation
>merely raises the price needlessly.
>
Well, what if they're for things somebody else needs to know? I know
people with deadly allergies, and they need to know ahead of time what's
in the food they buy. Most of the labels I see are either the
manufacturer or vendor voluntarily telling me information I might
need (and if nobody insists that it isn't outright lies I can't
rely on that) or labels required because reasonably large numbers
of people want or need to know the stuff.
You may not have any serious food allergies or dislikes, and find
that information you're not interested in is required to be on food.
Government doesn't just exist for your benefit, or my benefit, but
theoretically for everybody's benefit.
>> I can't think of government regulations that
>> prevent me from buying whatever junk I want for my own use.
>
>YES, ABSOLUTELY YOU CAN.
Nope.
People do decline to get involved in giving
>out free stuff or selling low-cost stuff because of worry of the
>liability issues.
Some do. Does the government force that?
Just the other day, I had a conversation with a
>friend about selling her birds (finches) at a yard sale. We concluded
>she couldn't sell them for fear of warranty issues, and that she'd
>just have to give them away, or, in the spirit of the free software
>movement, make up the money by increasing the cost of the cage.
Are either your friend or you learned in the law? Do I have a good
reason to think your friend would have a liability issue? I've bought
and sold lots of things on an as-is basis. I usually won't pay as
much for something sold as-is than for something with some sort of
warranty, but that's a market effect.
>(sigh) They're finches. What kind of idiot would buy them thinking I
>could warranty they'd live another day? God can't do that. Yet I had
>to concede it was a reasonable concern just because laws are stupid on
>this issue of warranty.
>
Or you're being overcautious. If you could cite some examples of people
etting into serious legal trouble for selling finches, I'd be more
impressed.
>> There are market effects that will, since it's sometimes not worthwhile
>> to make junk just to sell it cheap.
>
>It's stupider than that. You can't give away things that might be
>syntactically confused with toys for small kids any more without
>worrying about liability.
You can't? I have bought a considerable number of dangerous toys
(Among other things, I play wargames with miniature figures) that
contain lead and are a potential choking hazard, and not noticed
warnings on the packages. Nor have I seen the suppliers of my favorite
1/300 scale WWII soldiers going out of business due to liability
issues.
Suddenly it's not up to the parent, as it
>once was, to keep the kid from bad things. Now it's up to each and
>every producer of any kind of small plastic thing to see it's labeled
>"not for kids".
My mother-in-law once bought a replica of an old-style toy for my
child. Once out of the box, it proved to have a considerable number
of sharp edges. Fortunately, the box had labelling saying it was
unsuitable for children; otherwise, we would have followed the
"looks like a toy" principle and given it to the kid.
>And there was a certain Darwinian value in having kids that like to eat
>marbles and choke on them get genetically screened out. At some point
>that lack of screening is going to come home to haunt us too.
>
Nah, there's enough genetic variety. In the meantime, we don't
know the genetic basis of a predisposition to choke on marbles.
It may be connected with curiosity, in which case killing the
marble-eating kids may be dumbing down the human race. Never
do genetic screening on something that doesn't really matter;
you don't know what else you're doing.
>> (I have a friend who has a stamp for a mini-contract on the back of
>> his checks, saying that by accepting the check the vendor is warranting
>
>Yeah, vendors do that kind of nonsense too--with switching phone
>services by offering checks that have that stupidity on the back. I
>think a good lawyer could probably beat those stupid back-of-check
>contracts, though I'm sure no one is motivated to try. Proves nothing.
>
I've opened up envelopes and had checks come out, always having some
sort of writing like that on the back. If they weren't legally
enforceable, you'd think word would get around and the sort of people
who do that would have to stop doing it.
>A proper contract is one that involves a meeting of the minds, not a snuck
>in bit of wording. People in the US these days often want to have
>the convenience of having the government decide everything for them, not
>realizing the resulting financial cost. If they saw the cost itemized,
>they might think twice.
>
Every example you've brought up that I consider credible is not a
decision made for the people, but some sort of way of allowing the
consumer to make better decisions themselves. The consumer gets
to trust some of what the vendor says, is informed of potentially
serious conditions, can assume that he or she is getting something
more or less suitable for the purpose sold for, that sort of thing.
>To bring this back at least a little to the computer forum, if not to the
>lisp forum, contracts will one day probably work electronically. It will
>be VERY BAD if the thing we have to code up is not a nice simple additive
>list of agreements starting from zero and adding constraints each for
>a price, but instead starts with a set of defaults agreements that have to
>be laboriously and unreliably whittled away to get back to an acceptable
>base from which business can be done.
OK, wanna buy some potatos^H^H^H^H^H^H^Hcomputers from me? If the
contract starts with nothing, and you buy my catalog item XFG-348,
and neglect to type into the contract that it has to be a computer
(or you do, which annoys me - it's easier to buy potatos than
abaci), I've got $1500 and you've got potatos?
It seems to me that starting with some default agreements has a
great deal of advantages. They shouldn't be fancy, and in practice
they aren't. Right now, it's that the vendor hasn't lied too much,
and anyway not in writing, and that the item sold is vaguely
suitable for the purpose it is sold for (not necessarily the
purpose it is bought for). Seems reasonable to me.
>government is not an exercise in that. I'd hate to have to reliably
>program that contract system, and no doubt I'll end up having not only
>to do it but to have it covered by some implied warranty. Ugh.
In any application that has a list, it's really not that hard to
put some default elements in that list. The hard part is in
maintaining the list along with prices. Besides, if you're going
to offer any warranty, it will include merchantability and fitness
and some indication that your claims about it are to be taken
seriously. (Unless, like almost all vendors, you warrant that
you are providing a CD-ROM, and include lots of restrictions
on what I can and cannot do if there happens to be any software
on it.)
--
David H. Thornley | If you want my opinion, ask.
·····@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
········@visi.com (David Thornley) writes:
> Of course, if Alcoa had a manufacturing process that left botulism
> spores on the foil, that would be worthy of a lawsuit.
IF they marketed it as kitchen wrap. NOT by virtue of its being rolled
aluminum (unless it's contagious to the touch, which is a different matter
because it's an active, not passive threat).
> (Is there
> such a thing as a botulism spore?) Aluminum foil probably carries
> an implied warranty that it is itself safe for use with food
> unless labelled otherwise.
It happens to, but it needn't. If it didn't, we could solve this trivially
by just having "SAFE TO COVER FOOD" written on the box. I'd rather to see
that, actually. There are certainly things you can buy in the grocery store
that are ambiguous. Is dish soap edible? How rinsed must my dishes be? etc.
> >To quote (well, paraphrase--wish I had the exact quote) Jesse
> >Ventura--`Government should do for people only what they cannot do for
> >themselves.'
> >
> Right. What is it I cannot do for myself?
>
> I can make informed choices, but I need some sort of reliable
> information to make them.
A written warranty is such a source. Absent it, you can make reliable
decisions based on no information. e.g, I'd better not trust this since
no one has told me it's safe.
> If I can't trust anything a manufacturer says,
You absolutely can hold a manufacturer to what it says. The question is
whether you can hold it to what it has not said.
> ...If you remove any legal reason
> for a manufacturer to be truthful, and remove any implied warranties
> of merchantibility (or whatever that is),
Don't AND these together. They are different. I haven't eliminated the
need for a vendor to be truthful. I've advocated removal of the implication
that a vendor is untruthful when it doesn't make a claim and you want to
hold it to what claim you think it should have made that it has not.
> what's to stop the
> computer vendor from doing that?
[Not sure what the "that" was in this context.]
> (BTW, I saw a major vendor's web site whose legal disclaimer
> seemed to imply they could in fact send me a sack of potatos
> instead of a computer if I ordered a computer. Don't remember
> who it was anymore.)
My guess is that if it's a well-known company, it's safe to buy from,
warranty or not, because an established company would not risk its
expensive reputation to make a tiny income. By contrast, if it's a
company you never heard of, I'd break out the potato masher.
> This hurts the truthful companies as well as the liars. If I
> buy a $1500 sack of potatos once, I'm not likely to trust a
> computer vendor again.
I don't know why. The ones who deliver computers will gain reputation
and market share. It may be that the way they do that is by
explicitly saying "by the way, we'll send you a computer, not a sack
of potatoes". I don't think it's unduly onerous for them to need to
say that...
> On a more mundane level, I can't test every food item I buy for
> wholesomeness before I buy it.
The same could be said for a banana found growing in the wild.
But bananas themselves have a reputation for being non-poisonous.
Of course, if the land around the area has a reputation for being
radioactive, maybe not. But so it goes.
A common debate error is to assume that under a hypothetical, everything
else in the world would remain the same, rather than everything having
adapted to the fact of the hypothetical. Reputation information would
become more important, as well it should. Trade claim information would
become more visible, as well it should. But don't claim that because
those things haven't happened in our world, they wouldn't happen in the
hypothetical.
> I have to assume that it is
> indeed suitable for human consumption. I can't conduct a stress
> test on a hammer or stereo before buying it. I just have to
> believe some of what I am told.
Reputation.
Contract.
Third-party auditing of process..
Implied warranty is no stronger than these. It's just a syntactic variation
that makes it painful to know what is implied and what's not because the true
nature of the offering is hidden from inspection.
Implied warranty may be dangerous by lulling the purchaser into assuming
ALL needs are covered, rather than just well-known default needs.
This is definitely bad.
I'm going to stop repling here. I feel like I'm repeating myself.
David Thornley <········@visi.com> wrote in message
···························@ruti.visi.com...
> Well, what if they're for things somebody else needs to know? I know
> people with deadly allergies, and they need to know ahead of time what's
> in the food they buy. Most of the labels I see are either the
> manufacturer or vendor voluntarily telling me information I might
> need (and if nobody insists that it isn't outright lies I can't
> rely on that) or labels required because reasonably large numbers
> of people want or need to know the stuff.
These days, everything in the UK (Practically), has "May contain nuts"
printed on it.
> Or you're being overcautious. If you could cite some examples of people
> etting into serious legal trouble for selling finches, I'd be more
> impressed.
I can cite at least one case in the US of microwave oven manufacturers
being sued for failing to print warnings on their against putting living
things inside, leading to the death of pets when their owners tried to dry
them. I think I've changed my mind - I'm going over to KMP's pov.
> >> There are market effects that will, since it's sometimes not worthwhile
> >> to make junk just to sell it cheap.
> >
> >It's stupider than that. You can't give away things that might be
> >syntactically confused with toys for small kids any more without
> >worrying about liability.
>
> You can't? I have bought a considerable number of dangerous toys
> (Among other things, I play wargames with miniature figures) that
> contain lead and are a potential choking hazard, and not noticed
> warnings on the packages. Nor have I seen the suppliers of my favorite
> 1/300 scale WWII soldiers going out of business due to liability
> issues.
Have you never seen plastic bags with "This is not a toy" printed on
them?
> Suddenly it's not up to the parent, as it
> >once was, to keep the kid from bad things. Now it's up to each and
> >every producer of any kind of small plastic thing to see it's labeled
> >"not for kids".
>
> My mother-in-law once bought a replica of an old-style toy for my
> child. Once out of the box, it proved to have a considerable number
> of sharp edges. Fortunately, the box had labelling saying it was
> unsuitable for children; otherwise, we would have followed the
> "looks like a toy" principle and given it to the kid.
>>>>> On Wed, 11 Jul 2001 20:34:07 +0100, Marcin Tustin ("Marcin") writes:
Marcin> These days, everything in the UK (Practically),
Marcin> has "May contain nuts" printed on it.
ISP subscription contracts?
Christopher Stacy <······@spacy.Boston.MA.US> writes:
> >>>>> On Wed, 11 Jul 2001 20:34:07 +0100, Marcin Tustin ("Marcin") writes:
> Marcin> These days, everything in the UK (Practically),
> Marcin> has "May contain nuts" printed on it.
>
> ISP subscription contracts?
If not, they should. The Internet is full of nuts.
On Thu, 12 Jul 2001 03:57:31 GMT, Kent M Pitman <······@world.std.com>
wrote:
> Christopher Stacy <······@spacy.Boston.MA.US> writes:
>
> > >>>>> On Wed, 11 Jul 2001 20:34:07 +0100, Marcin Tustin ("Marcin") writes:
> > Marcin> These days, everything in the UK (Practically),
> > Marcin> has "May contain nuts" printed on it.
> >
> > ISP subscription contracts?
>
> If not, they should. The Internet is full of nuts.
Some friends of mine without computer background are a bit surprised when I
tell them that email is not reliable, and that a fraction of the messages
get lost.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
Christopher Stacy <······@spacy.Boston.MA.US> wrote in message
··················@spacy.Boston.MA.US...
> >>>>> On Wed, 11 Jul 2001 20:34:07 +0100, Marcin Tustin ("Marcin") writes:
> Marcin> These days, everything in the UK (Practically),
> Marcin> has "May contain nuts" printed on it.
>
> ISP subscription contracts?
Yes.
;)
From: George Neuner
Subject: Re: Engineering Envy [was: Re: CL and UML]
Date:
Message-ID: <3b37c668.2250016702@helice>
On 25 Jun 2001 10:32:11 -0700, ······@earthlink.net (Andy Freeman)
wrote:
>
>We long ago figured out that end-to-end solutions are the ones that
>work, that intermediate ecc is merely a possible performance enhancer,
>so why the obsession with exposing these innards to someone past the
>end?
>
Duh! ... it provides more pockets for lawyers to fish in.
George
"Thomas A. Russ" wrote:
[snip]
>
> I think that this rather overstates the case.
>
> In physical engineering there are various levels of quality and
> certification. I can go to my local hardware store and buy some cheap
> screws. These work well on small repairs and home projects, but Boeing
> or Airbus Industries would not use the same parts in their aircraft.
> They are required to use appropriately certified parts.
>
> One could easily imagine a similar system for software. There are many
> general purpose libraries with no particular guarantee, as well as some
> others that have been appropriately certified. If you don't want to go
> through the effort to have your library certified, then it would seem
> that someone who uses it in preference to a certified library would be
> taking on the liability.
>
One could easily "imagine" such a system, but such a system does not exist. You have backed into assuming what I'm asking for exists
(easy to do on a long series of posts).
It is not so obvious that such a system _can_ exist, thanks to the robustness of the Halting and Debugging problems.
Part of the devil's bargain we've made with having software at all is that -- so far -- we have no method that says "here's how you get
rid of all the bugs" or even "here's how you prove there's only seven bugs left" and in the latter case, what it would mean in terms of
catastrophe avoidance.
Until we can do that, any discussion of "certification" is essentially alchemy.
> The US Food and Drug Administration has guidelines for evaluating
> software in life-critical medical devices. I'm not familiar with the
> details, but there are ways of making certain software adhere to more
> formal standards.
And oh how I wished they worked in provable ways.
I once got to attend an excellent lecture on how software for Manned Spaceflight was developed. This software was ten times more
expensive to produce than most code (today, probably more than ten fold) and had many checks, reviews, and rechecks. From a bug
removal point of view, one only had to stand and salute. They are really, really serious about quality, folks.
In the end, however, Neil Armstrong came within something like 100 bytes of stack space from having his computer reset in the middle of
his famous manual landing procedure, which would have had him crashing into the lunar surface. That it didn't was a triumph for the
coders. (That they knew is a triumph, too). However, that it got that close to failure is a cautionary tale.
All you can do, really, is test more and review code more. That's all we have, that's all we've ever had. "Certification" is not a
process, it is a continuum of the same methods that got us here. I'm looking for real progress, something new, not just "working what
we know a lot harder", especially if we call that "certification." When I read the word "certification" I expect something like
proof. It is probably true that "proof" is less true in other engineering disciplines than we might expect (especially because they,
too, use computers these days), but bridges collapse at a much lower rate than, say, Windows.
Larry
Jochen Schmidt <···@dataheaven.de> wrote in message
···················@ID-22205.news.dfncis.de...
> You're right - but it is a bit more difficult to do that with software. If
> Person A writes a little library that does nothing special but contains a
> bug and some other developer B uses (besides of much much more other parts
> this small library in the software of an aircraft - who should be
> responsible?
> I'm rather sure you'll now say A is responsible because he caused the bug,
> but this means that you have to do _all_ work as if you would code for an
> aircraft or a Space Shuttle because you never know if someone uses it
later
> for something like this.
Clearly, B is responsible for ensuring that he uses appropriate
components,
and that he tests his components (Either himself, or by paying for
components
which are guaranteed, and indemnify the purchaser).
Larry Loen wrote:
> I was told at a conference that a bill was introduced in Texas to make
> programmers no less liable than any other engineering
> discipline. Never heard if it passed, but we won't forever get to call
> ourselves "artists" whilst our products cause airplanes to fall out of the
> sky.
This is the classical misuse of the word "artist" - Being an "artist" does
not imply that what is produced is good or better than others. The
artist-metaphor for programmers was not chosen because programmers
produce so beautiful things but because programming is sometimes a similar
fuzzy discipline like Art (authoring, composing...) that demands similar
capabilities (abstraction, creativity...)
ciao,
Jochen
> No civil engineer would say "the bridge is the design" and tell you (and
> often distainfully at that) to reconstruct its design girder by girder.
Tim Bradshaw wrote half of my response to this.
The other half is that "real engineers" have a useful design representation,
a representation that is not the artifact. For bridge designers, that
representation is a set of blueprints. They can analyse this representation
and extract almost any useful information.
I suspect that "not the artifact" is important.
In addition, bridges (and their components) are static.
Plus, we don't blame their designers for certain consequences. (No
one blames road designers for allowing the Nazis into Czechoslovakia.)
Note that we're just getting to the point where blueprints can be mechanically
transformed into objects.
-andy
* Larry Loen wrote:
> However, if we computer scientists want to be taken seriously as an
> engineering discipline, we're going to have to find a way to move
> beyond "the code is the design" supplemented (if at all) by a few
> cave paintings that tend to get tossed in the trash by mistake
> sometime within the first five years of the code's working life.
> No civil engineer would say "the bridge is the design" and tell you
> (and often distainfully at that) to reconstruct its design girder by
> girder.
Although I think that becoming an engineering discipline - which
software `engineering' clearly is not - is desirable, I think it's
dangerous to take the analogy this far. Code is not like bridges:
bridges aren't amenable to being taken to bits and put back together
again at almost no cost, don't usually have comments, or
self-documenting features, aren't usually introspective, are made from
parts that wear out in unpredictable ways rather than ideal
mathematical constructs and so on. The whole notion of taking a
source description and then automatically transforming it into object
code which does the work is just not like bridge building at all.
--tim
Tim Bradshaw wrote:
> * Larry Loen wrote:
>> However, if we computer scientists want to be taken seriously as an
>> engineering discipline, we're going to have to find a way to move
>> beyond "the code is the design" supplemented (if at all) by a few
>> cave paintings that tend to get tossed in the trash by mistake
>> sometime within the first five years of the code's working life.
>
>> No civil engineer would say "the bridge is the design" and tell you
>> (and often distainfully at that) to reconstruct its design girder by
>> girder.
>
> Although I think that becoming an engineering discipline - which
> software `engineering' clearly is not - is desirable, I think it's
> dangerous to take the analogy this far. Code is not like bridges:
> bridges aren't amenable to being taken to bits and put back together
> again at almost no cost, don't usually have comments, or
> self-documenting features, aren't usually introspective, are made from
> parts that wear out in unpredictable ways rather than ideal
> mathematical constructs and so on. The whole notion of taking a
> source description and then automatically transforming it into object
> code which does the work is just not like bridge building at all.
I fully agree!
And object code itself is only here for practical reasons - it is only a
better machine-interpretable notation of the same thing.
Programming is much more comparable to art than to engineering.
Regards,
Jochen
Jochen Schmidt <···@dataheaven.de> writes:
> Tim Bradshaw wrote:
>
> > * Larry Loen wrote:
> >> However, if we computer scientists want to be taken seriously as an
> >> engineering discipline, we're going to have to find a way to move
> >> beyond "the code is the design" supplemented (if at all) by a few
> >> cave paintings that tend to get tossed in the trash by mistake
> >> sometime within the first five years of the code's working life.
> >
> >> No civil engineer would say "the bridge is the design" and tell you
> >> (and often distainfully at that) to reconstruct its design girder by
> >> girder.
> >
> > Although I think that becoming an engineering discipline - which
> > software `engineering' clearly is not - is desirable, I think it's
> > dangerous to take the analogy this far. Code is not like bridges:
> > bridges aren't amenable to being taken to bits and put back together
> > again at almost no cost, don't usually have comments, or
> > self-documenting features, aren't usually introspective, are made from
> > parts that wear out in unpredictable ways rather than ideal
> > mathematical constructs and so on. The whole notion of taking a
> > source description and then automatically transforming it into object
> > code which does the work is just not like bridge building at all.
>
> I fully agree!
> And object code itself is only here for practical reasons - it is only a
> better machine-interpretable notation of the same thing.
> Programming is much more comparable to art than to engineering.
>
> Regards,
> Jochen
Yes! Software is unique, because once the description is complete in all its
detail, the desired object can be said to exist. There is no transformation to
a physical entity.
Compare this with a CAD/CAM design/execution. The design is, or could be, done
the same way as sw design/coding is done. Then there is a transformation to a
physical entity which can often be completely automated. This entity can be
customized to a greater or lesser degree before "instantiation". For example,
consider a modern auto assembly plant; every car can be different.
Bridges could be built this way but are not, probably because moving the
implementation hardware to the site is impracticable, and not enough bridges
are built to make it worthwhile.
It's interesting to consider a silicon compiler. It looks like software, but a
(customizable) physical entity is created. However, that entity is not the
desired object, merely a means to produce it.
With a sufficiently sophisticated toolset, most of the sw "design" could be
extracted from the "code" by automation. Perhaps only a top-level "intention"
is necessary, and that should be relatively small and maintainable.
Regards, KBK
Larry Loen <······@rchland.vnet.ibm.com> writes:
> However, if we computer scientists want to be taken seriously as an
> engineering discipline, we're going to have to find a way to move beyond
> "the code is the design" supplemented (if at all) by a few cave paintings
> that tend to get tossed in the trash by mistake sometime within the first
> five years of the code's working life.
We also (as an industry) need to stop writing such shitty code.
> No civil engineer would say "the bridge is the design" and tell you (and
> often distainfully at that) to reconstruct its design girder by girder.
Software is not bridge building. Most software is built with programming
languages designed to be written and read by humans, in addition to
instructing computers as to what to do.
There is no reason that those instructions can't describe clearly what is
going on to the human as well as the computer.
> I've seen the other side of it [...lost docs...]
This is a valid problem. Relevant documentation should be maintained as part
of the source code and should exist as soft copies in the same source code
control database as the code. That way it cannot be lost (out of date, and
obsolete, yes, but not lost).
> Clearly, "the code is the design" was a miserable failure; problems recurred
> often enough that they wished for that original design doc.
I don't think that anyone is (or should) be saying that good documentation is
not necessary. It is, but how necessary really depends on the complexity of
the project. Simple and conceptually "clean" projects can often get away with
a few pages of a "vision" and high-level architecture document. Complex
projects need documentation for each major portion, especially to describe how
it fits in with the other major pieces.
Even with good documentation, however, the code should still be well written,
such that a human can readily understand what is happening.
To date, I have found no magic bullet other than being careful as hell and to
write code with maintainence in mind.
> Perhaps for LISP "the code is the design" works, but for COBOL, C, C++, APL,
> FORTRAN, and other languages I could name, it has been a miserable failure
> in my experience of it.
It can work for Lisp, and it can work for C++ (I doubt it for APL,
though). The same discipline required to do good documentation also needs to
be in place to write readable and well thought out code. (It is a whole other
debate was to which languages support such goals well, of course.)
> I don't know how to fix this, but after heaping whatever justified scorn on
> the current tools we care to make, someone, somewhere I hope will be
> inspired with a useful and correct answer to this problem.
My observation is not so much that UML is useless, but that it is often used
inappropriately. I see far too much effort at putting large amounts of detail
in the model that should instead be properly in the code.
The model's purpose is to describe the design to other humans. Diagrams are a
poor medium for writing detailed logical steps. Diagrams are a great medium
for readily giving humans the essence of what a design is about. The details
needed make a project implementable should be delegated to the code.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@infomatch.com The Rhythm has my soul.
Alain Picard <·······@optushome.com.au> writes:
> Does _anybody_ here actually think UML like tools are _useful_?
> If so, how?
Well, UML-diagrams can make a simple program look very expensive. :-)
--
Lars
Lars =?iso-8859-1?q?Bj=F8nnes?= <············@fredrikstad.online.no> writes:
> Alain Picard <·······@optushome.com.au> writes:
>
> > Does _anybody_ here actually think UML like tools are _useful_?
> > If so, how?
>
> Well, UML-diagrams can make a simple program look very expensive. :-)
>
That's funny: in my experience, it was the opposite, i.e.
it took a _very_ expensive program� to make a simple diagram. :-)
Hit space for spoiler:
� You guessed it: Rational Rose!
--
It would be difficult to construe Larry Wall, in article
this as a feature. <·····················@netlabs.com>
>>>>> "tim" == Tim Bradshaw <···@tfeb.org> writes:
tim> David Bakhash <·····@alum.mit.edu> writes:
>>
>> I think that if you consider a Corba implementation in CL, such as
>> one in ACL or LispWorks, then UML is more applicable. Corba
>> development imposes restrictions on OOP that mesh well with UML,
>> as far as I know.
tim> Yes, that's the problem. I want to be able to use a great deal
tim> of what CLOS offers, not toe the priesthood's line.
So what you're saying, based on all the posts, is that you're not
using Corba, but CLOS, and want something like a UML tool.
Unless you plan to use RR or some other piece of modeling software,
why not just augment the UML notation, adding whatever CLOS features
you intend to use and represent in your diagrams? This may not be
that easy, but given that you've already written your own class
browser in CLIM, you're probably comfortable enough to graphically
represent the CLOS ideas.
I admit that I don't think I would attempt something like that. I
feel more old-fashioned. I just wanna understand a problem enough to
write the code that solves it. UML? Whah?
dave
David Bakhash <·····@alum.mit.edu> writes:
>
> So what you're saying, based on all the posts, is that you're not
> using Corba, but CLOS, and want something like a UML tool.
Well, I'm not quite at liberty to describe the situation as well as
I'd like to, unfortunately. I'm in no danger of having to use UML
*myself*, but I am interested if anyone else has had success doing so
to describe CLOS systems.
You are right that I'm dealing with programs written in unrestricted
CLOS (including some MOP stuff, though that's actually not a problem I
think), and not CORBA or some other subset.
> I admit that I don't think I would attempt something like that. I
> feel more old-fashioned. I just wanna understand a problem enough to
> write the code that solves it. UML? Whah?
My personal opinion is that this is right. Further, if I want to
understand a large CLOS program I'd do it by writing tools to get it
to describe itself (using the small amout of MOP stuff you need to do
that). I don't see any real point in using some modelling tool which
has no mechanism of ensuring that the model is consistent with the
program, still less one that does not seem to be powferul enough to
describe the program at all.
I suppose the problem with this is that the program might be full of
all sorts of low-level grut which is somehow not appropriate for the
model. I think this is indicative of other problems - if there is a
huge amount of stuff which is not described by the model, then the
model is not a very good view of what the program does, so it's not
really much use. I think the solution to this is stop wsriting in
COBOL, and find a language which provides tools that let you abstract
things at the level where a model makes sense.
So I don't, personally, think UML is useful for CLOS (and actually I
question its utility in general), but I'm interested to know if others
have succeeded with it. From the responses so far, it seems they have
not.
--tim
Tim Bradshaw <···@tfeb.org> writes:
> Has anyone had any experience with describing CL systems with UML?
> I'm not really familiar with UML, but it looks laughably too
> restrictive to describe CLOS - I'd like hear any other experiences
> though.
The question pops up occasionally on comp.object about using UML with
generic function based languages (CLOS, Dylan, etc). You could try
searching the groups.google.com archives for them. A quick search
using 'UML CLOS' brought up quite a few articles.
Chris.
--
http://www.double.co.nz/cl
i posted a query re UML/XMI a few days back.
i've yet to get an answer. i would have thought it useful to be able to
export descriptions in a "standard" form for visualization and/or import
them from other implementation environments.
...
Tim Bradshaw wrote:
>
> Has anyone had any experience with describing CL systems with UML?
> I'm not really familiar with UML, but it looks laughably too
> restrictive to describe CLOS - I'd like hear any other experiences
> though.
>