I believe that I understand closures conceptually. They are rather
simple. They are just a capture of the lexical environment in which a
function is created, so as to provide bindings for free variables.
What I am confused about is the implementation of a closure. I'm
hoping you guys can help me out.
Lets assume a local environment, whose symbol table contains the
binding of the symbol x to the number 1.
(let ((x 1))
...)
So, under the hood we have a symbol table, who's entry for x contains
an address. At this address is stored the number 1. Right?
Then, within this local environment we create a function, and hence
it's associated lexical closure.
(let ((x 1))
(defun get-x () x)
...)
So, under the hood again, we have a closure who's entry for x contains
an address? The same address that is stored in the local symbol
table? And at that address, is still the number 1?
Now, we modify the binding for x.
(let ((x 1))
(defun get-x () x)
(setf x 2))
So, under the hood again, the symbol table contains what now? The
same as before? Is it just the contents of the address pointed to by
the symbol table that have been changed? Has the number 1 been
replaced by the number 2?
What if we did a (setf x "this can't fit in the same space as an
integer!"). Then what happens? The symbol table has to be updated to
point to the address of the new string. But, this leaves the closure
hanging in the wind, as it is still pointing to the number 1.
So, it seems to me that the closure can't just point to the same
address as the local symbol table, because then it will become out of
sync if any of those symbol become re-bound.
But, it can't just contain a reference to the local symbol table
because then:
(let ((x 1))
(defun get-x () x)
(setf y 2))
The local-symbol table has picked up a new binding, from y to 2. This
would make the closure pick up this binding as well, which it should
not. I think.
So, how are closures implemented? My only ideas are using either a
"meta symbol-table" or using "object proxies", which I can explain if
I need to or if someone would like me to. But I don't really love
either of those solutions.
Thanks for any help that you can give me.
Justin Dubs
······@eos.ncsu.edu (Justin Dubs) writes:
> I believe that I understand closures conceptually. They are rather
> simple. They are just a capture of the lexical environment in which a
> function is created, so as to provide bindings for free variables.
>
> What I am confused about is the implementation of a closure. I'm
> hoping you guys can help me out.
This is a bad plan, btw.
Lisp is a language which deliberately hides implementation from you because
you are not supposed to have to know. You will not become a better Lisp
programmer by seeking the answer to this question; you will become a better
compiler writer, perhaps. But although Lisp can implement itself, one does
not prove one's merit in Lisp by doing so. You can solve a lifetime of
application problems in Lisp without ever knowing the answer to these
questions, and there is indeed no single answer to the question you ask,
any more than there is a single answer to "what internal data structure is used
when you sort something?" or "how are the hash keys of an arbitrary
hash table computed?" You are inquiring about something for which there
is a lot known, and about which you can learn a lot, but it won't get you
closer to "understanding closures", just like "understanding the chemistry
of food additives" probably won't make you a better judge of whether to buy
coke or pepsi for an upcoming party you're hosting...
> Lets assume a local environment, whose symbol table contains the
> binding of the symbol x to the number 1.
"variable", not "symbol".
Certain variables are incidentally implemented as symbols, but thinking
of variables as symbols will get you in trouble. Symbol names are used
syntactically as names, but that's not the right way to think of them
any more than saying that foo in the C language is not a variable but a
"sequence of chars". What the key to the lookuptable for a variable that
is resolved at language 'processing' time has nothing to do with the nature
of the table itself. The question you are asking is about variables,
not about symbols.
> (let ((x 1))
> (defun get-x () x)
> (setf x 2))
> What if we did a (setf x "this can't fit in the same space as an
> integer!"). Then what happens? The symbol table has to be updated to
> point to the address of the new string. But, this leaves the closure
> hanging in the wind, as it is still pointing to the number 1.
No. The error I think you are making is to assume there is immediate data
in Lisp. For now, think of ALL data as pointers and no data as anything
else. Variables have no type in Lisp, data does. But conceptually you'll
be able to scrape by if you think of x as being of type pointer-to-object.
And so you're changing x from pointer-to-1 to pointer-to-"this can't...".
The representations of the number 1 and the string "This can't..." are
both pointers whose type and nature can be dynamically figured out at
runtime.
> So, it seems to me that the closure can't just point to the same
> address as the local symbol table, because then it will become out of
> sync if any of those symbol become re-bound.
You're wrong here because you're assuming the wrong types.
But also, you're assuming there is only one way to do this. Implementations
are allowed to differ in how they do these things. So there may not be a
single canonical answer to your question about what happens internally.
> But, it can't just contain a reference to the local symbol table
> because then:
>
> (let ((x 1))
> (defun get-x () x)
> (setf y 2))
>
> The local-symbol table has picked up a new binding, from y to 2. This
> would make the closure pick up this binding as well, which it should
> not. I think.
This is what I meant by different strategies. In some
lisps, there may be a single table and you might be cluttering it. But
in others the internal world will be divided up so that functions that need
to produce closures will have a symbol table of precisely the size as the
number of free variables. If two functions have different free variables
in the same environment, there can be multiple symbol tables internally and
the closures can pick and choose which to point to. Implementations are
also allowed to lazily construct such tables if they want to bank on the
idea that the construction will not be needed in some cases.
> So, how are closures implemented? My only ideas are using either a
> "meta symbol-table" or using "object proxies", which I can explain if
> I need to or if someone would like me to. But I don't really love
> either of those solutions.
There's a book called Lisp in Small Pieces that I bet probably talks
about this. I have not read it, but it's written by Christian Queinnec
(in French, and later translated by Kathleen Callaway). The reviews on
it seem to be good, and I know Queinnec to be a knowledgeable guy, so
this might be a good way to proceed if you need this level of detail.
Although it lists for $95 on Amazon, a couple copies look to be available
used and in good condition for about $69...
Okay, I'm going to start completely over again. No one came even
close to actually answering any of my questions. I must assume that
this is my own fault for not phrasing them well. So, I'll try again.
Let me preface this by saying that the reason for my interest in this
"implementation" stuff is that, well, I am implementing it. I am
writing a lisp interpreter. Yes, a pure interpreter. No, no
compilng. Yes, it's for education purposes. Yes, I realize that
everyone thinks I'm wasting my time.
Now, imagine a local symbol table, as before, that contains the
binding of the symbol x to the number 1. In C++-ish terms, I have a
hash where the key is a pointer to the Symbol "x" and the value is a
pointer to the Number 1.
Now, again we create a closure within this lexical environment:
(let ((x 1))
(defun get-x () x))
So, my Closure has it's own symbol table for the free variables, in
this case, x. So, currently it would be another hash, whose only
entry would have a key that is again a pointer to the symbol "x" and
the value would be a pointer to the Number 1. The same Number 1 that
was pointed to in the lexical environment.
The problem is when I change the code to:
(let ((x 1))
(defun get-x () x)
(setf x 2))
Now, I have the closure already created, with it's entry pointing to
the Number 1. When I get the (setf x 2) I modify the lexical
environment's symbol table be creating a new Number, Number 2, and
updating the hash to point to this new number.
This doesn't work out well because the closure is still pointing to
the Number 1. So the x that get-x knows about hasn't changed.
So, I thought about instead having the closure just contain a
reference to lexical environment it was created in. This way, any
changes to it, such as (setf x 2), would also affect the closure.
However, now I change the code again:
(let ((x 1))
(defun get-x () x)
(setf y 2))
Now I have the problem that y is introduced into the symbol table for
the lexical environment, and hence also into the closure. This is
likely not the desired behavior, as y was not bound until after the
closure was created.
So, as the two easiest ways both have problems, I was wondering how
closures are implemented "in the real world." There are a few
obvious ways to fix my problem, but I wondering what the established,
main-stream approach was, as it may very well be better than what I
have come up with.
I'm sorry if I am not describing this problem horribly well. Thank
you all for your time, and any additional assistance that you can give
me.
Justin Dubs
>>>>> "Justin" == Justin Dubs <······@eos.ncsu.edu> writes:
Justin> Okay, I'm going to start completely over again. [...]
Justin> Let me preface this by saying that the reason for my
Justin> interest in this "implementation" stuff is that, well, I
Justin> am implementing it. I am writing a lisp interpreter.
Justin> Yes, a pure interpreter. No, no compilng. Yes, it's for
Justin> education purposes. Yes, I realize that everyone thinks
Justin> I'm wasting my time.
Closures are extremely well described in several good books. I
recomend Christian Queinnec's "Lisp In Small Pieces". The classical
SICP also helps.
You are not wasting your time since you are trying to learn something.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net
aliases: basile<at>tunes<dot>org = bstarynk<at>nerim<dot>net
8, rue de la Fa�encerie, 92340 Bourg La Reine, France
Basile STARYNKEVITCH <·········@SPAM+starynkevitch.net.invalid> writes:
> >>>>> "Justin" == Justin Dubs <······@eos.ncsu.edu> writes:
>
> Justin> Okay, I'm going to start completely over again. [...]
>
> Justin> Let me preface this by saying that the reason for my
> Justin> interest in this "implementation" stuff is that, well, I
> Justin> am implementing it. I am writing a lisp interpreter.
> Justin> Yes, a pure interpreter. No, no compilng. Yes, it's for
> Justin> education purposes. Yes, I realize that everyone thinks
> Justin> I'm wasting my time.
>
> Closures are extremely well described in several good books. I
> recomend Christian Queinnec's "Lisp In Small Pieces". The classical
> SICP also helps.
>
> You are not wasting your time since you are trying to learn something.
At the risk of being beaten up for taking a potentially unpopular
position (and what's new about that?), I just want to say that
implicit in this statement is that any attempt to learn anything
leads, definitionally, in a good direction. It seems quite unlikely
that this is so.
I think there are a lot of things one can spend time learning that do
not contribute to the world, for example, if the world already has enough
of those things. And we do have a lot of Lisp and Scheme interpreters,
running around.
The Scheme community takes pride in its ability to crank out people who
know how to make Scheme interpreters. The simplicity of the interpreter
seems to make everyone revel in writing one of their own, until the world
is really knee-deep in them.
It is often remarked that Common Lisp processors (whether interpreter or
compiler) are more work. I smile at this. They aren't an impossibly large
amount of work--a few people have done it and there is a pretty thriving
number of competing implementations. But it's quite hard. I think it's
fine to work on.
But I personally think it's at least not a good use of the community's
time to shepherd someone point by point through the process. It is an
advanced art, yes, but it is and ought to be also, I think, obscure.
We need people to understand the language itself, and its definition;
and it probably helps for people to know why the language is the way
it is. But the HOW of implementation is not and need not be a community
problem. The whole POINT of a language is to MOVE ON and USE IT. If
we do not, and we keep just reimplementing them, we have failed as a
community.
So when people say they have picked a topic to work on, and we are acting
in the role of guiding force, I feel compelled to spend my "guidance"
chips saying "don't do this" and "it is a waste". I'm confident that
once in a while, some number of people will still do it even over my
objections, and of them, this will once in a while be ok. But in most
cases I think my guidance is right.
I personally don't care if someone is learning or not. I care if they are
doing something they can make money at. I want them to make money. That
will make them able to buy food. That will make them able to buy software
from other people. That will make them able to tell success stories to
the world about how Lisp enabled them. I do not believe I will see
success stories of that kind about people who implement Lisp itself. The
good people at the existing Lisp houses have struggled for years to put
together some fine products that are "good enough", and that we should all
support, not compete with, or we spread our precious community resources
too thin. If we don't understand them, we should read the documentation,
not the source, and certainly not try to reimplement them.
Part of the reason, too, not to read the source is that learning _a_ way
to do it is not learning _the_ way to do it, and I fear that a lot of the
time it doesn't lead so much to a realization about new ways to do something
as to a limitation of the way of doing something that excludes other ways.
If there are 6 different ways to do something, does someone have to read or
implement all 6 to understand them? If not, why can they understand one
way only by implementing and the other 5 just from theory or a spec?
There are so many things computers could be doing for people.
It saddens me to see yet another eager learner turning his attention to
solved problems rather than to unsolved ones.
Success of a high tech industry should be measured by its use for an
end-user purpose, not by counting how many intermediate things it
makes; we don't say the movie industry is more successful if it sells
more latex masks. That's part of the cost of making the movie, but
movies are not made to keep the latex mask people fed.
Sadly, a lot of the computer industry's success is measured by its
ability to make problems for itself. We call it successful because it
sells more "operating systems" or "computer hardware", but those
aren't really end-user need, except in the trivial sense that our lack
of progress in the computer industry has reduced every potential
end-user to confront all manner of what should be intermediate-level
issues kept far from their view. Admittedly, today, one can send
email, purchase books and (sometimes unrelated) porn, balance a
checkbook, draw a picture, or organize one's home movies a bit better
than one could do before computers. But that's a pretty darned sad
record given literally millions of programmers over now multiple (1-4,
depending on how you count) decades. And I think at least a teensy
amount of it has to be attributed to a focus on teaching people to
solve solved problems rather than teaching them to solve unsolved
ones.
Lisp was designed to solve the world's hardest problems. I'd rather see
our programmers and potential programmers pointed at those problems,
largely still unsolved, than pat them on the back for picking a solved
one and saying "trying to learn something" is automatically not a waste
of time.
In the information age, there are many things one can learn. Too
many. We are past the day where any of those things is an automatic
virtue to confront. The new game in town is to avoid the blind
alleys, because they are legion.
Kent M Pitman <······@world.std.com> wrote in message news:<···············@shell01.TheWorld.com>...
> At the risk of being beaten up for taking a potentially unpopular
> position (and what's new about that?), I just want to say that
> implicit in this statement is that any attempt to learn anything
> leads, definitionally, in a good direction. It seems quite unlikely
> that this is so.
>
> I think there are a lot of things one can spend time learning that do
> not contribute to the world, for example, if the world already has enough
> of those things. And we do have a lot of Lisp and Scheme interpreters,
> running around.
Yes, but I am not writing "another Lisp interpreter." It does happen
to be a dialect of Lisp in that, at the core, it is based off of
S-Expressions. However, I'm leaning towards a handful of large-ish
changes. For one, ML-style type-inference. For another, a more
powerful, easier to use set of introspection and reflection tools.
For a third, syntax, maybe similar to the direction that Arc is
headed. Optional embedded syntax that can be interspersed within the
Lisp code that gets dynamically translated into S-Expressions for
evaluation.
> But I personally think it's at least not a good use of the community's
> time to shepherd someone point by point through the process.
I had misconceptions as to how new bindings are introduced and as to
how closures worked. I have asked a single question about this
process, and now I am "wasting the community's time?"
> So when people say they have picked a topic to work on, and we are acting
> in the role of guiding force, I feel compelled to spend my "guidance"
> chips saying "don't do this" and "it is a waste". I'm confident that
> once in a while, some number of people will still do it even over my
> objections, and of them, this will once in a while be ok. But in most
> cases I think my guidance is right.
>
> I personally don't care if someone is learning or not. I care if they are
> doing something they can make money at. I want them to make money. That
> will make them able to buy food. That will make them able to buy software
> from other people. That will make them able to tell success stories to
> the world about how Lisp enabled them. I do not believe I will see
> success stories of that kind about people who implement Lisp itself. The
> good people at the existing Lisp houses have struggled for years to put
> together some fine products that are "good enough", and that we should all
> support, not compete with, or we spread our precious community resources
> too thin. If we don't understand them, we should read the documentation,
> not the source, and certainly not try to reimplement them.
I respect your opinion, even though I disagree with it. I happen to
be a 20-year-old college student. "Making money" is not my biggest
interest at this point. Learning is. This project is not my job. It
is just a way to spend my free time, to further my understanding of a
topic that interests me. In this case, my fascination with computer
language theory, which is what led me to Lisp in the first place.
> Part of the reason, too, not to read the source is that learning _a_ way
> to do it is not learning _the_ way to do it, and I fear that a lot of the
> time it doesn't lead so much to a realization about new ways to do something
> as to a limitation of the way of doing something that excludes other ways.
> If there are 6 different ways to do something, does someone have to read or
> implement all 6 to understand them? If not, why can they understand one
> way only by implementing and the other 5 just from theory or a spec?
I have questioned evey step of this process as I have been exploring
and writing it. My methedology in writing this interpreter I think
you will find is humongously different from any interpreter you've
seen. Possibly in a good way. Possibly not. I don't do anything the
way "the establishment" does it, just because that's the way they do
it.
> There are so many things computers could be doing for people.
> It saddens me to see yet another eager learner turning his attention to
> solved problems rather than to unsolved ones.
What "unsolved problem" are you currently working on solving? This is
not meant sarcastically. I'm honestly curious. I'll feel more
compelled to work on unsolved problems once I have a good
understanding of the solved ones, which is what I'm working on
building up right now.
This is also assuming that you feel that computer language design is a
"solved problem." As that is what I am doing, not writing another
Common Lisp.
> Lisp was designed to solve the world's hardest problems.
Well, no, it wasn't actually. Lisp was designed to be a
mathematically sound, easier-to-use replacement for the Turing
machine. It wasn't even meant to be a viable computer language until
one of McCarthy's students noticed that if you implemented Lisp's eval
in machine language, than you would have written a Lisp interpreter.
He did this, and off Lisp went.
Justin Dubs
······@eos.ncsu.edu (Justin Dubs) writes:
> Kent M Pitman <······@world.std.com> wrote in message news:<···············@shell01.TheWorld.com>...
>
...
>
> > Lisp was designed to solve the world's hardest problems.
>
> Well, no, it wasn't actually. Lisp was designed to be a
> mathematically sound, easier-to-use replacement for the Turing
> machine. It wasn't even meant to be a viable computer language until
> one of McCarthy's students noticed that if you implemented Lisp's
> eval in machine language, than you would have written a Lisp
> interpreter. He did this, and off Lisp went.
Uh, the design of Lisp didn't end with McCarthy or his grad students.
The Lisp dialect commonly discussed here (as you may well know) is
Common Lisp which was a carefully designed language (designed in part,
BTW, by several of the contributors to this group) building on top of
the earlier design work put into Lisp Machine Lisp, MacLisp, NIL, S-1
Lisp, Spice Lisp, and Scheme[1]. *That's* the lisp that *was* designed
to solve the world's hardest problems.
-Peter
P.S. Not that argument from authority is the strongest rhetorical
technique but Kent Pitman *is* listed as one of the "Major Technical
Contributors" in the front Common Lisp standard[2] . So you might want
to reconsider the wisdom of replying "Well, no" when he makes a claim
of the form "Lisp was designed to ...". Or not; YMMV. But I would.
[1] <http://www.lispworks.com/reference/HyperSpec/Body/01_ab.htm>
[2] ANSI INCITS 226-1994 (R1999) p. xxviii
--
Peter Seibel ·····@javamonkey.com
The intellectual level needed for system design is in general
grossly underestimated. I am convinced more than ever that this
type of work is very difficult and that every effort to do it with
other than the best people is doomed to either failure or moderate
success at enormous expense. --Edsger Dijkstra
Peter Seibel <·····@javamonkey.com> writes:
> ······@eos.ncsu.edu (Justin Dubs) writes:
>
> > Kent M Pitman <······@world.std.com> wrote [...]
> >
> > > Lisp was designed to solve the world's hardest problems.
> >
> > Well, no, it wasn't actually. Lisp was designed to be a
> > mathematically sound, easier-to-use replacement for the Turing
> > machine. It wasn't even meant to be a viable computer language until
> > one of McCarthy's students noticed that if you implemented Lisp's
> > eval in machine language, than you would have written a Lisp
> > interpreter. He did this, and off Lisp went.
>
> Uh, the design of Lisp didn't end with McCarthy or his grad students.
> The Lisp dialect commonly discussed here (as you may well know) is
> Common Lisp which was a carefully designed language (designed in part,
> BTW, by several of the contributors to this group) building on top of
> the earlier design work put into Lisp Machine Lisp, MacLisp, NIL, S-1
> Lisp, Spice Lisp, and Scheme[1]. *That's* the lisp that *was* designed
> to solve the world's hardest problems.
Thanks, Peter. Saved me some typing, which I'll spend on related
remarks since this is indeed what I meant.
Although proud of its traditions, Lisp's design has taken decades, and
continues. But its foundational years were spent on AI, and even
though AI per se is not its core business now, and some in commercial
sectors find AI a dirty word, the severe pounding on that it received
as it tried to support work in math, planning & scheduling, vision,
teaching, etc. [some of the disciplines I was alluding to when I said
"the world's hardest problems] have served it well in its longevity in
a hostile, often openly anti-lisp world. People have tried to kill
Lisp many times and the fact that it hasn't gone away is testimony to
its continued ability to show people ideas and solutions that are
still not as available in other languages as one might hope they would
someday be. Java, Perl, C++, and others have benefited from Lisp's
experience, but they do not subsume all that Lisp has to offer.
The fact of something's start is often accidental. It's what you do
with an opportunity once you get it that matters, not how you get it.
I got involved in Common Lisp design because I needed a ride to a Lisp
Conference, and Glenn Burke, who had offered me a ride, told me that
he hoped I wouldn't mind that he was stopping off for a CL design
meeting along the way so we'd have to stay an extra day. I asked if I
could come to the meeting, too, and he got me an agenda. I got this
opportunity because of my work at MIT. I was at MIT because a friend
of mine in the Panama Canal Zone had applied to MIT and had asked them
if he'd have to come to an interview, being so far away. They sent a
second copy of an application stamped "your interview is waived". He
handed me the unneeded extra application and said "want this?" I
might otherwise have gone to Georgia Tech or the University of Tulsa.
So when you talk about Lisp and its curious origins, it's a good story
no matter how it's told, but the worth of Lisp does not hinge so much
on its inspiration as its experience and its adaptation to that
experience, as I hope my own worth is more about what I've done and
how I've changed than about how I got my pretty arbitrary starts on
things...
> P.S. Not that argument from authority is the strongest rhetorical
> technique but Kent Pitman *is* listed as one of the "Major Technical
> Contributors" in the front Common Lisp standard[2] . So you might want
> to reconsider the wisdom of replying "Well, no" when he makes a claim
> of the form "Lisp was designed to ...". Or not; YMMV. But I would.
Heh. Thanks for the vote of confidence. I'm of two minds on this. I
don't think credentials alone should win arguments. But I do think
credentials are underemphasized in a modern over-egalitarian world
that seems to assume that one person's casual opinion is exactly equal
to another's in all cases.
Probably the legal term of art "prima facie" (findlaw.com defines this
as "sufficient to establish a fact or case unless disproved") wants to
be used here; that is, one might want to say that a person with an
appropriate credential can, by merely saying something, have asserted
a prima facie case (rebuttable presumption of truth) for the claim,
while someone without a credential might have to do more building of
foundational claims. In effect, slashdot does this by its Karma
mechanism that allows people who are respected to enter a discussion
at a higher tier but doesn't keep them from being moved higher or
lower in the pecking order after this initial position. All this to
say that I think people should be encouraged to question what warrants
questioning, as well as should be encouraged to shut up or at least go
slowly when they are out of their league or contributing nothing new.
(I'm not making a statement about the situation here, just speaking in
the abstract...)
It's not that I worry about people being disrespectful in the
"interpersonal" sense, but I worry about them being disrespectful in
the sense that those more experienced can have a lot of wisdom behind
what they say, and the value of that wisdom comes in their ability to
leap directly to a correct answer; to the extent that you make them
recreate everything from scratch, you destroy any value of their
having been able to offer a cached solution, and you both squander the
value of that wisdom and distract from the valuable contributions they
could be making. (Again, whether _I_ am on any given occasion the
person who is owed this hypothetical degree of respect is not what I'm
getting at; the whole question of what DOES constitute a credential,
and whether my or anyone in particular's credentials are worth
anything, is orthogonal again to the question of what one does with a
credential once one sees one. I just often, and more with passing
time, lament the loss of the notion of credentials on the net...)
"Justin Dubs" <······@eos.ncsu.edu> wrote in message
·································@posting.google.com...
> Kent M Pitman <······@world.std.com> wrote in message
news:<···············@shell01.TheWorld.com>...
> I have questioned evey step of this process as I have been exploring
> and writing it. My methedology in writing this interpreter I think
> you will find is humongously different from any interpreter you've
> seen. Possibly in a good way. Possibly not. I don't do anything the
> way "the establishment" does it, just because that's the way they do
> it.
Yeah, right. Just like the establishment you seem to be unwilling
and maybe unable to learn from the past. So you will be stuck like
the rest of the establishment, reimplementing the state of the art.
Wade
Last one to realize Justin's cup is full is a rotten egg.
But I say, good for him. The student has to own their own learning.
Young tigers are to be encouraged, no matter how arrogant they seem.
Lawdy, haven't we all passed that way?
They are just a little hard to help since they already know everything.
Their questions (and esp. follow-up questions) all read like answers.
Maybe it is the insecurity of youth. Most heavyweights preface newbie
questions in unfamiliar turf with twenty-five words or less of groveling
self-abasement, tossed off comfortably because they've done OK on their
home turf. And they certainly don't start throwing punches ("what
unsolved problem are you working on?") or lecturing the priesthood
("Well, no, it wasn't actually."). But without a string of trophies on
the shelf, even the strongest young tiger ends up roaring a little more
loudly than necessary.
The bad news is that he seems unaware of SICP or Lisp in Small Pieces.
But there ya go, another hallmark of gifted young talent: not learning
the establishment stuff before tossing it aside.
Now it's my turn on the couch. I have to apologize for my condescension
towards Justin and overall bogus posturing as a grup. Call it the
pontificacy of old age.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
I want to thank everyone for their responses. I have learned a lot.
I've done a lot more reading, both of your posts and of texts, and I
have cleared up most of my misconceptions revolving around
environments and bindings, symbols vs variables, and so on.
You see, my formal education has been a crock, so I have had to fall
back on self-learning. There are certain things that I seem to have
trouble grasping when working by myself, with only reference books for
assistance. Sometimes I need the intervention, no matter how
belligerent, of others to get me pushed in the right direction.
I would also like to apologize for seeming so defensive. From the
moment I received the first responses to my original post, I felt like
I was being attacked by the "community," and I reacted to it
defensively, and poorly. I'm sorry.
> They are just a little hard to help since they already know everything.
> Their questions (and esp. follow-up questions) all read like answers.
I'm a simple student, seeking knowledge. Nearly all of the original
responses to my post were condescending and belittling. I took
offense to this and reacted in kind. I should not have. Again, I am
sorry.
> Maybe it is the insecurity of youth.
That's certainly part of it.
> And they certainly don't start throwing punches ("what
> unsolved problem are you working on?")
It was an honest question. I still would like to know the answer. He
told me that I was wasting my time by working on "solved problems", so
I wanted to know what he was doing. Is it wrong to even question the
"priesthood?"
I will still maintain that language design is not a "solved problem."
> or lecturing the priesthood ("Well, no, it wasn't actually.").
I will still maintain that Lisp was created as a mathematical tool,
not as a language to be used to "solve difficult problems." Lisp has
certainly evolved to do this, but evolution != creation. Then again,
this may just be semantics. Or, I may just be completely wrong. If
this is the case, then I would appreciate a link to a site or a
reference to a book that will correct me.
> The bad news is that he seems unaware of SICP or Lisp in Small Pieces.
> But there ya go, another hallmark of gifted young talent: not learning
> the establishment stuff before tossing it aside.
I have read On Common Lisp, The Anatomy of Lisp, and several others
that I can not think of off-hand. I had not heard of Lisp in Small
Pieces, you are correct. Thankfully, another post on this thread
pointed it out to me, and I will be getting my hands on it tomorrow.
> Now it's my turn on the couch. I have to apologize for my condescension
> towards Justin and overall bogus posturing as a grup. Call it the
> pontificacy of old age.
You have nothing to apologize for. I apologize for my defensiveness.
I felt as though I was being attacked and belittled for asking my
original question. But, that is no excuse for my behavior.
Take care everyone.
Justin Dubs
On Tue, Mar 11, 2003 at 08:36:47PM -0800, Justin Dubs wrote:
> I have read On Common Lisp, The Anatomy of Lisp, and several others
> that I can not think of off-hand. I had not heard of Lisp in Small
> Pieces, you are correct. Thankfully, another post on this thread
> pointed it out to me, and I will be getting my hands on it tomorrow.
Pick up _Paradigms of AI Programming_ too. It has nice examples of a
Prolog interpreter and compiler, and a Scheme interpreter and compiler,
among other things.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
From: Johann Hibschman
Subject: Re: Help understanding closures
Date:
Message-ID: <m2bs0geamk.fsf@yahoo.com>
Matthew Danish <·······@andrew.cmu.edu> writes:
> On Tue, Mar 11, 2003 at 08:36:47PM -0800, Justin Dubs wrote:
> > I have read On Common Lisp, The Anatomy of Lisp, and several others
> > that I can not think of off-hand. I had not heard of Lisp in Small
> > Pieces, you are correct. Thankfully, another post on this thread
> > pointed it out to me, and I will be getting my hands on it tomorrow.
>
> Pick up _Paradigms of AI Programming_ too. It has nice examples of a
> Prolog interpreter and compiler, and a Scheme interpreter and compiler,
> among other things.
I have _ANSI Common Lisp_ by Paul Graham and _Paradigms of AI
Programming_ by Peter Norvig. If you're looking for good introductory
lisp books, those are both great.
Personally, I don't use _ANSI Common Lisp_ all that much any more,
since I've downloaded the hyperspec and look up any questions I have
in that, but it took ANSI CL to get me to the point where I could do
that. (The Hyperspec is wonderful, if you've not looked at it.)
For your specific case, Justin, thinking about an interpreter, see if
you can find _Structure and Interpretation of Computer Programs_ by
Abelson and Sussman. It uses Scheme, but the last few chapters
present a good overview of frames and bindings and so on.
It's online, if you want to check it out. Specifically, look at:
http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-21.html#%25_sec_3.2
and then Chapters 4 and 5.
Good luck. If you've got time on your hands, I, for one, would really
like to see something inspired by Common Lisp (with, say, 90% of the
features), but with the small size and embeddability of Lua. There's
a goal for ya!
Cheers,
-Johann
Justin Dubs wrote:
> I'm a simple student, seeking knowledge. Nearly all of the original
> responses to my post were condescending and belittling. I took
> offense to this and reacted in kind. I should not have. Again, I am
> sorry.
Hey, counterpunching needs no apology. But the key here is that none of
the responses were condescending or belittling. Your "questions" were
packed with erroneous assertions. They were also poorly written simply
from the standpoint of the English language, hence hard even to
understnad and respond to. The community did its best to enlighten you,
efforts you shrugged off with more erroneous assertions.
> It ["what unsolved...?] was an honest question.
Nah, it was a debating tactic. You know it, we know it, give it up, it's
OK, we all do the same.
> I still would like to know the answer. He
> told me that I was wasting my time by working on "solved problems", so
> I wanted to know what he was doing.
I know you have not read the literature. Do you also not know who he is?
You'll discover he has spent a lot of time solving your unsolved problem
of language design.
> Is it wrong to even question the
> "priesthood?"
Yep. In the Asian tradition you get your head handed to you for that.
Your teacher may not know everything, but you won't know that for sure
until you know more than them. Your job is to learn, not defend your
ego. Sometimes my tai chi teacher comes over and says "do X", sometimes
he says "don't do X". Sorting that out is my problem, all I know is that
he is very good at what he does and that he corrected me because
something did not look right to him. And I get more better instruction
because I do not say "But you said...".
>
> I will still maintain that language design is not a "solved problem."
You haven't used Cells.
> I will still maintain that Lisp was created as a mathematical tool,
> not as a language to be used to "solve difficult problems." Lisp has
> certainly evolved to do this, but evolution != creation. Then again,
> this may just be semantics.
Right, you are stuck in quibblethink and have lost sight of what was
being said. "evolution != creation". Great, there's a hundred article
mindless NG debate. Dude, creation is not instantaneous. I am the last
person to speak on Lisp's history, but in the beginning McCarthy turned
to lambda calculus for the language foundation. Not to make a
mathematical tool, but to create a good language. Then they started
working on AI, a problem intractable, not just hard. In that crucible,
to our advantage, Lisp was formed.
> I have read On Common Lisp, The Anatomy of Lisp, and several others
> that I can not think of off-hand. I had not heard of Lisp in Small
> Pieces, you are correct. Thankfully, another post on this thread
> pointed it out to me, and I will be getting my hands on it tomorrow.
Now yer talkin. But no SICP?
Point of information unrelated to anything above: you said you were
going to write an interpreter the likes of which the world has never
seen. Cool. So what? Will you be able to interpret HLLs giving me, the
applications guy, features I have never seen? If not, why bother?
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
Kenny Tilton <·······@nyc.rr.com> wrote in message news:<················@nyc.rr.com>...
> > Is it wrong to even question the
> > "priesthood?"
> Yep. In the Asian tradition you get your head handed to you for that.
> Your teacher may not know everything, but you won't know that for sure
> until you know more than them. Your job is to learn, not defend your
> ego. Sometimes my tai chi teacher comes over and says "do X", sometimes
> he says "don't do X". Sorting that out is my problem, all I know is that
> he is very good at what he does and that he corrected me because
> something did not look right to him. And I get more better instruction
> because I do not say "But you said...".
You know, I'm glad that every stupid thing us asians do is translated
into something useful. It must help me a great deal in Europe without
me knowing it.
But yes, there is often a threshold in learning rote when answers
given early may complicate matters. Still, that's up to your and your
teacher's personalities to decide...
Tj
From: Kenny Tilton
Subject: OT Martial arts instruction [was Re: Help understanding closures]
Date:
Message-ID: <3E6F8787.8010405@nyc.rr.com>
Tj wrote:
> Kenny Tilton <·······@nyc.rr.com> wrote in message news:<················@nyc.rr.com>...
>
>>> Is it wrong to even question the
>>>"priesthood?"
>>
>>Yep. In the Asian tradition you get your head handed to you for that.
>>Your teacher may not know everything, but you won't know that for sure
>>until you know more than them. Your job is to learn, not defend your
>>ego. Sometimes my tai chi teacher comes over and says "do X", sometimes
>>he says "don't do X". Sorting that out is my problem, all I know is that
>>he is very good at what he does and that he corrected me because
>>something did not look right to him. And I get more better instruction
>>because I do not say "But you said...".
>
>
> You know, I'm glad that every stupid thing us asians do is translated
> into something useful.
Isn't it great how people can put such a positive spin on things? I long
thought "win without fighting" had to do with conflict avoidance, where
the "win" could be mutual, or possibly me just realizing my opponent was
right. Then I read some texts saying it was still about conquering the
opponent, just with a minimum of casualities to one's own side. Oh well.
btw, "Asian tradition" was (too) shorthand for "traditional Asian
martial arts instruction".
> But yes, there is often a threshold in learning rote when answers
> given early may complicate matters.
No, he gives us all the answers all the time starting on day one. And he
is always coming up with new ways to explain what he is after, though he
is close to retirement. But of course the answers do not help, until we
get to a point one day in our practice where we realize, oh, that is
what he means.
My problem with arguing with the teacher is this. If he corrects me, it
is because he saw something wrong in my form. If last week he corrected
me with words which seemed to contradict the words he used today, that's
just a problem with natural language. And boy does that have problems.
So the only thing I am sure of is that he saw something wrong both times
and gave me a clue as to how to correct it. The only mistake I can make
is to get hung up on resolving the apparent contradiction between the clues.
Hell, when coding I break my own rules. Rules are artifices which try to
produce the Right Way if followed, but no rule can capture everything a
master knows, so just go with the master until they lose your
confidence, then leave quietly. That's my take, anyway.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
Kenny Tilton <·······@nyc.rr.com> wrote in message news:<················@nyc.rr.com>...
> Isn't it great how people can put such a positive spin on things? I long
> thought "win without fighting" had to do with conflict avoidance, where
> the "win" could be mutual, or possibly me just realizing my opponent was
> right. Then I read some texts saying it was still about conquering the
> opponent, just with a minimum of casualities to one's own side. Oh well.
It's wonderful when people learn a lot by totally misunderstanding.
That's probably the point of books, that there's no teacher to correct
your insights. And I am pretty certain there are some singers who
pronounce things ambiguously.
> My problem with arguing with the teacher is this. If he corrects me, it
> is because he saw something wrong in my form. If last week he corrected
> me with words which seemed to contradict the words he used today, that's
> just a problem with natural language. And boy does that have problems.
I often think that people are turned into consumers of learning,
starting in school where they're pushed to learn bucketloads of junk,
and they develop the habit of expecting answers without reflecting.
Teachers become adversarial because you don't truly want what they
have, but like Microsoft they're hard for most to escape.
Maybe the nice thing about the dotcom bust is the carnage of people
who see computers as an obstacle between them and money. IME, those
are the people most likely to lose their patience gratuitously, and
need to impotently argue. (As opposed to the cool ones who tend to
catch their teachers in grey areas. ;)
I know this was a tendency of mine when programming was something to
make a buck. I often have to wonder if I'm whaling on Java just
because that world was just so dirty. Maybe my only true interest in
things like lisp and computation is that there's something terrible on
me I have to get rid of.
BTW, you should take a look at Bruce Lee's _Tao of Jeet Kune Do_, if
you haven't earlier. I think being in America gave him real insights
into eastern culture. Although I don't know how "eastern" it is --
schools of programming look suspiciously like schools of martial arts,
with the occasional need to take the flamewars into the ring with
little shootouts. He got tired of how ossified the schools became,
and told people to take anything meaningful and discard the rest.
"All vague notions must fall before a pupil can call himself a
master." -- Bruce Lee
Tj
From: Kenny Tilton
Subject: Re: OT Martial arts instruction [was Re: Help understanding closures]
Date:
Message-ID: <3E70A5B1.6030702@nyc.rr.com>
Tj wrote:
> BTW, you should take a look at Bruce Lee's _Tao of Jeet Kune Do_, if
> you haven't earlier.
yep, one of those books with a dog-ear on every page.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
On 12 Mar 2003 09:55:31 -0800, ··········@yahoo.com (Tj) wrote:
>Kenny Tilton <·······@nyc.rr.com> wrote in message news:<················@nyc.rr.com>...
>> Yep. In the Asian tradition you get your head handed to you for that.
>> Your teacher may not know everything, but you won't know that for sure
>> until you know more than them. Your job is to learn, not defend your
>> ego. Sometimes my tai chi teacher comes over and says "do X", sometimes
>> he says "don't do X". Sorting that out is my problem, all I know is that
>> he is very good at what he does and that he corrected me because
>> something did not look right to him. And I get more better instruction
>> because I do not say "But you said...".
>
>You know, I'm glad that every stupid thing us asians do is translated
>into something useful. It must help me a great deal in Europe without
>me knowing it.
I'm curious, does it work the other way around too?
(I remember reading a story when I was a child, where a Chinese
student came to Europe, and "of course" he had a black belt in karate,
which was an important element of the story. I'm told there was
similarly a time when if a European or American went to Asia, people
would assume you were probably a rocket scientist ^.^)
>But yes, there is often a threshold in learning rote when answers
>given early may complicate matters. Still, that's up to your and your
>teacher's personalities to decide...
There's no single right answer to this. Some of my lecturers in
college talked an awful lot of rubbish; fortunately, being a free
spirited, independent thinker, I was able to see this. Others talked a
lot of sense; unfortunately, being an arrogant little punk who thought
he was God's gift to the world, I wasted a fair amount of time
rediscovering this for myself :P
--
"Sore wa himitsu desu."
To reply by email, remove
killer rodent from address.
http://www.esatclear.ie/~rwallace
First off, thanks for the level-headed response. You are right about
most everything. My original posts were unintelligable. My
understanding of the terminology was in a world of hurt, and I'm sure
I confused the hell out of everyone. I've read 3.1 in CLHS and have a
better grasp of the terminology now.
Kenny Tilton <·······@nyc.rr.com> wrote in message news:<················@nyc.rr.com>...
> Justin Dubs wrote:
> > I'm a simple student, seeking knowledge. Nearly all of the original
> > responses to my post were condescending and belittling. I took
> > offense to this and reacted in kind. I should not have. Again, I am
> > sorry.
>
> Hey, counterpunching needs no apology. But the key here is that none of
> the responses were condescending or belittling. Your "questions" were
> packed with erroneous assertions. They were also poorly written simply
> from the standpoint of the English language, hence hard even to
> understnad and respond to. The community did its best to enlighten you,
> efforts you shrugged off with more erroneous assertions.
>
> > It ["what unsolved...?] was an honest question.
>
> Nah, it was a debating tactic. You know it, we know it, give it up, it's
> OK, we all do the same.
Fair enough.
>
> > I still would like to know the answer. He
> > told me that I was wasting my time by working on "solved problems", so
> > I wanted to know what he was doing.
>
> I know you have not read the literature. Do you also not know who he is?
> You'll discover he has spent a lot of time solving your unsolved problem
> of language design.
I know he was involved with the formation of Common Lisp. I've only
known of the Common Lisp world for a year now, and I've really only
been involved in studying it for half of that. Like I said before,
I'm just an undergrad. I'd like to know more. Can anyone, or you
yourself Kent, recommend a site with some manner of biography. I am
interested in knowing what you have contributed to the Lisp world.
> > I will still maintain that language design is not a "solved problem."
>
> You haven't used Cells.
As a newbie, I must profess that I have absolutely no idea what you
are talking about. I noticed the correlation between this and your
sig, which also contains a reference to cells. Could I get you to
clarify?
> [...] I am the last
> person to speak on Lisp's history, but in the beginning McCarthy turned
> to lambda calculus for the language foundation. Not to make a
> mathematical tool, but to create a good language. Then they started
> working on AI, a problem intractable, not just hard. In that crucible,
> to our advantage, Lisp was formed.
Fair enough. You have convinced me. Thank you.
> > I have read On Common Lisp, The Anatomy of Lisp, and several others
> > that I can not think of off-hand. I had not heard of Lisp in Small
> > Pieces, you are correct. Thankfully, another post on this thread
> > pointed it out to me, and I will be getting my hands on it tomorrow.
>
> Now yer talkin. But no SICP?
Ahhh... Structure and Interpretation of Computer Programs. Not coming
from the background of formal academic training, I did not recognize
this acronym. Yes, I have read it, but it could probably use a
re-read. :-)
> Point of information unrelated to anything above: you said you were
> going to write an interpreter the likes of which the world has never
> seen. Cool. So what? Will you be able to interpret HLLs giving me, the
> applications guy, features I have never seen? If not, why bother?
Very good questions, to which I have no satisfactory answers. Writing
this pure interpreter is foremost a way of helping me learn and
understand Lisp. If you don't understand it, you're going to have
trouble implementing an interpreter for it. :-)
My interests seem to lie in the fields of language design and, more in
general, in creating tools to help programmers do their jobs better,
and faster.
HLL's trade speed for flexibility, in general. I'm going to try and
go a bit further with that idea, for the sake of experimentation. In
Common Lisp, the following won't work:
(let ((x 1))
(eval '(print x)))
It will scold you first about the unused lexical variable, x, and then
about the unbound variable, x.
I'm hoping that that won't be true with my Lisp dialect. This will,
of course, require another sacrafice to the gods of flexibility. More
speed, I assume they'll want.
I have ideas for a new type-system. Optional static typing with
ML-style type-inference, combined with a good
pattern-matching/argument deconstruction system.
Ah, yes, and syntax. Run-time modifiable, embeddable syntax,
translated dynamically into s-expressions.
I suppose my goal, as far-fetched as it sounds, is to have a dynamic
Lisp core, on top of which I can program in a more ML-like way.
I can dream, can't I. :-)
As far as the new features for the App Dev guy, I don't really know
what I'd be able to offer that he can't get in other ways. Atleast
nothing new that he would want. As far as "why bother": Because I
can. Because it interests me. If I come up with a better idea, or
lose interest in this one, I'll stop.
Justin Dubs
······@eos.ncsu.edu (Justin Dubs) writes:
> In Common Lisp, the following won't work:
>
> (let ((x 1))
> (eval '(print x)))
(let ((x 1))
(eval `(print ,x)))
or
(let ((x 1))
(declare (special x))
(eval '(print x)))
Your example is possible with either of these transformations; maybe
even these aren't tolerable.
That your example doesn't work doesn't strike me as a flaw in the
language, but rather a flaw in your understanding. What you're asking
for is more limited, and even ambiguous, compared to what we have
today.
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
······@eos.ncsu.edu (Justin Dubs) writes:
> I know he was involved with the formation of Common Lisp. I've only
> known of the Common Lisp world for a year now, and I've really only
> been involved in studying it for half of that. Like I said before,
> I'm just an undergrad. I'd like to know more. Can anyone, or you
> yourself Kent, recommend a site with some manner of biography. I am
> interested in knowing what you have contributed to the Lisp world.
Well, the reason I'm hard to find is that I'm not what you'd think of
as a first-tier name like McCarthy, Steele, Sussman, Greenblatt, or
Gabriel. I'm kind of in that nebulous second-tier underclass that has
had their fingers in a lot of "this and that" which always needs
doing, but isn't always worth mentioning in anyone's short summary. :)
There are probably a lot of us in that category, actually...
Still, for what it's worth, I just now created
http://www.nhplace.com/kent/PFAQ/kents-lisp-contributions.lisp
in case your or anyone else cares to see a hastily constructed list of
how Lisp and I have crossed paths. (If someone sees an error or omission,
they can contact me privately. I don't think it really needs to be a
point of major conversation here.)
Kent M Pitman <······@world.std.com> writes:
> Still, for what it's worth, I just now created
> http://www.nhplace.com/kent/PFAQ/kents-lisp-contributions.lisp
Did you intend this instead?
http://www.nhplace.com/kent/PFAQ/kents-lisp-contributions.html
^^^^
----------------------------------------------------------|
Carl Shapiro <·············@panix.com> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > Still, for what it's worth, I just now created
> > http://www.nhplace.com/kent/PFAQ/kents-lisp-contributions.lisp
>
> Did you intend this instead?
>
> http://www.nhplace.com/kent/PFAQ/kents-lisp-contributions.html
> ^^^^
> ----------------------------------------------------------|
(got private mail about this, too)
yes.
sigh.
Justin Dubs wrote:
> Can anyone, or you
> yourself Kent, recommend a site with some manner of biography. I am
> interested in knowing what you [Kent, right? <kt>] have contributed to the Lisp world.
He contributed Lisp!!!!! OK, McCarthy gets some credit, as do a few
other folks. We are lucky here on c.l.l. to have a few regulars who were
there when Common Lisp was formed. It is so cool to whine about some
language feature and then have one of these folks jump in with "well,
the reason we went the way we did on that was yada yada yada".
>
>
>>>I will still maintain that language design is not a "solved problem."
>>
>>You haven't used Cells.
>
>
> As a newbie, I must profess that I have absolutely no idea what you
> are talking about.
My bad. That's an in joke because I won't shut up about Cells here on
c.l.l. But it /was/ responsive in that Cells solve a lot of problems
involved in programming.
> I noticed the correlation between this and your
> sig, which also contains a reference to cells. Could I get you to
> clarify?
DL the PDF by clicking Overview in the first paragraph at:
http://www.tilton-technology.com/cells_top.html
> In Common Lisp, the following won't work:
>
> (let ((x 1))
> (eval '(print x)))
>
> It will scold you first about the unused lexical variable, x, and then
> about the unbound variable, x.
>
> I'm hoping that that won't be true with my Lisp dialect.
I am hoping it will. How the hell do I write code which will become data
and then sent a million miles to your interpreter to be evaluated in
whatever lexical scope the eval statement randomly sits in (from my
viewpoint as the author of the code sent a million miles?).
ie, change the code above to:
(let ((code (get-packet-from *god-knows-where*)))
(dotimes (x 10)
(eval code))
> I have ideas for a new type-system. Optional static typing with
> ML-style type-inference
Like Dylan? Anyway, knock yourself out. Cells turned out to be old-hat
(and a trivial example of) what i discovered was called constraints or
constraint-logic programming. Steele rediscovered it in the eighties
after it was abandoned inthe sixties. Garnet is (in part) a Lisp
constraint hack I had sitting unbeknownst to me in a folder from the MCL
distro.
Maybe if I knew about all that I never would have gotten as far as I
have with Cells, or I might have been sucked into making the same
mistakes those folks did.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
Kenny Tilton <·······@nyc.rr.com> wrote in message news:<················@nyc.rr.com>...
> Justin Dubs wrote:
> > Can anyone, or you
> > yourself Kent, recommend a site with some manner of biography. I am
> > interested in knowing what you [Kent, right? <kt>] have contributed to the Lisp world.
>
> He contributed Lisp!!!!! OK, McCarthy gets some credit, as do a few
> other folks. We are lucky here on c.l.l. to have a few regulars who were
> there when Common Lisp was formed. It is so cool to whine about some
> language feature and then have one of these folks jump in with "well,
> the reason we went the way we did on that was yada yada yada".
Very interesting. Thank you for enlightenming me.
> My bad. That's an in joke because I won't shut up about Cells here on
> c.l.l. But it /was/ responsive in that Cells solve a lot of problems
> involved in programming.
>
> > I noticed the correlation between this and your
> > sig, which also contains a reference to cells. Could I get you to
> > clarify?
>
> DL the PDF by clicking Overview in the first paragraph at:
>
> http://www.tilton-technology.com/cells_top.html
I'm downloading it as I type this. Thanks a lot for the link.
> > In Common Lisp, the following won't work:
> >
> > (let ((x 1))
> > (eval '(print x)))
> >
> > It will scold you first about the unused lexical variable, x, and then
> > about the unbound variable, x.
> >
> > I'm hoping that that won't be true with my Lisp dialect.
>
> I am hoping it will. How the hell do I write code which will become data
> and then sent a million miles to your interpreter to be evaluated in
> whatever lexical scope the eval statement randomly sits in (from my
> viewpoint as the author of the code sent a million miles?).
I'm not saying that the lexical-environment-respecting eval would be
the only eval. It would just be nice to have the option. Maybe
having eval vs local-eval. In combination with with a good package
system and the ability to have non-global (ie. local) functions, it
should allow for the simple creation of a jail system which could
in-fact be very useful in your example of sending code from afar over
a socket.
> Like Dylan? Anyway, knock yourself out. Cells turned out to be old-hat
> (and a trivial example of) what i discovered was called constraints or
> constraint-logic programming. Steele rediscovered it in the eighties
> after it was abandoned inthe sixties. Garnet is (in part) a Lisp
> constraint hack I had sitting unbeknownst to me in a folder from the MCL
> distro.
Yes, a bit like Dylan. Only with the S-Expression core of Lisp,
allowing for defmacro and the like. Yes, I am familiar with
contraint-logic programming. An interesting concept, some of whose
ideas I may be borrowing.
Justin Dubs
From: Tim Bradshaw
Subject: Re: Help understanding closures
Date:
Message-ID: <ey3r89bwngj.fsf@cley.com>
* Justin Dubs wrote:
> I'm not saying that the lexical-environment-respecting eval would be
> the only eval. It would just be nice to have the option. Maybe
> having eval vs local-eval. In combination with with a good package
> system and the ability to have non-global (ie. local) functions, it
> should allow for the simple creation of a jail system which could
> in-fact be very useful in your example of sending code from afar over
> a socket.
This is a really strange view. I've written jail systems for CL and
the problems aren't like this at all. There are essentially three
problems:
(1) Define a safe subset of the language. This is fairly easy if
by `safe' you don't include `may cause stack overflow' & stuff
like that. It's harder if you want safe *and* useful. Java's
experience probably helps here.
(2) Catch runtime errors reliably and handle them. This is mostly
an implementation issue - you require a lot of the things that
the standard allows not to be caught to actually be caught, and
to be caught in a handleble way (so if a thread gets a stack
overflow the rest of the system needs to be able to catch it).
(3) Intern handling. You need to be able to get at the point in
the reader just before a symbol is interned. This sounds
obscure, but you need it so you can read unknown source and
prevent it interning symbols in places you don't want it to
(it's not hard to find out, *after* you've read the source,
whether it has bad symbols (or other objects) in it, but that
is too late unless you are willing to do heroic tricks).
The nature of EVAL isn't even on the map.
--tim
On Wed, Mar 12, 2003 at 03:28:55PM -0800, Justin Dubs wrote:
> I'm not saying that the lexical-environment-respecting eval would be
> the only eval. It would just be nice to have the option. Maybe
> having eval vs local-eval.
Someone else has already pointed out the ambiguities of
lexical-environment aware eval. Languages which do support such an eval
usually have an argument to eval which accepts an environment object.
But the problem with lexical-environment aware eval is that its presence
affects the potential efficiency of a compiler. Normally, the lexical
environment information is compiled away; usually ending up as offsets
into a stack, registers, memory locations, etc. When you have a
``lexical-eval'' operator then you suddenly need to preserve the lexical
environment information everywhere.
These kind of issues don't come up so much with an interpreter, though.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
······@eos.ncsu.edu (Justin Dubs) writes:
> I'm not saying that the lexical-environment-respecting eval would be
> the only eval. It would just be nice to have the option.
Let me put this into historical perspective for you:
EVAL used to, a long time ago, always 'respect' (we called it 'invading'
then) the local (it wasn't lexical) environment. That is, all variables
used to be dynamic.
This meant that programs could not hide from other programs invading them.
A consequence of this is that you can never prove any program correct because
you have to worry that, either in a breakpoint or in an interrupt or in
a variety of other situations, someone might set a free variable that will
affect your running program adversely.
Lexical variables implement privacy. You can't have optional privacy.
Having the police only raid your house on odd days doesn't mean you have
privacy on the days they don't do it--it means you have no privacy--because
privacy isn't just about the event, but about the possibility.
Just as mathemeticians reduce problems to various canonical problems
in order to resolve their "difficulty", philosophers reduce problems
to standard scenarios that are of known intellectual complexity. Here
we have a problem that is equivalent to the "unstoppable force" and
the "impenetrable barrier". You can have both of those as concepts,
but not in the same manifest scenario; if you have a force that goes
through anything, you cannot have an impenetrable barrier, and if you
can have an impenetrable barrier you cannot have a force that goes
through anything.
Likewise, you can't have both private variables and an operator that can
violate privacy. Lexical variables are private. They are available to those
who are in their initial scope and to nothing else. It is this fact and
this fact only that allows the compiler to optimize them away or otherwise
transform them in intersting ways. If the compiler had to worry someone was
going to check in on their value in a way not visible at compile time, the
compiler could not turn
(let ((x 1)) (+ x x))
into the constant 2 for fear that someone would try to get a breakpoint in
there and see the value of x, which is really only a coding-time variable
and has no place in the running form of a compiled program.
Old-style EVAL used to cause myriad program errors as did FEXPR's, which
were how we used to implement special forms. (Usually we'd have to call
EVAL but there was no way to pick up the argument without cluttering the
argument space. e.g.,
(defun prog1 fexpr (x) ;x gets cdr of the prog1 form
(let ((val1 (eval (car x))))
(mapcar 'eval (cdr x))
val1))
might implement a fexpr named prog1 in Maclisp. Unfortunately, if someone
wrote (let ((x 4)) (prog1 (+ x 1) (print 'foo)))
the result might be surprising becuase the prog1 captures the x and
you end up calling (eval '(+ x 1)) in an environment where x is
((+ x 1) (print 'foo)) instead of one where x is 4.
It was a major step forward, and not one we need to go back on, to get
rid of the ability of EVAL to invade private program data.
We still have the ability to export data in a running program (using
a SPECIAL declaration) so that it _is_ voluntarily accessible to EVAL.
But only one person can win--the writer of the private code or the writer
of the privacy-invading code. And we made the decision that it will be
the writer of the private code.
There is only one other case, and that's the option of a special form,
not a function, that does EVAL. That is. One where the compiler can
tell lexically what you are trying to EVAL so it can know what you ar
depending on. In that case you'd do
(lexical-eval (+ x 3))
not
(lexical-eval '(+ x 3))
becuase the form to evaluate would not be a variable. But unfortunately,
if you know what you want to eval, you might as well just say
(+ x 3)
since the form is not evaluable in the first place. So that doesn't
need to work either.
Conclusion: Lexical eval may look like a concept worth pursuing, but it
really is not. Not even as an option. Especially not as an option.
It is antithetical to fixed decisions already made in the language.
Kenny Tilton <·······@nyc.rr.com> writes:
> Justin Dubs wrote:
> > Can anyone, or you
> > yourself Kent, recommend a site with some manner of biography. I am
> > interested in knowing what you [Kent, right? <kt>] have contributed to the Lisp world.
>
> He contributed Lisp!!!!!
I appreciate the kudos but this is a little extreme and I've got to
set the record straight. It may look like I did that, but if so it's
just cleer mirrors and camera angles. Lisp was there before me
certainly. And the part that has my name on it is a group project.
Kathy Chapman worked the first couple of years as Project Editor for
ANSI CL getting it going, until it was clear it needed someone who was
a Lisp user to finish the work. I volunteered. With help from Franz,
who found funding, I directed my full time energy to finishing the
text of the spec from 1990 to 1994, and another year after managing
political hassles behind the scenes to get ANSI CL published.
I also had a lot of technical help. Some big pieces like LOOP and CLOS
were written wholesale by other subgroups, and though I certainly had
my opinions on it when it came to adopt it in the committee as a whole,
those opinions were probably in the noise. I mostly just merged their text
with the look and feel of the standard; I didn't do the design myself.
> OK, McCarthy gets some credit, as do a few
> other folks.
Quite a number. Please see the CLHS credits. Being author means the
text was on my disk for several years, that I published about 5 cubic
feet of drafts, that about as many cubic feet of paper with red marks
on it came back for me to fix. It means many thousands, perhaps
several tens of thousands of emails went by that I had to track. I did
a lot of stuff in that time. But I didn't create ANSI CL myself; I was
one of several people with various roles in coordinating its creation.
(It also wasn't a revenue generating activity, and when Symbolics was
due to go Chapter 11, they realized I wasn't in the critical path, and
laid me off because of it. So I incurred some personal career risk
for doing it. Fortunately, then-Harlequin scooped me up and let me
continue the work from their offices, and the project completed.)
(Ironically, Jo Marks hired me to then-Harlequin to be a lead in Dylan
design work, but then when push came to shove, he wasn't willing to
grant me any actual management authority. His attitude seemed to be
that people shouldn't tell other people what to do, and that if the
community didn't automatically accord me whatever respect I needed tog
et the job done, then I probably didn't deserve it. (This may or may
not have been a reasonable theory in that case, but as a general
theory neglects the possibility that the community in question is
sheltered from important knowledge that would change its view.) The
practical effect was that every time I got into a discussion on any
technical topic, it happened there what happened in this conversation
earlier, with someone new saying "teach me" and "explain yourself"
instead of simply accepting things I suggeted doing. I quickly
realized that if I had any wisdom to offer [always questionable to
start with], it would be squandered on having to explain everything
and we'd get no tactical advantage to my experience in just being able
to leap to an immediate conclusion on the basis of an experience
credential. So, lacking any internal community consensus that I had
the appropriate credential to guide them, I bowed out of the process
and disassociated myself with the Dylan effort internally to
then-Harlequin, figuring it was better that they just learned the
stuff on their own than waste my time. And that's what freed me to
have enough time to work on ANSI CL, which I might not have had time
for if I'd continued working on Dylan. Not trying to moralize about
who was right there; just trying to explain how it played out.)
> We are lucky here on c.l.l. to have a few regulars who
> were there when Common Lisp was formed. It is so cool to whine about
> some language feature and then have one of these folks jump in with
> "well, the reason we went the way we did on that was yada yada yada".
The committee started with about 60 of us in 1986 or so, and I think
about 10 of us remained by 1994 when the project more or less wound down.
I do agree much of interest happened in the back rooms and that's why I
like to be around to tell the tales. Usenet is perhaps not the best tool
for entering something into the historical record, but hopefully the
combination of that and your various individual memories will help some
kinds of knowledge and impressions to survive we who were there as
individuals and will one day be gone.
······@eos.ncsu.edu (Justin Dubs) writes:
> My interests seem to lie in the fields of language design and, more
> in general, in creating tools to help programmers do their jobs
> better, and faster.
So language design is an interesting field. (I lean that way myself
many days.) But the history of Lisp has shown us that if one cares
about programmers actually *having* the tools to do their jobs better
and faster (as opposed to just creating new tools that no one uses)
then it might be better to put one's energy into figuring out why most
programmers don't get to use the better tools that already exist. Such
as Common Lisp.
In other words, if you believe that Common Lisp is, on balance, a
better tool than most of the languages that are commonly used to
develop software these days *and* you want to create better tools for
programmers, it seems your project is doomed to failure unless you can
figure out why your better tools are going to have significantly
better adoption than Lisp. Which is probably more of a social and
psychological problem than a technical one though there may be
technical parts to an answer.
Part of the basis for the response you've gotten here might be due to
a feeling that if more of the folks who pop in here and say, "Lisp is
great, I really love it but I'm going to go invent my own new language
that is going to be like Lisp but different in some obscure technical
way" had stuck around and put that energy into Lisp itself--writing
high-quality libraries, writing new apps in it, learning it well and
becoming and advocate for its use--then there'd probably be more
programmers actually using the existing better tools.
> In Common Lisp, the following won't work:
>
> (let ((x 1))
> (eval '(print x)))
>
> It will scold you first about the unused lexical variable, x, and
> then about the unbound variable, x.
>
> I'm hoping that that won't be true with my Lisp dialect.
My Lisp dialect (Common Lisp) already supports that:
(let ((x 1))
(declare (special x))
(eval '(print x)))
> I have ideas for a new type-system. Optional static typing with
> ML-style type-inference, combined with a good
> pattern-matching/argument deconstruction system.
So Lisp has the later. And the former up to a point. What makes these
features incompatible with Common Lisp? I.e. why can't you add them to
an existing Lisp implementation?
> Ah, yes, and syntax. Run-time modifiable, embeddable syntax,
> translated dynamically into s-expressions.
>
> I suppose my goal, as far-fetched as it sounds, is to have a dynamic
> Lisp core, on top of which I can program in a more ML-like way.
>
> I can dream, can't I. :-)
Live the dream. If you really want to play around with language
design, you could do far worse than to build it on top of the existing
Lisp core. Depending how far away from sexps your syntax is you may
even be able to use the lisp reader. But if not, write a parser for
your language that turns stuff into sexps and then go to town
compiling them into Lisp.
> As far as the new features for the App Dev guy, I don't really know
> what I'd be able to offer that he can't get in other ways. Atleast
> nothing new that he would want. As far as "why bother": Because I
> can. Because it interests me. If I come up with a better idea, or
> lose interest in this one, I'll stop.
So this is where we loop back around to the question of following
one's bliss versus listening to the wisdom of those who have gone
before you. Suppose we were all baseball players. And suppose you
said, "I'm working on a new hitting technique in which I swing the bat
with only one hand because I think that'll help me start running to
first base faster." And some wise old batting coach says, "Well, son,
that might work. But I've seen other guys try it and they always end
up coming back to swinging the bat with two hands. So if you really
want to be a big-league ball player you'll spend your time working on
batting with two hands. Because while you're working on your
one-handed technique, the other guys are getting better and come
summer, you might not make the cut." Now, there's some possibility
that you've got an insight that the old coach doesn't and you might
revolutionize the game. But there's also a pretty good possibility
that he's right and time you spend trying to hit with one hand is time
that you're *not* learning other valuable skills.
I'm sure you'll learn something following your current path. The
question is what aren't you learning in the meantime.
-Peter
--
Peter Seibel ·····@javamonkey.com
The intellectual level needed for system design is in general
grossly underestimated. I am convinced more than ever that this
type of work is very difficult and that every effort to do it with
other than the best people is doomed to either failure or moderate
success at enormous expense. --Edsger Dijkstra
Peter Seibel <·····@javamonkey.com> wrote in message news:<··············@localhost.localdomain>...
> ······@eos.ncsu.edu (Justin Dubs) writes:
> [...] In other words, if you believe that Common Lisp is, on balance, a
> better tool than most of the languages that are commonly used to
> develop software these days *and* you want to create better tools for
> programmers, it seems your project is doomed to failure unless you can
> figure out why your better tools are going to have significantly
> better adoption than Lisp. Which is probably more of a social and
> psychological problem than a technical one though there may be
> technical parts to an answer.
I would guess that a lot of it is technical. The lack of a good,
standard FFI. The lack of built in bindings to make use of the
UNIX/POSIX, X11, and Win32 API's. The lack of a common, portable
implementation of Lisp. I think that all of these things, in
combination with some social and psychological factors, contribute to
Lisp not getting much play in big business.
> > In Common Lisp, the following won't work:
> >
> > (let ((x 1))
> > (eval '(print x)))
> >
> > It will scold you first about the unused lexical variable, x, and
> > then about the unbound variable, x.
> >
> > I'm hoping that that won't be true with my Lisp dialect.
>
> My Lisp dialect (Common Lisp) already supports that:
>
> (let ((x 1))
> (declare (special x))
> (eval '(print x)))
This isn't really working. By declaring x to be special, you have
transformed it from a lexical variable to a dynamic variable, thus
giving it global scope. The entire reason that I used a let-construct
in my example was to give x local scope. Atleast, that's my
understanding of "special" from CLHS 3.3.
> Live the dream. If you really want to play around with language
> design, you could do far worse than to build it on top of the existing
> Lisp core. Depending how far away from sexps your syntax is you may
> even be able to use the lisp reader. But if not, write a parser for
> your language that turns stuff into sexps and then go to town
> compiling them into Lisp.
I am, more or less, considering this as a possibility. First I want
to get a basic lisp interpreter up and running, mostly as a learning
experience.
> I'm sure you'll learn something following your current path. The
> question is what aren't you learning in the meantime.
This is a tremendously good point, and one that I will give a lot of
consideration to. Thank you for pointing it out.
> -Peter
Justin Dubs
······@eos.ncsu.edu (Justin Dubs) writes:
> Peter Seibel <·····@javamonkey.com> wrote in message news:<··············@localhost.localdomain>...
> > ······@eos.ncsu.edu (Justin Dubs) writes:
> > [...] In other words, if you believe that Common Lisp is, on balance, a
> > better tool than most of the languages that are commonly used to
> > develop software these days *and* you want to create better tools for
> > programmers, it seems your project is doomed to failure unless you can
> > figure out why your better tools are going to have significantly
> > better adoption than Lisp. Which is probably more of a social and
> > psychological problem than a technical one though there may be
> > technical parts to an answer.
>
> I would guess that a lot of it is technical. The lack of a good,
> standard FFI. The lack of built in bindings to make use of the
> UNIX/POSIX, X11, and Win32 API's.
Without getting into whether each of those things may or may not be
available from various implementations, I take you point--to a point.
I think if you really *are* interested in putting better tools in the
hand of programmers, you'd attack *these* problems. Go help out the
UFFI guys. Or write a POSIX API and post it here and get some feedback
from our elder statesmen (not me!). But a new lisp-like language isn't
going to have these things until quite a bit of work has been done.
I'm not saying that there are no other good reasons to implement your
own language. But you should probably stop saying you're doing it
because you want programmers to have better tools.
> The lack of a common, portable implementation of Lisp.
So that one's going to raise some hackles around here. The whole
*point* of all the work that Kent and others did on standardizing
Common Lisp was to allow programmers to not have to pick a single
implementation. If you follow the standard (as a Lisp programmer) your
programs will run on *any* conforming implementation. But that said
there are at least two implementations, one free (gratis *and* libre)
and one commercial that are portable to a wide variety of unices,
Windows, and Mac OS X: CLISP and Allegro Common Lisp. (I actually sort
of agree with you--I suspect that these days lots of people are
happier with languages that are standardized via a single
implementation rather than via an actual standard. But I'm not sure
why that is other than that's what they're used to if they cut their
teeth on Perl, Python, Java.)
> > > In Common Lisp, the following won't work:
> > >
> > > (let ((x 1))
> > > (eval '(print x)))
> > >
> > > It will scold you first about the unused lexical variable, x, and
> > > then about the unbound variable, x.
> > >
> > > I'm hoping that that won't be true with my Lisp dialect.
> >
> > My Lisp dialect (Common Lisp) already supports that:
> >
> > (let ((x 1))
> > (declare (special x))
> > (eval '(print x)))
>
> This isn't really working. By declaring x to be special, you have
> transformed it from a lexical variable to a dynamic variable, thus
> giving it global scope.
Nope. That's not how it works.
CL-USER(2412): (let ((x 1)) (declare (special x)) (eval '(print x)))
1
1
CL-USER(2413): (boundp 'x)
NIL
A special variable means it has dynamic scope, not that it's a global
variable. Global variables are all special (i.e. dynamic), but not
vice versa.
> The entire reason that I used a let-construct in my example was to
> give x local scope. Atleast, that's my understanding of "special"
> from CLHS 3.3.
I'm not sure 'local scope' is a term the spec uses. (Could be wrong.)
There's lexical scope and dynamic scope. LET forms can establish
bindings in both kinds of scope. Lookup dynamic scope in the glossary
and follow all the links mentioning "dynamic", "lexical", "scope", and
"extent", recursively. Repeat until your head shrinks back to its
normal size. It's not actually too terribly complicated but--at least
for me--it took some doing to get it all straight in my head.
> > Live the dream. If you really want to play around with language
> > design, you could do far worse than to build it on top of the
> > existing Lisp core. Depending how far away from sexps your syntax
> > is you may even be able to use the lisp reader. But if not, write
> > a parser for your language that turns stuff into sexps and then go
> > to town compiling them into Lisp.
>
> I am, more or less, considering this as a possibility. First I want
> to get a basic lisp interpreter up and running, mostly as a learning
> experience.
Then you should definitely read, _Lisp In Small Pieces_. Read it and
go implement a Scheme (everyone else does) and get it out of your
system. ;-) Then come back and help us bring Common Lisp to its
rightful place in the world.
-Peter
--
Peter Seibel ·····@javamonkey.com
The intellectual level needed for system design is in general
grossly underestimated. I am convinced more than ever that this
type of work is very difficult and that every effort to do it with
other than the best people is doomed to either failure or moderate
success at enormous expense. --Edsger Dijkstra
In article <··············@localhost.localdomain>, Peter Seibel
<·····@javamonkey.com> wrote:
> I suspect that these days lots of people are
> happier with languages that are standardized via a single
> implementation rather than via an actual standard. But I'm not sure
> why that is other than that's what they're used to if they cut their
> teeth on Perl, Python, Java.
I suspect it's because reading a standard is much harder than just trying
something to see if it works.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <··············@localhost.localdomain>, Peter Seibel
> <·····@javamonkey.com> wrote:
>
> > I suspect that these days lots of people are
> > happier with languages that are standardized via a single
> > implementation rather than via an actual standard. But I'm not sure
> > why that is other than that's what they're used to if they cut their
> > teeth on Perl, Python, Java.
>
> I suspect it's because reading a standard is much harder than just trying
> something to see if it works.
Too bad just seeing if something works doesn't tell you if it works.
Kent M Pitman <······@world.std.com> writes:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <··············@localhost.localdomain>, Peter Seibel
> > <·····@javamonkey.com> wrote:
> >
> > > I suspect that these days lots of people are
> > > happier with languages that are standardized via a single
> > > implementation rather than via an actual standard. But I'm not sure
> > > why that is other than that's what they're used to if they cut their
> > > teeth on Perl, Python, Java.
> >
> > I suspect it's because reading a standard is much harder than just trying
> > something to see if it works.
>
> Too bad just seeing if something works doesn't tell you if it works.
... or that you can count on it working in the future...
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
In article <·············@beta.franz.com>, Duane Rettig <·····@franz.com> wrote:
> Kent M Pitman <······@world.std.com> writes:
>
> > ···@jpl.nasa.gov (Erann Gat) writes:
> >
> > > In article <··············@localhost.localdomain>, Peter Seibel
> > > <·····@javamonkey.com> wrote:
> > >
> > > > I suspect that these days lots of people are
> > > > happier with languages that are standardized via a single
> > > > implementation rather than via an actual standard. But I'm not sure
> > > > why that is other than that's what they're used to if they cut their
> > > > teeth on Perl, Python, Java.
> > >
> > > I suspect it's because reading a standard is much harder than just trying
> > > something to see if it works.
> >
> > Too bad just seeing if something works doesn't tell you if it works.
>
> ... or that you can count on it working in the future...
Indeed. :-( But I think this is just a reflection of people's general
attitude towards quality. (Zen and the Art of Motorcycle Maintenance
anyone?) People just seem not to care. People want things to be shiny
and glitzy and easy (hence the popularity of GUIs) but they don't give a
damn about reliability. Hence the popularity of Microsoft, and the
unpopularity of standards. It's sad, but that's the way it is.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <·············@beta.franz.com>, Duane Rettig <·····@franz.com> wrote:
>
> > Kent M Pitman <······@world.std.com> writes:
> >
> > > ···@jpl.nasa.gov (Erann Gat) writes:
> > >
> > > > In article <··············@localhost.localdomain>, Peter Seibel
> > > > <·····@javamonkey.com> wrote:
> > > >
> > > > > I suspect that these days lots of people are
> > > > > happier with languages that are standardized via a single
> > > > > implementation rather than via an actual standard. But I'm not sure
> > > > > why that is other than that's what they're used to if they cut their
> > > > > teeth on Perl, Python, Java.
> > > >
> > > > I suspect it's because reading a standard is much harder than just trying
> > > > something to see if it works.
> > >
> > > Too bad just seeing if something works doesn't tell you if it works.
> >
> > ... or that you can count on it working in the future...
>
> Indeed. :-( But I think this is just a reflection of people's general
> attitude towards quality. (Zen and the Art of Motorcycle Maintenance
> anyone?) People just seem not to care. People want things to be shiny
> and glitzy and easy (hence the popularity of GUIs) but they don't give a
> damn about reliability. Hence the popularity of Microsoft, and the
> unpopularity of standards. It's sad, but that's the way it is.
Not for everyone.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
···@jpl.nasa.gov (Erann Gat) wrote in message news:<····················@dialin-102.jpl.nasa.gov>...
> In article <·············@beta.franz.com>, Duane Rettig <·····@franz.com> wrote:
> > > Too bad just seeing if something works doesn't tell you if it works.
> >
> > ... or that you can count on it working in the future...
>
> Indeed. :-( But I think this is just a reflection of people's general
> attitude towards quality. (Zen and the Art of Motorcycle Maintenance
> anyone?)
Ah yes, that reminds me: then there are those who won't use a piece of
aluminum that makes a perfectly good shim, due to some purity issues.
Duane Rettig <·····@franz.com> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > ···@jpl.nasa.gov (Erann Gat) writes:
> >
> > > In article <··············@localhost.localdomain>, Peter Seibel
> > > <·····@javamonkey.com> wrote:
> > >
> > > > I suspect that these days lots of people are
> > > > happier with languages that are standardized via a single
> > > > implementation rather than via an actual standard. But I'm not sure
> > > > why that is other than that's what they're used to if they cut their
> > > > teeth on Perl, Python, Java.
> > >
> > > I suspect it's because reading a standard is much harder than just trying
> > > something to see if it works.
> >
> > Too bad just seeing if something works doesn't tell you if it works.
>
> ... or that you can count on it working in the future...
Right. Well, there are several axes to this:
(1) Testing the code doesn't assure you tested it.
e.g., Suppose I think < means numerical compare in a bash shell script.
I do
x=1
y=2
if [ "$x" "<" "$y" ]; then
echo "you understand"
else
echo "you're confused"
fi
and find that I understand. Even though I'm doing string compare.
Too bad I didn't test values 9 and 10 instead.
(2) Knowing that the code works today doesn't assure it will work tomorrow.
I might do:
(if (= (random 2) 1) 'win 'lose)
to assure myself that RANDOM always returns 1, and it might say yes.
That doesn't mean it will tomorrow.
(3) Knowing that the code works repeatedly doesn't assure it does what you
intend.
I recall a famous case with perceptrons where they taught one to recognize
tanks. It got very good in tests but lost in the field. Eventually
they discovered that it was recognizing time of day. (The test photos
all had tanks in the morning and non-tanks in the afternoon.)
This variability is why I don't care much about arguments that say
we should emphaisze "testing correctness by running the program".
I think that just encourages bad testing techniques.
+ Kent M Pitman <······@world.std.com>:
| (1) Testing the code doesn't assure you tested it.
Indeed. Perhaps more disconcerting, running an experiment to check
your understanding of the specification doesn't prove you understood
it. Case in point: CMUCL produces the following results:
(loop for i below 5
do (format t "~D " i)
finally (format t "finally ~D~%" i))
-> 0 1 2 3 4 finally 5
(loop for a on '(a b c d e)
do (format t "~A " a)
finally (format t "finally ~A~%" a))
-> (A B C D E) (B C D E) (C D E) (D E) (E) finally NIL
(loop for (a . more) on '(a b c d e)
do (format t "~A " a)
finally (format t "finally ~A~%" a))
-> A B C D E finally E
(loop for (a . more) on '(a b c d e)
while more
do (format t "~A " a)
finally (format t "finally ~A~%" a))
-> A B C D finally E
I am still not sure if none, any, or all of the above must produce
these results in a conforming lisp. My intuition says the first three
are suspect, while the final example ought to be OK. I guess it's a
question of whether assignment is done before or after the termination
test. In particular, the second and the third examples seem mutually
inconsistent to me, in that the assignment to (a . more) evidently
takes place after the termination test, while the assignment to a in
the second example equally evidently happens before the termination
test. I can think of lots of reasons why an implementation would
choose to do it this way, but whether or not CL mandates it I cannot
tell from my browsing of the Hyperspec.
In the final example, I think I am on safe ground because my own
termination test will trigger before loop's built-in test, so I have
control over the order of execution where it matters. (I have some
code depending on this, so I hope I am right.)
(Hmm, my signature seems especially appropriate today.)
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Yes it works in practice - but does it work in theory?
Harald Hanche-Olsen <······@math.ntnu.no> writes:
> (loop for (a . more) on '(a b c d e)
> while more
> do (format t "~A " a)
> finally (format t "finally ~A~%" a))
>
> -> A B C D finally E
>
> I am still not sure if none, any, or all of the above must produce
> these results in a conforming lisp.
The last one is OK, but the other ones are undefined. The value of an
iteration variable after the iteration has terminated is undefined
(there's nothing in the standard that defines it).
We last had an argument about this two years ago
<http://groups.google.com/groups?threadm=vwWs4.59%24VM6.2271%40burlma1-snr2>.
Also, just two weeks ago, we discussed DOLIST result form (under
subject "dolist type declaration"), which is an analoguous situation.
--
Pekka P. Pirinen
This article printed on 100% recycled electrons.
From: Johann Hibschman
Subject: Re: Help understanding closures
Date:
Message-ID: <m2y93dfc2s.fsf@yahoo.com>
···············@globalgraphics.com (Pekka P. Pirinen) writes:
> The last one is OK, but the other ones are undefined. The value of an
> iteration variable after the iteration has terminated is undefined
> (there's nothing in the standard that defines it).
Hm. As a specific application, I just wrote
(defun iterate-call (n f x0)
"Apply the Nth iterate of F to x0"
(loop for i upto n
for x = x0 then (funcall f x)
finally return x))
Is the behavior of this undefined, according to the spec? Or is it
defined, since the for-as-equals-then clause never officially
"terminates"?
Thanks,
--Johann
Johann Hibschman <··········@yahoo.com> writes:
> (defun iterate-call (n f x0)
> "Apply the Nth iterate of F to x0"
> (loop for i upto n
> for x = x0 then (funcall f x)
> finally return x))
Sidestepping your question:
initial-final::= initially compound-form+ | finally compound-form+
so (return x) must be parenthesized.
Not so long ago I read about people using genetic techniques to program
an FPGA to oscillate. It finally oscillated. When they analyzed the
result, they found the FPGA had become a radio receiver and was
amplifying an oscillating signal from a nearby computer.
Kent M Pitman wrote:
> intend.
> I recall a famous case with perceptrons where they taught one to recognize
> tanks. It got very good in tests but lost in the field. Eventually
> they discovered that it was recognizing time of day. (The test photos
> all had tanks in the morning and non-tanks in the afternoon.)
>>>>> "Kent" == Kent M Pitman <······@world.std.com> writes:
Kent> This variability is why I don't care much about arguments that
Kent> say we should emphaisze "testing correctness by running the
Kent> program". I think that just encourages bad testing techniques.
Oh boy do I hear you! This is something I try to explain to my
co-workers, but they just can't seem to grasp the idea that running a
program once successfully does not mean its tested.
At one stage I was asked to do some testing of a co-workers code. I
did the testing and supplied him with about 20 pages of errors. He
couldn't believe it and asked me what I did. I told him "Well, I tried
to break it and this documents all the ways I was able to do it".
Nobody at work asks me to test anything anymore - which suits
me. Testing is a drag, but it is essential. I don't think you
should test to see if it works, you should test to see how it doesn't
work. If I give someone something to test and they come back with a
boot load of errors, I'm actuallly quite pleased. It often opens my
eyes to things I'd missed because I was too close to the problem and
it means there will be a boot load less errors when I'm finally
finished (though the old boot of errors will probably be replaced by a
new boot full.
The story about the app used to spot tanks which was flawed because of
poorly selected training sets (I think it was a neural network?) and
insufficient testing reminds me of the one I heard about here in
Australia - again related to the military. It involved a flight
simulator and a demonstration to some visiting US military folk. In a
rush to get the simulator finished, the development team pinched some
code from an infintry fight simulator. The soldiers were replaced by
icons representing kangaroos and in testing it all looked fine. When
the US military guys tried it out, they decided to buzz a mob of
kangaroos just for fun. They were very serprised when the roos pulled
out missile launches and blew them out of the sky!
The developers hadn't tested very well - simply changed the icons and
added some "flocking" routines to control the movement - noboby
realised the code relating to hostile attack response was still
included.
Tim
--
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you
really need to send mail, you should be able to work it out!
Tim X <····@spamto.devnul.com> wrote:
> At one stage I was asked to do some testing of a co-workers code. I
> did the testing and supplied him with about 20 pages of errors. He
> couldn't believe it and asked me what I did. I told him "Well, I
> tried to break it and this documents all the ways I was able to do
> it".
On one project I worked on, one of the members of the team had a
"black thumb" --- he could break almost any piece of code or
documentation. He had a kind of skewed way of looking at the world
which meant he would always do things differently from what you would
expect. Not deliberately, he just had that kind of mind.
I considered him one of the more valuable members of the team.... :-)
--
Fred Gilham ······@csl.sri.com
The rage of dance and style that swept the country in the late '70s
crumbled from serious backlash as disco freaks seemed to finally wake
up and realize what they were wearing. -- Michael Okwu
Fred Gilham wrote:
> Tim X <····@spamto.devnul.com> wrote:
>
>>At one stage I was asked to do some testing of a co-workers code. I
>>did the testing and supplied him with about 20 pages of errors. He
>>couldn't believe it and asked me what I did. I told him "Well, I
>>tried to break it and this documents all the ways I was able to do
>>it".
>
>
> On one project I worked on, one of the members of the team had a
> "black thumb" --- he could break almost any piece of code or
> documentation. He had a kind of skewed way of looking at the world
> which meant he would always do things differently from what you would
> expect. Not deliberately, he just had that kind of mind.
>
> I considered him one of the more valuable members of the team.... :-)
>
On my first big design project I was assigned three programmers, one of
whom hated me after I suggested she keep a page of notes for her FAQs
(after she asked one of them for about the fourth time).
Anyway, she turned out be useless so got no coding responsibility, ended
up testing the software. Every few minutes she would yell out Ha! and
gleefully document some new bug. The first few whoops got under my skin,
then I realized the whole situation was a dream come true.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
Duane Rettig <·····@franz.com> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > ···@jpl.nasa.gov (Erann Gat) writes:
> >
> > > In article <··············@localhost.localdomain>, Peter Seibel
> > > <·····@javamonkey.com> wrote:
> > >
> > > > I suspect that these days lots of people are
> > > > happier with languages that are standardized via a single
> > > > implementation rather than via an actual standard. But I'm not sure
> > > > why that is other than that's what they're used to if they cut their
> > > > teeth on Perl, Python, Java.
> > >
> > > I suspect it's because reading a standard is much harder than just trying
> > > something to see if it works.
> >
> > Too bad just seeing if something works doesn't tell you if it works.
>
> ... or that you can count on it working in the future...
Although, ironically, you're probably far better off on this front in
Lisp than in Perl. I mean, we're talking about a language that added
setf methods, but kept rplaca! Perl has no such notions of placing
value on stability (ever tried to port something from early Perl5 to
later Perl5?).
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Tim Bradshaw
Subject: Re: Help understanding closures
Date:
Message-ID: <ey3n0jzwn1w.fsf@cley.com>
* Peter Seibel wrote:
> So that one's going to raise some hackles around here. The whole
> *point* of all the work that Kent and others did on standardizing
> Common Lisp was to allow programmers to not have to pick a single
> implementation. If you follow the standard (as a Lisp programmer) your
> programs will run on *any* conforming implementation. But that said
> there are at least two implementations, one free (gratis *and* libre)
> and one commercial that are portable to a wide variety of unices,
> Windows, and Mac OS X: CLISP and Allegro Common Lisp.
Other than MacOS X (I don't know how hard the port of the GUI would
be, I think they already run on the correct processor and presumably
MacOS X looks enough like Unix that the non-GUI parts of a port would
not be hideously difficult) LispWorks also meets this criteria (it
might not run on so many Unices, I'm not sure). And, hey, it has a
portable GUI API too!
I'm not trying to push LW - the point is that there are in fact a fair
number of relatively portable implementations of CL which cover the
common platforms (really: windows and the common Unixoid systems),
including two commercially supported, native code, implementations.
The lack of portable implementations has not been a problem for CL
these 10 years.
--tim
Peter Seibel <·····@javamonkey.com> writes:
> If you follow the standard (as a Lisp programmer) your programs will run on
> *any* conforming implementation. But that said there are at least two
> implementations, one free (gratis *and* libre) and one commercial that are
> portable to a wide variety of unices, Windows, and Mac OS X: CLISP and
> Allegro Common Lisp. (I actually sort of agree with you--I suspect that
> these days lots of people are happier with languages that are standardized
> via a single implementation rather than via an actual standard. But I'm not
> sure why that is other than that's what they're used to if they cut their
> teeth on Perl, Python, Java.)
Is it maybe because your standard conforming common lisp program can just
about read and write (English) text and maybe binary files, whereas a
(more-or-less single-implemention standardized) python program can actually
accomplish something useful (multithreaded, guied, networked, deployable
etc. on multiple platforms and localized, for free)?
alex
Alexander Schmolck <··········@gmx.net> writes:
> Peter Seibel <·····@javamonkey.com> writes:
>
> > If you follow the standard (as a Lisp programmer) your programs
> > will run on *any* conforming implementation. But that said there
> > are at least two implementations, one free (gratis *and* libre)
> > and one commercial that are portable to a wide variety of unices,
> > Windows, and Mac OS X: CLISP and Allegro Common Lisp. (I actually
> > sort of agree with you--I suspect that these days lots of people
> > are happier with languages that are standardized via a single
> > implementation rather than via an actual standard. But I'm not
> > sure why that is other than that's what they're used to if they
> > cut their teeth on Perl, Python, Java.)
>
> Is it maybe because your standard conforming common lisp program can
> just about read and write (English) text and maybe binary files,
> whereas a (more-or-less single-implemention standardized) python
> program can actually accomplish something useful (multithreaded,
> guied, networked, deployable etc. on multiple platforms and
> localized, for free)?
Well, there's somethnig to that--but that's not due to their being a
single implementation. That's because Python has a large (de facto)
standard library that contains code for doing lots of thing that are
important today. Java, although not standardized, has a formal
specification (written in part by Lisp's own Guy Steele) and there are
multiple implementations. But it too has a huge standard library,
similar to what Python offers.
If Lisp vendors (including the authors of the open/free lisps) and/or
the Lisp community wants Lisp to compete with Python and Java in that
realm (which I think would be great) then they and/or we could write
and organize and make easily available a similar set of libraries for
Lisp. And there are efforts along those lines: the CLOCC[1], Franz's
open source collection[2] and the set of miscelaneous libraries listed
on the Cliki[3]. Similarly the UFFI effort[4] points in a good
direction for maybe having a portable FFI. Standardized (de facto or
de jure) threading seems the farthest away. But Perl *and* Python
gained most of their popularity long before they had multithreading.
-Peter
[1] <http://clocc.sourceforge.net/>
[2] <http://opensource.franz.com/>
[3] <http://www.cliki.net/Library>
[4] <http://uffi.med-info.com/>
--
Peter Seibel ·····@javamonkey.com
The intellectual level needed for system design is in general
grossly underestimated. I am convinced more than ever that this
type of work is very difficult and that every effort to do it with
other than the best people is doomed to either failure or moderate
success at enormous expense. --Edsger Dijkstra
> > ······@eos.ncsu.edu (Justin Dubs) writes:
> > > (let ((x 1))
> > > (eval '(print x)))
> Peter Seibel <·····@javamonkey.com> wrote
> > (declare (special x))
> > (eval '(print x)))
······@eos.ncsu.edu (Justin Dubs) writes:
> This isn't really working. By declaring x to be special, you have
> transformed it from a lexical variable to a dynamic variable, thus
> giving it global scope. The entire reason that I used a let-construct
> in my example was to give x local scope. Atleast, that's my
> understanding of "special" from CLHS 3.3.
Try this:
(let ((x 1))
(eval `(print ,x)))
--
Hilsen
Johan Ur Riise
Johan Ur Riise <·@rsc.no> wrote:
+---------------
| > > ······@eos.ncsu.edu (Justin Dubs) writes:
| > > > (let ((x 1))
| > > > (eval '(print x)))
| > Peter Seibel <·····@javamonkey.com> wrote
| > > (declare (special x))
| > > (eval '(print x)))
| ······@eos.ncsu.edu (Justin Dubs) writes:
| > This isn't really working. By declaring x to be special, you have
| > transformed it from a lexical variable to a dynamic variable, thus
| > giving it global scope. The entire reason that I used a let-construct
| > in my example was to give x local scope. Atleast, that's my
| > understanding of "special" from CLHS 3.3.
|
| Try this:
| (let ((x 1))
| (eval `(print ,x)))
+---------------
Uh... That may "work" when X contains a number (like 1) or some other
self-evaluating object (e.g., vectors, strings), but not for conses
or symbols:
(let ((x 'y))
(eval `(print ,x)))
==> #<ERROR: Variable Y is unbound>
-Rob
-----
Rob Warnock, PP-ASEL-IA <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) writes:
> (let ((x 'y))
> (eval `(print ,x)))
> ==> #<ERROR: Variable Y is unbound>
Anyone who's written a macro knows the answer to this one:
(let ((x 'y))
(eval `(print ',x)))
But for me the interesting perspective is this:
(let ((form '(print x)))
(let ((x 'y))
(eval form)))
Because if the argument to eval is a literal form, then it's all very
uninteresting as the solution is to just remove the wrapping
eval. Now, to make the above form work via lexical binding, there must
be established a lexical connection between the x in the form that
binds x and the x in the '(print x) literal. A lexical connection to
something that is outside the lexical scope of the variable. I can't
for the life of me see how this makes any sense whatsoever, either
conceptually or technically.
--
Frode Vatvedt Fjeld
······@eos.ncsu.edu (Justin Dubs) wrote in message news:<····························@posting.google.com>...
> HLL's trade speed for flexibility, in general. I'm going to try and
> go a bit further with that idea, for the sake of experimentation. In
> Common Lisp, the following won't work:
>
> (let ((x 1))
> (eval '(print x)))
It's not actually clear what "work" means. Consider the following:
(let* ((x 2)
(p '(print x)))
(let ((x 1))
(eval p)))
(let ((p '()))
(let ((x 2))
(setq p '(print x)))
(let ((x 1))
(eval p)))
If the "right" answer for the first example is necessarily 1, the
right answer for the my two examples is probably 2, and that's a
huge problem.
A more reasonable approach is to realize that eval doesn't have
enough information, that it can't dynamically acquire its caller's
static environment.
Another way to the same conclusion is to consider what "should" happen
if the eval'd code happens to use a variable with the same name as
one in eval's definition.
Justin Dubs wrote:
> Well, no, it wasn't actually. Lisp was designed to be a
> mathematically sound, easier-to-use replacement for the Turing
> machine. It wasn't even meant to be a viable computer language until
> one of McCarthy's students noticed that if you implemented Lisp's eval
> in machine language, than you would have written a Lisp interpreter.
> He did this, and off Lisp went.
This is not true.
http://www-formal.stanford.edu/jmc/history/lisp/lisp.html
from this document:
"The implementation of LISP began in Fall 1958. The original idea was to
produce a compiler, but this was considered a major undertaking, and we
needed some experimenting in order to get good conventions for subroutine
linking, stack handling and erasure. Therefore, we started by
hand-compiling various functions into assembly language and writing
subroutines to provide a LISP "environment". These included programs to
read and print list structure. I can't now remember whether the decision to
use parenthesized list notation as the external form of LISP data was made
then or whether it had already been used in discussing the paper
differentiation program."
What you refer to is maybe the following note:
"S.R. Russell noticed that eval could serve as an interpreter for LISP,
promptly hand coded it, and we now had a programming language with an
interpreter."
But this fact does in *no* way imply that there was no intention to make
lisp a "viable computer language". In the above document McCarthy describes
that he considered it important to make Lisp obey the usual mathematical
laws as far as practically possible.
ciao,
Jochen
In article <····························@posting.google.com>,
······@eos.ncsu.edu (Justin Dubs) wrote:
> Yes, but I am not writing "another Lisp interpreter." It does happen
> to be a dialect of Lisp in that, at the core, it is based off of
> S-Expressions. However, I'm leaning towards a handful of large-ish
> changes. For one, ML-style type-inference. For another, a more
> powerful, easier to use set of introspection and reflection tools.
> For a third, syntax, maybe similar to the direction that Arc is
> headed. Optional embedded syntax that can be interspersed within the
> Lisp code that gets dynamically translated into S-Expressions for
> evaluation.
OK, cool, and good luck. But if you don't alrady know how closures work
then you're a very very long way from doing this.
Some light reading might be more appropriate than asking what is sure to
be a long series of questions here.
People have already suggested "Lisp in Small Peices". To that -- and
given the above direction -- I would add "Compiling with Continuations"
by Andrew W. Appel.
You might also want to play around with existing compilers and see what
they do. If they compile to machine code then it can be hard to see
whats going on, but a lot of compilers now go to C, which makes that
much easier. Take a look, for example, at the Gwydion "d2c" Dylan
compiler and the "Chicken" Scheme compiler and see what they do with
various closure examples. The former (d2c) produces C that is a fairly
obvious translation from the source code. The latter (Chicken) produces
some of the most tortured (and yet legal) C code you can imagine. Oh,
and then there is the "Stalin" Scheme compiler which also produces C.
Are there any CL compilers which go via C? It tougher to do a
responsive REPL in that case, but by no means impossible, as the MIT
"goo" compiler demonstrates.
-- Bruce
Bruce Hoult <·····@hoult.org> writes:
> People have already suggested "Lisp in Small Peices". To that -- and
> given the above direction -- I would add "Compiling with
> Continuations" by Andrew W. Appel.
I'd second the suggestion of _Lisp in Small Pieces_, it's quite an
entertaining tour through various implementation techniques.
> Are there any CL compilers which go via C? It tougher to do a
> responsive REPL in that case, but by no means impossible, as the MIT
> "goo" compiler demonstrates.
GCL, I believe. For a bytecode interpreter check out CLISP. And
CMUCL/SBCL round things out with a native compiler. If you really want
to explore language design you might learn more faster by trying to
build the feautures you want into one of these existing
implementations. And for bonus points (with the crew around here
anyway) figure out a way to add the features you want in a backwards
compatible way, i.e. leave the implementation a conforming Common
Lisp. If you did that you'd actually have a user base who might
actually try out your ideas in the real world as they'd just be
features (or extensions) of a language they already use as opposed to
a whole new language.
-Peter
--
Peter Seibel ·····@javamonkey.com
The intellectual level needed for system design is in general
grossly underestimated. I am convinced more than ever that this
type of work is very difficult and that every effort to do it with
other than the best people is doomed to either failure or moderate
success at enormous expense. --Edsger Dijkstra
Peter Seibel <·····@javamonkey.com> wrote:
+---------------
| Bruce Hoult <·····@hoult.org> writes:
| > People have already suggested "Lisp in Small Peices". To that -- and
| > given the above direction -- I would add "Compiling with
| > Continuations" by Andrew W. Appel.
|
| I'd second the suggestion of _Lisp in Small Pieces_, it's quite an
| entertaining tour through various implementation techniques.
+---------------
And I'll third it! *Especially* the section on "Fast Interpretation",
which shows you that even in an "interpreter" there's no need for
for closures to have anything even vaguely like a "symbol table"
at run time. Basically, in any reasonable system lexical variables
get turned into name-free (no "symbols" any more) accesses to slots
in some kind of closure-environment structure, which may be a flat
array, linked chunks, or a single linked list, depending on which
of various other design choices you've made.
-Rob
-----
Rob Warnock, PP-ASEL-IA <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
······@eos.ncsu.edu (Justin Dubs) wrote in message news:<····························@posting.google.com>...
> Yes, but I am not writing "another Lisp interpreter." It does happen
> to be a dialect of Lisp in that, at the core, it is based off of
> S-Expressions. However, I'm leaning towards a handful of large-ish
> changes. For one, ML-style type-inference.
You might want to look into Jonathan Bachrach's goo before you jump in
too deep. Let's just say he's been thinking quite deeply about these
issues for a while, and has a good deal of experience implementing
these ideas.
http://www.ai.mit.edu/~jrb/goo/
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> I personally don't care if someone is learning or not. I care if they are
> doing something they can make money at. I want them to make money.
To which I respond with another of Kent's quotes from the same article:
> It seems quite unlikely that this is so.
:-)
If getting people to make money was all you cared about then you'd be
advising them to learn C++, Java, and Perl. Or to get an MBA. Or a law
degree. If your goal is to make money, then Lisp is about the last thing
you want to learn. In fact, it could be argued that knowing Lisp is
actively harmful to the goal of making money because once you know Lisp,
programming in C++, Java and Perl becomes almost unbearably painful. I'm
pretty sure that in my own personal case knowing Lisp has been a net
financial loss.
So what you really want is not for people to make money (people do that
all the time), but rather for people to make money *using Lisp*. But
why? It's not because Lisp is a particularly effective means of making
money. One might argue that it ought to be, but the simple fact of the
matter supported by decades of history is that it's not.
I suspect that the reason you want people to make money using Lisp is
quite simple: you like Lisp. It has some ineffable quality that cannot be
measured in dollars. It is beautiful (in a quirky sort of way). It is
elegant. It is powerful. Programming in Lisp is not painful. The
problem is, none of this has anything at all to do with making money. In
fact, *programming* has very little to do with making money. Making money
is very simple: obtain (or create) something and sell it to someone else
for more than you paid for it. It's as simple -- and as complicated -- as
that.
> There are so many things computers could be doing for people.
Like what? If you really have an answer to this question, and your answer
is one that people are willing to pay money to have computers do for them,
then you're half way to being rich. The thing is that this is a much,
much harder question to answer than most technical people appreciate.
> It saddens me to see yet another eager learner turning his attention to
> solved problems rather than to unsolved ones.
You are completely missing the point. If your goal is money, solving
unsolved problems is just as useless (or just as useful) as solving solved
problems. After all, just because a problem has a solution doesn't mean
that you couldn't find a better one. The programming problem was "solved"
with Fortran. Why invent Lisp?
Here's the thing: If your goal is money, then it's not about problems,
it's about products. The trouble is, for techno-geeks it's a whole lot
more *fun* to worry about problems than about products. That's why most
of them never make any money.
> Success of a high tech industry should be measured by its use for an
> end-user purpose,
By this measure Lisp is an abject failure.
> Sadly, a lot of the computer industry's success is measured by its
> ability to make problems for itself. We call it successful because it
> sells more "operating systems" or "computer hardware", but those
> aren't really end-user need, except in the trivial sense that our lack
> of progress in the computer industry has reduced every potential
> end-user to confront all manner of what should be intermediate-level
> issues kept far from their view. Admittedly, today, one can send
> email, purchase books and (sometimes unrelated) porn, balance a
> checkbook, draw a picture, or organize one's home movies a bit better
> than one could do before computers. But that's a pretty darned sad
> record given literally millions of programmers over now multiple (1-4,
> depending on how you count) decades. And I think at least a teensy
> amount of it has to be attributed to a focus on teaching people to
> solve solved problems rather than teaching them to solve unsolved
> ones.
I think you seriously underestimate how much harder it is to develop a
product than it is to solve a problem.
> Lisp was designed to solve the world's hardest problems.
Yes, that is precisely why Lisp fails in the market: beacuse in the market
it's not about problems, it's about products. The trouble is not really
Lisp per se. There's no reason why Lisp could not be a success in the
market. The problem is that because Lisp was designed to solve problems,
it tends to attract people who are interested in solving problems as
opposed to creating products. (People who are interested in creating
products tend to be the kind of people who *hire* others to do the
programming and other heavy lifting for them rather than doing it
themselves. And those people want employees who do as they're told.
That's why there are lots of C++, Java and Perl jobs and precious few Lisp
jobs out there.)
IMO, there is nothing at all wrong with rejecting the market game and
doing what you want instead of what someone else wants. (I've mostly
taken this path in my own life.) There's nothing wrong with learning new
things because you find joy in learning. (I do.) And there's nothing
wrong with giving up wealth in order to live your life in this way. (I
have.) Similarly, there's nothing wrong with making money. (I'm still
trying. All else being equal I'd rather be rich than poor.)
But I think there's a lot wrong with advising people unconditionally they
shouldn't learn new things because you think they ought to be making
money.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <···············@shell01.TheWorld.com>, Kent M Pitman
> <······@world.std.com> wrote:
> > I personally don't care if someone is learning or not. I care if
> > they are doing something they can make money at. I want them to
> > make money.
> If getting people to make money was all you cared about then you'd
> be advising them to learn C++, Java, and Perl. Or to get an MBA.
> Or a law degree. If your goal is to make money, then Lisp is about
> the last thing you want to learn.
...
> So what you really want is not for people to make money (people do
> that all the time), but rather for people to make money *using
> Lisp*. But why? It's not because Lisp is a particularly effective
> means of making money. One might argue that it ought to be, but the
> simple fact of the matter supported by decades of history is that
> it's not.
Is that so? When I look at the pile of Linux CDs on my table and
think about the immense amount of man-hours that went into writing all
that software in C and C++ for nothing I am not so sure about that
anymore. Sure, there are much fewer small companies that try to make
money using Lisp than, say, Java or C++, but I would indeed be
surprised if the former were any less successful than the latter.
> I suspect that the reason you want people to make money using Lisp
> is quite simple: you like Lisp. It has some ineffable quality that
> cannot be measured in dollars. It is beautiful (in a quirky sort of
> way). It is elegant. It is powerful. Programming in Lisp is not
> painful.
Yes, and when more people make lots of money with it, more people will
want to know about it.
> > There are so many things computers could be doing for people.
>
> Like what? If you really have an answer to this question, and your
> answer is one that people are willing to pay money to have computers
> do for them, then you're half way to being rich. The thing is that
> this is a much, much harder question to answer than most technical
> people appreciate.
That's right: First you need a product, and...
> > It saddens me to see yet another eager learner turning his
> > attention to solved problems rather than to unsolved ones.
>
> You are completely missing the point.
No, he is exactly /on/ the point!
> If your goal is money, solving unsolved problems is just as useless
> (or just as useful) as solving solved problems. After all, just
> because a problem has a solution doesn't mean that you couldn't find
> a better one. The programming problem was "solved" with Fortran.
> Why invent Lisp?
Then the problem is to do it better, that's just playing word games.
> Here's the thing: If your goal is money, then it's not about
> problems, it's about products. The trouble is, for techno-geeks
> it's a whole lot more *fun* to worry about problems than about
> products. That's why most of them never make any money.
Maybe so -- but mainly because they waste too much of their time
writing the third implementation of procmail, the 300th window manager
and the 30000th little pet language with an interpreter. These are
/not/ products. Nobody is going to give you one cent for them. And
the little bit of knowledge you aquire along the way is not likely to
be a useful basis for a successful product.
> I think you seriously underestimate how much harder it is to develop
> a product than it is to solve a problem.
Well, that depends on the product, I'd say :-) Sure, if you try to
make money by writing Windows Desktop applications using Visual C++ or
whatever, finding a product anybody would want to buy is indeed
extremely hard. But in that case you should get your head checked,
anyway. If you want to make money, you'll have to look around and
find out who is selling products not for $100 apiece but for $30000
apiece. Or $500000. These people can take so much money for their
products because their software works and anybody else who tried
failed so far. And they failed because they couldn't solve all the
problems the other guys successfully solved. (No, this is not just a
question of man-years). And for this kind of thing, a language like
Lisp, that makes it just a bit easier to solve hard problems, could
indeed be the very key element that makes you rich. Of course, this
is still easier said than done ;-) You have to work in the industry
for many years until you know the key players and how the game works.
Most likely, you'll have to write in C and C++ during that time. But
when you finally jump and start your own shop, if you have an
advantage over your competitors that lets you solve problems quicker
and easier, you are very likely to make a shitload of money.
But you have to be focused on such a goal. If you waste your time
writing toy interpreters you are not moving towards it at all.
> But I think there's a lot wrong with advising people unconditionally
> they shouldn't learn new things because you think they ought to be
> making money.
They should learn new things if they help them doing something useful,
maybe in a remote way (like learning Lisp ;-) and useful things tend
to make money in the end.
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
In article <··············@cartan.de>, Nils Goesche <······@cartan.de> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <···············@shell01.TheWorld.com>, Kent M Pitman
> > <······@world.std.com> wrote:
>
> > > I personally don't care if someone is learning or not. I care if
> > > they are doing something they can make money at. I want them to
> > > make money.
>
> > If getting people to make money was all you cared about then you'd
> > be advising them to learn C++, Java, and Perl. Or to get an MBA.
> > Or a law degree. If your goal is to make money, then Lisp is about
> > the last thing you want to learn.
> ...
> > So what you really want is not for people to make money (people do
> > that all the time), but rather for people to make money *using
> > Lisp*. But why? It's not because Lisp is a particularly effective
> > means of making money. One might argue that it ought to be, but the
> > simple fact of the matter supported by decades of history is that
> > it's not.
>
> Is that so? When I look at the pile of Linux CDs on my table and
> think about the immense amount of man-hours that went into writing all
> that software in C and C++ for nothing I am not so sure about that
> anymore. Sure, there are much fewer small companies that try to make
> money using Lisp than, say, Java or C++, but I would indeed be
> surprised if the former were any less successful than the latter.
Just because I claim that Lisp is not an effective means of making money
it does not follow that I therefore believe that C++ is an effective means
of making money. In fact, I explicitly said (in the part of my quote that
you elided) that *programming* -- in whatever language -- has very little
to do with making money.
> > I suspect that the reason you want people to make money using Lisp
> > is quite simple: you like Lisp. It has some ineffable quality that
> > cannot be measured in dollars. It is beautiful (in a quirky sort of
> > way). It is elegant. It is powerful. Programming in Lisp is not
> > painful.
>
> Yes, and when more people make lots of money with it, more people will
> want to know about it.
Again, this is not supported by history. Yahoo Store was a highly visible
and lucrative success story for Lisp, but there was no increase in the
commercial use of Lisp as a result. In fact, Yahoo, rather than embracing
Lisp, is trying as hard as it can to get rid of it. We saw the same thing
here at NASA: despite the overwhelming technical success of the Remote
Agent there is no increased interest in Lisp. In fact, we see the exact
opposite: the RA is widely perceived as a failure, and cited as a reason
not to use Lisp. And IMO one of the factors that contributed to this was
that the Lisp programmers were combative and a pain in the ass to work
with.
> > > It saddens me to see yet another eager learner turning his
> > > attention to solved problems rather than to unsolved ones.
> >
> > You are completely missing the point.
>
> No, he is exactly /on/ the point!
>
> > If your goal is money, solving unsolved problems is just as useless
> > (or just as useful) as solving solved problems. After all, just
> > because a problem has a solution doesn't mean that you couldn't find
> > a better one. The programming problem was "solved" with Fortran.
> > Why invent Lisp?
>
> Then the problem is to do it better, that's just playing word games.
Well, then why is writing a better Lisp implementation not a legitimate
problem for an eager young learner to tackle?
> > Here's the thing: If your goal is money, then it's not about
> > problems, it's about products. The trouble is, for techno-geeks
> > it's a whole lot more *fun* to worry about problems than about
> > products. That's why most of them never make any money.
>
> Maybe so -- but mainly because they waste too much of their time
> writing the third implementation of procmail, the 300th window manager
> and the 30000th little pet language with an interpreter. These are
> /not/ products. Nobody is going to give you one cent for them. And
> the little bit of knowledge you aquire along the way is not likely to
> be a useful basis for a successful product.
And you know this how? How many successful products have you brought to
market?
> > I think you seriously underestimate how much harder it is to develop
> > a product than it is to solve a problem.
>
> Well, that depends on the product, I'd say :-)
No, it doesn't. It's hard, period, end of story. If it were easy more
people would be doing it.
> But you have to be focused on such a goal. If you waste your time
> writing toy interpreters you are not moving towards it at all.
First, that is not at all clear. Bill Gates started his career writing
toy interpreters and he did OK (in terms of making money).
Second, the whole point is that it's not writing toy interpreters that is
the waste of time W.R.T. a goal of making money, but _programming_.
Programming has virtually nothing to do (any more) with making money.
Programmers are like machinists. They are the hired help. They do not
make the big bucks no matter how smart and clever they are.
This is not to say that people shouldn't become programmers, just that
they should not become programmers if their goal is to make money. There
are other worthy goals in life, and IMO solving problems and learning new
things purely for their own sake is one of them.
> > But I think there's a lot wrong with advising people unconditionally
> > they shouldn't learn new things because you think they ought to be
> > making money.
>
> They should learn new things if they help them doing something useful,
> maybe in a remote way (like learning Lisp ;-) and useful things tend
> to make money in the end.
Useful things make money, but *doing* useful things typically doesn't.
This is a crucial distinction. Things (useful or otherwise) make money
for their owners, not for their producers.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <··············@cartan.de>, Nils Goesche <······@cartan.de> wrote:
>
> > Is that so? When I look at the pile of Linux CDs on my table and
> > think about the immense amount of man-hours that went into writing
> > all that software in C and C++ for nothing I am not so sure about
> > that anymore. Sure, there are much fewer small companies that try
> > to make money using Lisp than, say, Java or C++, but I would
> > indeed be surprised if the former were any less successful than
> > the latter.
>
> Just because I claim that Lisp is not an effective means of making
> money it does not follow that I therefore believe that C++ is an
> effective means of making money.
Well, you said (and I /did/ quote it):
> > > If getting people to make money was all you cared about then
> > > you'd be advising them to learn C++, Java, and Perl.
Sorry if I misunderstood that (if so, I probably still do).
> In fact, I explicitly said (in the part of my quote that you elided)
> that *programming* -- in whatever language -- has very little to do
> with making money.
This looks like a very odd statement to me. What have I and my
coworkers been doing all these years if not making money by
programming? Sure, there are other ways of making money. You could
sell toilets, for instance. Programmers make and sell software. Some
work for other people, others run their own shops. I can hardly
believe that you are not aware of this.
> > > I suspect that the reason you want people to make money using
> > > Lisp is quite simple: you like Lisp. It has some ineffable
> > > quality that cannot be measured in dollars. It is beautiful (in
> > > a quirky sort of way). It is elegant. It is powerful.
> > > Programming in Lisp is not painful.
> >
> > Yes, and when more people make lots of money with it, more people
> > will want to know about it.
>
> Again, this is not supported by history. Yahoo Store ... RA
Yes. Two examples. We all remember them. So set some more examples.
I am rather amused if people think they can't use Lisp for commercial
systems -- fine, use Java in your shop then. I use Lisp. Let's see
who wins.
> > > If your goal is money, solving unsolved problems is just as
> > > useless (or just as useful) as solving solved problems. After
> > > all, just because a problem has a solution doesn't mean that you
> > > couldn't find a better one. The programming problem was
> > > "solved" with Fortran. Why invent Lisp?
> >
> > Then the problem is to do it better, that's just playing word
> > games.
>
> Well, then why is writing a better Lisp implementation not a
> legitimate problem for an eager young learner to tackle?
Because my crystal ball is telling me that he is not going to make any
money in that area. Just my opinion. If he thinks he can get rich
that way, sure let him go ahead. But I rather suspect he didn't even
think about his goals (other than ``I'll learn something��).
> > > Here's the thing: If your goal is money, then it's not about
> > > problems, it's about products. The trouble is, for techno-geeks
> > > it's a whole lot more *fun* to worry about problems than about
> > > products. That's why most of them never make any money.
> >
> > Maybe so -- but mainly because they waste too much of their time
> > writing the third implementation of procmail, the 300th window
> > manager and the 30000th little pet language with an interpreter.
> > These are /not/ products. Nobody is going to give you one cent
> > for them. And the little bit of knowledge you aquire along the
> > way is not likely to be a useful basis for a successful product.
>
> And you know this how? How many successful products have you
> brought to market?
If you went to the last few CeBit's, you might have seen some. What
is this, a pissing contest? No, I don't ``know�� that the way I
``know�� that, say, two plus two is four. This is obviously just my
opinion. Everybody is free to disagree. I have just learned that it
is important to have knowhow in areas where there are /not/ millions
of other people with the same knowhow. Because it enables you to come
out with products other people weren't able to finish yet. To aquire
this knowhow you have to work hard and be focused on your goals, not
randomly learn something just because you don't know it yet. Again,
feel free to disagree. People might make different experiences.
> > But you have to be focused on such a goal. If you waste your time
> > writing toy interpreters you are not moving towards it at all.
>
> First, that is not at all clear. Bill Gates started his career
> writing toy interpreters and he did OK (in terms of making money).
Fine. If I thought I could repeat Microsoft's success, I'd go and
try. But I don't...
> Second, the whole point is that it's not writing toy interpreters
> that is the waste of time W.R.T. a goal of making money, but
> _programming_. Programming has virtually nothing to do (any more)
> with making money. Programmers are like machinists. They are the
> hired help. They do not make the big bucks no matter how smart and
> clever they are.
What if it's them who hire? I find this really strange -- have you
never met any programmer who runs his own shop making money? I know a
lot...
> This is not to say that people shouldn't become programmers, just
> that they should not become programmers if their goal is to make
> money. There are other worthy goals in life, and IMO solving
> problems and learning new things purely for their own sake is one of
> them.
Fine with me. But ideally, one would try to combine those things :-)
> > They should learn new things if they help them doing something
> > useful, maybe in a remote way (like learning Lisp ;-) and useful
> > things tend to make money in the end.
>
> Useful things make money, but *doing* useful things typically
> doesn't. This is a crucial distinction. Things (useful or
> otherwise) make money for their owners, not for their producers.
Sure, if you work for somebody else, you'll make /him/ rich. Most
programmers do this a number of times in their career. Some go on
like that forever, others try to learn...
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
> > Just because I claim that Lisp is not an effective means of making
> > money it does not follow that I therefore believe that C++ is an
> > effective means of making money.
>
> Well, you said (and I /did/ quote it):
>
> > > > If getting people to make money was all you cared about then
> > > > you'd be advising them to learn C++, Java, and Perl.
>
> Sorry if I misunderstood that (if so, I probably still do).
Ah, no, this misunderstanding is my fault. I'm mentally flipping back and
forth between two different intepretations of "making money."
Making money (1) means earning a salary.
Making money (2) means owning a share of a profitable business venture.
Knowing C++, Java and Perl is demonstrably more effective than knowing
Lisp if your goal is to make money (1).
Having programming skills (in any language) can be helpful if your goal is
to make money (2) but they are neither necessary, nor sufficient, and I
claim that you reach the point of diminishing returns very, very quickly.
A few general observations about making money (n):
Making money (2) is a prerequisite for making money (1). It's not
necessarily the same person making the money in those two modes (in fact,
it usually isn't), but no one can make money (1) unless someone is making
money (2). (The only exception is if you are working for the government.)
The amount of money you can make by making money (2) is vastly higher than
the amount of money you can make by making money (1).
Very few people have ever made money (2) using Lisp. (I know of only one case.)
> > In fact, I explicitly said (in the part of my quote that you elided)
> > that *programming* -- in whatever language -- has very little to do
> > with making money.
>
> This looks like a very odd statement to me. What have I and my
> coworkers been doing all these years if not making money by
> programming?
You have (I suspect -- I don't know your particular circumstances) been
making money (1), not making money (2).
> Sure, there are other ways of making money. You could
> sell toilets, for instance. Programmers make and sell software. Some
> work for other people, others run their own shops. I can hardly
> believe that you are not aware of this.
Programmers make software, but typically someone else sells it. The
skills required to sell software (or anything for that matter) are very
different than the skills required to make it. It is rare that those
skills reside in the same person.
> Yes. Two examples. We all remember them. So set some more examples.
> I am rather amused if people think they can't use Lisp for commercial
> systems -- fine, use Java in your shop then. I use Lisp. Let's see
> who wins.
I wish you all the luck in the world. I hope you win. I hope you kick
their ass. I hope you make billions of dollars. I really do. The world
will be a better place when Lisp makes (or is perceived as making) more
people rich.
> > Well, then why is writing a better Lisp implementation not a
> > legitimate problem for an eager young learner to tackle?
>
> Because my crystal ball is telling me that he is not going to make any
> money in that area. Just my opinion. If he thinks he can get rich
> that way, sure let him go ahead. But I rather suspect he didn't even
> think about his goals (other than ``I'll learn something��).
That is entirely possible. But we don't even know that he *wants* to make
himself rich. Note by the way that wanting to make yourself rich is a
very different thing than wanting to *be* rich. I wouldn't mind being
rich, but having learned a lot about what it takes to make yourself rich
I'm not at all sure that's what I want.
> > > > Here's the thing: If your goal is money, then it's not about
> > > > problems, it's about products. The trouble is, for techno-geeks
> > > > it's a whole lot more *fun* to worry about problems than about
> > > > products. That's why most of them never make any money.
> > >
> > > Maybe so -- but mainly because they waste too much of their time
> > > writing the third implementation of procmail, the 300th window
> > > manager and the 30000th little pet language with an interpreter.
> > > These are /not/ products. Nobody is going to give you one cent
> > > for them. And the little bit of knowledge you aquire along the
> > > way is not likely to be a useful basis for a successful product.
> >
> > And you know this how? How many successful products have you
> > brought to market?
>
> If you went to the last few CeBit's, you might have seen some.
I don't even know what CeBit is.
> What is this, a pissing contest?
No, it was an honest question so that people can judge your credentials to
hold forth on why people fail to make money. (Feel free to ask the same
question of me if you want to know.)
> No, I don't ``know�� that the way I
> ``know�� that, say, two plus two is four. This is obviously just my
> opinion. Everybody is free to disagree.
OK, that's fine. You didn't qualify it in this way when you originally
wrote it.
> I have just learned that it
> is important to have knowhow in areas where there are /not/ millions
> of other people with the same knowhow. Because it enables you to come
> out with products other people weren't able to finish yet. To aquire
> this knowhow you have to work hard and be focused on your goals, not
> randomly learn something just because you don't know it yet. Again,
> feel free to disagree. People might make different experiences.
No, I agree that this sort of thing helps. But again, it is neither
necessary nor sufficient for making money (of either sort).
> > Second, the whole point is that it's not writing toy interpreters
> > that is the waste of time W.R.T. a goal of making money, but
> > _programming_. Programming has virtually nothing to do (any more)
> > with making money. Programmers are like machinists. They are the
> > hired help. They do not make the big bucks no matter how smart and
> > clever they are.
>
> What if it's them who hire? I find this really strange -- have you
> never met any programmer who runs his own shop making money? I know a
> lot...
Actually, no, I haven't. I'm sure they exist, but I've never met a
successful freelancer.
> > This is not to say that people shouldn't become programmers, just
> > that they should not become programmers if their goal is to make
> > money. There are other worthy goals in life, and IMO solving
> > problems and learning new things purely for their own sake is one of
> > them.
>
> Fine with me. But ideally, one would try to combine those things :-)
I agree, but not everyone does. (Thomas Bushnell for example.) It is not
up to us to decide on life goals for others (except that I think it's fair
to encourage people to try to make the world a better place).
> > > They should learn new things if they help them doing something
> > > useful, maybe in a remote way (like learning Lisp ;-) and useful
> > > things tend to make money in the end.
> >
> > Useful things make money, but *doing* useful things typically
> > doesn't. This is a crucial distinction. Things (useful or
> > otherwise) make money for their owners, not for their producers.
>
> Sure, if you work for somebody else, you'll make /him/ rich. Most
> programmers do this a number of times in their career. Some go on
> like that forever, others try to learn...
Exactly the point I was trying to make.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> Ah, no, this misunderstanding is my fault. I'm mentally flipping back and
> forth between two different intepretations of "making money."
>
> Making money (1) means earning a salary.
>
> Making money (2) means owning a share of a profitable business venture.
I meant neither, btw.
I meant "making money = doing something that is of sufficient value to
one other person or several other people or many other people that
they will, collectively, do something for you that justifies your
having spent the time".
I recently read Atlas Shrugged, by Ayn Rand, and cannot recommend it
highly enough as a defense of what I mean by making money.
When I hear people saying things like "this is valuable to people even
though no one will pay money for it", the oxymoron indicator light on
my internal dashboard goes on.
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > Ah, no, this misunderstanding is my fault. I'm mentally flipping back and
> > forth between two different intepretations of "making money."
> >
> > Making money (1) means earning a salary.
> >
> > Making money (2) means owning a share of a profitable business venture.
>
> I meant neither, btw.
>
> I meant "making money = doing something that is of sufficient value to
> one other person or several other people or many other people that
> they will, collectively, do something for you that justifies your
> having spent the time".
That's not making money, that's engaging in a barter transaction. On your
definition, I make money posting to usenet. (Would that it were so.)
What makes money different from barter is that you can do something for
one person that is of sufficient value to them that they will turn over to
you a token that will cause a third party with no connection whatsoever to
the original transaction to do something for you. That is the magic of
money -- and it really is magic. Money is arguably one of the great
inventions of civilization, right up there with the printing press and the
wheel.
> When I hear people saying things like "this is valuable to people even
> though no one will pay money for it", the oxymoron indicator light on
> my internal dashboard goes on.
I think your usenet postings are valuable to many people, but I doubt that
they'd be willing to pay enough to make collecting worthwhile. How does
that register on the old O-meter?
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <···············@shell01.TheWorld.com>, Kent M Pitman
> <······@world.std.com> wrote:
>
> > When I hear people saying things like "this is valuable to people even
> > though no one will pay money for it", the oxymoron indicator light on
> > my internal dashboard goes on.
>
> I think your usenet postings are valuable to many people, but I doubt that
> they'd be willing to pay enough to make collecting worthwhile. How does
> that register on the old O-meter?
Rand-like `objectivism' is naive, but not *that* naive. What Kent is
getting in return for his postings is `good will', which is a
non-tangible, but quite valuable asset.
In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <···············@shell01.TheWorld.com>, Kent M Pitman
> > <······@world.std.com> wrote:
> >
> > > When I hear people saying things like "this is valuable to people even
> > > though no one will pay money for it", the oxymoron indicator light on
> > > my internal dashboard goes on.
> >
> > I think your usenet postings are valuable to many people, but I doubt that
> > they'd be willing to pay enough to make collecting worthwhile. How does
> > that register on the old O-meter?
>
> Rand-like `objectivism' is naive, but not *that* naive. What Kent is
> getting in return for his postings is `good will', which is a
> non-tangible, but quite valuable asset.
Yes, that is actually the point I was trying to make in an oblique way.
There are lots of things that have intangible value that cannot be
measured in dollars, including good will, companionship, cameraderie, the
joy that comes from having created something or helped someone, and -- the
original point of this thread -- knowledge.
E.
Joe Marshall <···@ccs.neu.edu> writes:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <···············@shell01.TheWorld.com>, Kent M Pitman
> > <······@world.std.com> wrote:
> >
> > > When I hear people saying things like "this is valuable to people even
> > > though no one will pay money for it", the oxymoron indicator light on
> > > my internal dashboard goes on.
> >
> > I think your usenet postings are valuable to many people, but I doubt that
> > they'd be willing to pay enough to make collecting worthwhile. How does
> > that register on the old O-meter?
>
> Rand-like `objectivism' is naive, but not *that* naive. What Kent is
> getting in return for his postings is `good will', which is a
> non-tangible, but quite valuable asset.
But in Randian terms, the time I'm spending posting is stuff _I_ pay
for. It is not free. Someone is paying. Me. And that person has
given consent. It comes out of profits I made on other paying
activities, and it diminishes time and resources that I might spend on
other things. It does NOT come out of nowhere. It might profit me,
or it might be a mistake for me to do because it doesn't profit me,
but it certainly has someone who will (and does) pay. Me.
(Also, importantly, I'm not billing someone else for it and claiming
that it's benefiting them even though they never would have hired me
to do what I do on their nickel.)
That is substantively different than a student who is working on mom & dad's
nickel doing the same thing, or than an employee who is spending half the day
working and the other half of the day surfing unless the worker's employer,
except in the situation where mom&dad or the employer has given informed
consent.
Also, I don't have problems with money spent on tax programs for things
like NASA or PBS or whatever _if_ there is consent of enough of the public
that the taxes from that public can pay for it. But if only one person in
the public wants PBS, then it's not fair to say "it's a good idea and it
can't be sustained unless we tax everyone". Nor is it ok for one group
(say, the pro-lifers in the US) to tell another group they cannot spend
tax dollars in a certain way (say, abortion); rather, no more tax dollars
should be spent on something than were collected from willing participants.
If there's something that can't be accounted for, it should come out of
a pool of people who give money saying "I trust the government to do wise
things with this."
Incidentally, while Atlas Shrugged might be based on a notion of
objectivism, it doesn't even define the term and I won't in my defense
of the book defend the notion since I have not read an independent
document defining that term and am not really familiar with the notion
in the abstract, nor am I attempting to push it.
I am simply defending the notion that there is nothing to be ashamed
of in believing that money is as reasonable a metric of value as there
is. (I am also not defending it because Rand said it; I thought this
way before I read her story. I am just saying she expresses the ideas
more clearly and entertainingly than I might, so you might prefer to
read her rather than me.)
The book also makes some other interesting points about the origin of
the term "to make money"; that is, that wealth used to be largely
pre-existing and mostly traded but never created, and that we have
finally created a society in which work can yield new money by
creating new value. I conclude that when you create new value but
charge no money, all you do is make the accounting more complicated
and disempower the person who has made value but not acquired any
societally accepted interchange acknowledgement of that. Sure, you
can do someone a favor, and you'll get some gratitude, but it will be
limited to the small community that sees it happen, and you'll be
regarded as vain for touting your good deeds outside that community.
I can make a piece of free software, and you all might be grateful,
but my grocer won't.
Back to the original point about doing something useful that no one
values, I'm saying that somewhere there should be someone who either
owns money or acts on informed behalf of the person who owns the money
who is authorizing the use of time, whether for education or whatever.
Surely some of education is authorization to just "learn". But I think
there is an ethical responsibility of the student not to sweep under
the rug the difference between "I didn't know how to write a simple
do loop so I wrote a toy program to test that". and "I didn't know how
to write a web browser, so I wrote one." because one might be marketable
and one might not be. The former is quite obviously "education" but the
latter falls into the gray area of "potential moneymaker". If you don't
believe this, observe the difference in the last 20 years over how carefully
universities deal with the issue of intellectual property in theses, which
often turn out to have commercial value. Some universities used to grab
copyright on these things, claiming it was part of the education that
produced the output. Now, I think most universities wouldn't dare lock
out the student from some or all of the intellectual property rights on
the things they make.
And, finally, we come back to the question of whether the university
should advise the student that some paths to projects lead to
economically uninteresting results, while others do not. I see no
reason for people to do something economically uninteresting if they
can learn the same thing by doing something economically interesting.
Hence my original comment regarding what is useful and what is not
in terms of ways to learn lisp.
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> But in Randian terms, the time I'm spending posting is stuff _I_ pay
> for. It is not free. Someone is paying. Me.
But there is a fundamental difference between the internal trades you make
when you decide how to spend your life and monetary transactions. (There
is also a third kind of transaction, barter, which is fundamentally
different from the other two.) Many people make themselves miserable by
not recognizing this.
> I am simply defending the notion that there is nothing to be ashamed
> of in believing that money is as reasonable a metric of value as there
> is.
I don't dispute this, but it does not follow that money is a reasonable
metric of value. And it certainly does not follow that money is a
reasonable metric of all that is valuable in life.
> Back to the original point about doing something useful that no one
> values, I'm saying that somewhere there should be someone who either
> owns money or acts on informed behalf of the person who owns the money
> who is authorizing the use of time, whether for education or whatever.
I am researcher. The way "informed consent" works in the research world
is that we write proposals which are reviewed by our peers, who give the
"informed consent" to do the work. For a time in my career I had a string
of proposals rejected on the grounds that the work I was proposing to do
was impossible given the resources I was requesting. (I was, of course,
planning to do the work in Lisp, where the reviewers were undoubtedly
estimating the effort that would be required in C.) I started descoping
my proposals, and suddenly they started to get funded. But of course, I
was now able to do more than I actually proposed, so my work started
running ahead of my proposals. For a while the actual work I was doing
was running several years ahead of what I was proposing.
(In fact, just today I dug a six year old presentation out of the
mothballs and discovered that the time is just about right to propose the
work that it describes.)
The vast majority of people wouldn't recognize a good idea if it walked up
and kicked them in the ass. Sometimes you have to go Nike: just do it.
Just because no one in the world except you thinks it's a good idea it
does not follow that it is not a good idea.
> Surely some of education is authorization to just "learn". But I think
> there is an ethical responsibility of the student not to sweep under
> the rug the difference between "I didn't know how to write a simple
> do loop so I wrote a toy program to test that". and "I didn't know how
> to write a web browser, so I wrote one." because one might be marketable
> and one might not be. The former is quite obviously "education" but the
> latter falls into the gray area of "potential moneymaker".
Wait, now I'm really confused. Are you saying that if there is no hope
that an activity will make money then it's OK to go ahead and just do it
in the name of "learning", but if an activity might make money then you
need someone else's informed consent first? That doesn't make any kind of
sense.
> And, finally, we come back to the question of whether the university
> should advise the student that some paths to projects lead to
> economically uninteresting results, while others do not. I see no
> reason for people to do something economically uninteresting if they
> can learn the same thing by doing something economically interesting.
But that is precisely the problem: it's impossible to know what is and is
not economically interesting except in retrospect. Napster and Google
both started out in more or less the same way, with one or two bright guys
tinkering at something just for the fun of it. If anything, Napster
looked more economically interesting than Google at first. Napster was
completely new. Google was entering a market with existing players and
considerable barriers to entry.
There is an even deeper problem: whether something is "economically
interesting" or not depends not so much on the thing being done as in the
manner in which it is done. Writing, for example, can be "economically
interesting" or not depending on how one engages in it. Likewise with
programming, and just about anything else for that matter.
> Hence my original comment regarding what is useful and what is not
> in terms of ways to learn lisp.
And hence my continued dissent. Who is to say that someone won't come up
with something brilliant (and lucrative) as a result from having tinkered
(yet again) with implementing lexical closures?
E.
···@jpl.nasa.gov (Erann Gat) writes:
> > Surely some of education is authorization to just "learn". But I think
> > there is an ethical responsibility of the student not to sweep under
> > the rug the difference between "I didn't know how to write a simple
> > do loop so I wrote a toy program to test that". and "I didn't know how
> > to write a web browser, so I wrote one." because one might be marketable
> > and one might not be. The former is quite obviously "education" but the
> > latter falls into the gray area of "potential moneymaker".
>
> Wait, now I'm really confused. Are you saying that if there is no hope
> that an activity will make money then it's OK to go ahead and just do it
> in the name of "learning", but if an activity might make money then you
> need someone else's informed consent first? That doesn't make any kind of
> sense.
No, I'm saying that if Mom and Dad are paying for my education, then
classifying some programs I write as "learning exercises" is
reasonable while classifying others I write might be said to be a kind
of fraud. If Mom and Dad have authorized me unfettered playtime EVEN
IF I could be making money, that's one thing, but I'm guessing they're
paying for my time because they think me not yet able to to pay myself
because I'm "still learning". I'm saying you cross an ethical
boundary if you become capable of self-supporting but don't go back to
the people who are supporting you and tell them so. It's one thing if
those people are independently wealthy and another thing entirely if they
have mortgaged themselves to help me get ahead. At the point that I am
ahead but just don't want to acknowledge it, I'm not "doing them proud"
by learning enough to finallyg et ahead, I'm "doing them a disservice"
by not returning the enormous favor they did me in lending me their
hard-earned money--money they would certainly not have if instead of
demanding money for THEIR work, they had demanded instead favors and
good will.
> > And, finally, we come back to the question of whether the university
> > should advise the student that some paths to projects lead to
> > economically uninteresting results, while others do not. I see no
> > reason for people to do something economically uninteresting if they
> > can learn the same thing by doing something economically interesting.
>
> But that is precisely the problem: it's impossible to know what is and is
> not economically interesting
But it's not impossible to know when someone is trying to care about
economics and when they are not. If it's not your money you're operating
on, you have an ethical responsibility to stay within the bounds of
reasonableness specified by the person whose money it is. e.g., some
R&D departments are fine with "blue sky" research, while others want to
stay just one step ahead of the product design team.
> except in retrospect. Napster and Google
> both started out in more or less the same way,
Yes, by people who owned money making an informed decision to spend it
in a certain way. [In the case of napster, we have to also consider
whether they owned the copyrights they "spent", but that's another matter.]
> There is an even deeper problem: whether something is "economically
> interesting" or not depends not so much on the thing being done as in the
> manner in which it is done. Writing, for example, can be "economically
> interesting" or not depending on how one engages in it. Likewise with
> programming, and just about anything else for that matter.
If it's your own money, great. If you're trying to justify how you're
spending someone else's money, that's something else again. Atlas Shrugged
speaks directly to researchers, and not kindly. I'm not accusing all
researchers of doing nothing of value, since some (perhaps much) of research
is a calculated gamble by the funders and is done in proper knowledge of
the risks by the people who own the money.
> > Hence my original comment regarding what is useful and what is not
> > in terms of ways to learn lisp.
>
> And hence my continued dissent. Who is to say that someone won't come up
> with something brilliant (and lucrative) as a result from having tinkered
> (yet again) with implementing lexical closures?
Someone might. But that's not the question. The question is: who is to say
whethr that's what you should be seeking. And the answer there is--the
person whose money it is. One either was or wasn't hired with the search
for that in your contract. Sure, sometimes you find things by accident.
But if you're hired to find a medical cure and you end up deciding to
investigate a new ways to implement closures, no matter how good you do on
that, you're still doing the wrong thing. And I think if you're trying to
learn something on you're own nickel, then pursue what you like; but when
you're on someone else's time, you should do them the favor of getting OFF
their welfare program before you go trying to solve the world's problems.
Unless they've said they want to pay you to do that...
It's true that Lisp doesn't always crank out money makers. That may be
because it's too empowering, not too limiting. Other languages can barely
be used for more than just cranking out a business solution, so that's all
anyone ever tries and it works pretty well. In Lisp, there's a certain
discipline required to keep the focus on business, and if you don't do that,
you end up off in left field doing something fun for yourself (and
perhaps others), but having no money at the end of the day.
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> No, I'm saying that if Mom and Dad are paying for my education, then
> classifying some programs I write as "learning exercises" is
> reasonable while classifying others I write might be said to be a kind
> of fraud.
I don't dispute that. What I dispute is that writing yet another
implementation of closures (or yet another Scheme interpreter) is
necessarily an endeavor of the second kind.
> If Mom and Dad have authorized me unfettered playtime EVEN
> IF I could be making money, that's one thing, but I'm guessing they're
> paying for my time because they think me not yet able to to pay myself
> because I'm "still learning". I'm saying you cross an ethical
> boundary if you become capable of self-supporting but don't go back to
> the people who are supporting you and tell them so.
This seems to be a very different position than the one you took to start
this discussion, which was more like: it is well understood how closures
are implemented, and the probability that you will learn anything
economically viable by going through the process yet again is so low that
you should not bother. What you just now said is: once you are able to
support yourself you have an ethical obligation to inform those who are
supporting you of this fact. What you said earlier is more like: you have
an ethical obligation to reach the threshold of self-supportability in an
expeditious manner, and you should not waste your time on things that
don't have a clear path towards profitability. It is this second position
I take issue with, not the first.
> It's true that Lisp doesn't always crank out money makers. That may be
> because it's too empowering, not too limiting. Other languages can barely
> be used for more than just cranking out a business solution, so that's all
> anyone ever tries and it works pretty well. In Lisp, there's a certain
> discipline required to keep the focus on business, and if you don't do that,
> you end up off in left field doing something fun for yourself (and
> perhaps others), but having no money at the end of the day.
You assume that programming (in Lisp or whatever) needs to be a
money-making activity. Why? What wrong with pursuing programming (in
Lisp or whatever) as a hobby or an artistic endeavor, and doing something
completely different as the day job?
I live in Los Angeles. This town is full of actors with dreams of making
it big in the movies. The vast majority of them will never make a dime
from acting. And yet they do it, they find it fulfilling, and IMO they
make the world a better place by doing it despite the fact that most of
them will never make a dime acting. (What do you call an actor in Los
Angeles? Waiter.) For one thing, you can find exceptionally fine
theatre in Los Angeles for dirt cheap.
Maybe programming is like acting. Maybe programming in C++ is the digital
equivalent of doing yet another mortifying performance of "Nunsense" at
the dinner theatre while you wait for your Big Break. Maybe programming
is something people do not to earn a living but out of passion, for the
sheer joy of creating something, never mind that it has been created
before. (People still find performing Shakespeare worthwhile despite the
fact that it's been done.) Maybe Linux is analogous to all those little
theatres in Los Angeles where exceptionally fine actors slave away for
nothing except the opportunity to be on a stage in front of an audience,
even a tiny one. Maybe Lisp is like some obscure form of Kabuki that only
a small group of adherents knows how to appreciate.
Certainly it is good for people to earn money. I just don't see why that
necessarily has to have anything to do with programming.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> > If Mom and Dad have authorized me unfettered playtime EVEN
> > IF I could be making money, that's one thing, but I'm guessing they're
> > paying for my time because they think me not yet able to to pay myself
> > because I'm "still learning". I'm saying you cross an ethical
> > boundary if you become capable of self-supporting but don't go back to
> > the people who are supporting you and tell them so.
>
> This seems to be a very different position than the one you took to start
> this discussion, which was more like: it is well understood how closures
> are implemented, and the probability that you will learn anything
> economically viable by going through the process yet again is so low that
> you should not bother.
Not that different. I'm assuming that mom and dad are paying for school
so you can do something economically valuable, not so you can just be smart.
(In a few cases, that's not so. But in most cases it is. Further, mom and
dad are usually neither there nor if they were there are they competent
to evaluate when you are pursuing money and when you are spinning your wheels.)
> What you just now said is: once you are able to
> support yourself you have an ethical obligation to inform those who are
> supporting you of this fact. What you said earlier is more like: you have
> an ethical obligation to reach the threshold of self-supportability in an
> expeditious manner, and you should not waste your time on things that
> don't have a clear path towards profitability. It is this second position
> I take issue with, not the first.
They seem quite related to me, and I mostly endorse both readings as a
default, absent authorization to do otherwise from a specific parent or
funder or other patron.
> > It's true that Lisp doesn't always crank out money makers. That may be
> > because it's too empowering, not too limiting. Other languages can barely
> > be used for more than just cranking out a business solution, so that's all
> > anyone ever tries and it works pretty well. In Lisp, there's a certain
> > discipline required to keep the focus on business, and if you don't do that,
> > you end up off in left field doing something fun for yourself (and
> > perhaps others), but having no money at the end of the day.
>
> You assume that programming (in Lisp or whatever) needs to be a
> money-making activity. Why? What wrong with pursuing programming (in
> Lisp or whatever) as a hobby or an artistic endeavor, and doing something
> completely different as the day job?
Actually, I assume that more and more programming is impossible to make into
a money-making activity becuase of the ill effects of free software which
empowers someone but removes the economic benefit of the empowerment. One
can't easily charge for what can be obtained free, so all the free software
in the world doesn't bring me a dime closer to making money. It may bring
me closer to solving problems, but when you solve problems for free, that's
called a hobby.
> I live in Los Angeles. This town is full of actors with dreams of making
> it big in the movies. The vast majority of them will never make a dime
> from acting. And yet they do it, they find it fulfilling, and IMO they
> make the world a better place by doing it despite the fact that most of
> them will never make a dime acting. (What do you call an actor in Los
> Angeles? Waiter.) For one thing, you can find exceptionally fine
> theatre in Los Angeles for dirt cheap.
I worry that soon you'll be able to say the same about programmers.
> Maybe programming is like acting. Maybe programming in C++ is the digital
> equivalent of doing yet another mortifying performance of "Nunsense" at
> the dinner theatre while you wait for your Big Break. Maybe programming
> is something people do not to earn a living but out of passion, for the
> sheer joy of creating something, never mind that it has been created
> before. (People still find performing Shakespeare worthwhile despite the
> fact that it's been done.) Maybe Linux is analogous to all those little
> theatres in Los Angeles where exceptionally fine actors slave away for
> nothing except the opportunity to be on a stage in front of an audience,
> even a tiny one. Maybe Lisp is like some obscure form of Kabuki that only
> a small group of adherents knows how to appreciate.
Mostly fine metaphors, but I'd say "street theatre", not "dinner theatre"
since they are not charging for it.
Moreover, I'd say that in a town where street theatre is something you trip
over in every direction on your way to dinner, you aren't goign to want to
relax and PAY for theatre with your dinner. You can get all the theatre
you want when you go outside, thank you very much. Why pay for something
so easily obtained free?
> Certainly it is good for people to earn money. I just don't see why that
> necessarily has to have anything to do with programming.
Exactly. And less and less DOES programming have much to do with money.
We're producing a generation of technopeasants.
And they're going willingly.
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> Why pay for something so easily obtained free?
The impression I get is that you pose this question rhetorically, with the
intention of saying something like: it is self-evident that not getting
paid for programming is a bad thing, therefore free software is bad
because it makes it impossible to get paid for programming.
But I dispute that. I think that's a serious question: why *should* we
pay for something so easily obtained for free? If the level of effort
required to produce software of adequate quality (as judged by the
customer) is no more than people are willing to invest as a hobby, what's
wrong with that?
> Exactly. And less and less DOES programming have much to do with money.
> We're producing a generation of technopeasants.
> And they're going willingly.
Yes, and if they're going willingly I ask again, what's wrong with that?
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <···············@shell01.TheWorld.com>, Kent M Pitman
> <······@world.std.com> wrote:
> > Why pay for something so easily obtained free?
>
> The impression I get is that you pose this question rhetorically, with the
> intention of saying something like: it is self-evident that not getting
> paid for programming is a bad thing, therefore free software is bad
> because it makes it impossible to get paid for programming.
>
> But I dispute that. I think that's a serious question: why *should* we
> pay for something so easily obtained for free? If the level of effort
> required to produce software of adequate quality (as judged by the
> customer) is no more than people are willing to invest as a hobby, what's
> wrong with that?
Look at http://www.oarcorp.com. They develop and publish an open
source real-time operating system called RTEMS. Anyone can download
and use it, tweak it, etc. OAR accepts patches from RTEMS users who
choose to contribute their fixes & updates back to the source tree.
The company makes money by consulting, either helping a RTEMS user get
something done or giving assistance when porting it to previously
unsupported hardware.
Gregm
Greg Menke <··········@toadmail.com> writes:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <···············@shell01.TheWorld.com>, Kent M Pitman
> > <······@world.std.com> wrote:
> > > Why pay for something so easily obtained free?
> >
> > The impression I get is that you pose this question rhetorically, with the
> > intention of saying something like: it is self-evident that not getting
> > paid for programming is a bad thing, therefore free software is bad
> > because it makes it impossible to get paid for programming.
> >
> > But I dispute that. I think that's a serious question: why *should* we
> > pay for something so easily obtained for free? If the level of effort
> > required to produce software of adequate quality (as judged by the
> > customer) is no more than people are willing to invest as a hobby, what's
> > wrong with that?
>
> Look at http://www.oarcorp.com. They develop and publish an open
> source real-time operating system called RTEMS. Anyone can download
> and use it, tweak it, etc. OAR accepts patches from RTEMS users who
> choose to contribute their fixes & updates back to the source tree.
> The company makes money by consulting, either helping a RTEMS user get
> something done or giving assistance when porting it to previously
> unsupported hardware.
My remarks were to assert not that such systems don't exist nor that people
don't use them, but rather that the presence of things like this drive
commercial vendors out of the market because they can't afford to compete
with zero-cost product.
Kent M Pitman <······@world.std.com> writes:
> Greg Menke <··········@toadmail.com> writes:
>
> > ···@jpl.nasa.gov (Erann Gat) writes:
> >
> > > In article <···············@shell01.TheWorld.com>, Kent M Pitman
> > > <······@world.std.com> wrote:
> > > > Why pay for something so easily obtained free?
> > >
> > > The impression I get is that you pose this question rhetorically, with the
> > > intention of saying something like: it is self-evident that not getting
> > > paid for programming is a bad thing, therefore free software is bad
> > > because it makes it impossible to get paid for programming.
> > >
> > > But I dispute that. I think that's a serious question: why *should* we
> > > pay for something so easily obtained for free? If the level of effort
> > > required to produce software of adequate quality (as judged by the
> > > customer) is no more than people are willing to invest as a hobby, what's
> > > wrong with that?
> >
> > Look at http://www.oarcorp.com. They develop and publish an open
> > source real-time operating system called RTEMS. Anyone can download
> > and use it, tweak it, etc. OAR accepts patches from RTEMS users who
> > choose to contribute their fixes & updates back to the source tree.
> > The company makes money by consulting, either helping a RTEMS user get
> > something done or giving assistance when porting it to previously
> > unsupported hardware.
>
> My remarks were to assert not that such systems don't exist nor that people
> don't use them, but rather that the presence of things like this drive
> commercial vendors out of the market because they can't afford to compete
> with zero-cost product.
I don't think its a given that commercial vendors get pushed out.
vxWorks is the largest competitor in the space where RTEMS works- they
are suited to the same classes of problems. RTEMS does put a lot of
pressure on vxWorks, which is good for consumers because Wind River is
well known for their particuarly obnoxious licensing terms. Naturally
they can do whatever they choose, but strong competition will tend to
make them a little nicer to their customers..
vxWorks certainly can & does compete, and it has for years- they have
the deep pockets to dump money into fancy GUI's and quick support for
new hardware, training, lots of documentation, etc..- whereas RTEMS
doesn't offer as much in those areas.
Gregm
On 15 Mar 2003 23:07:02 -0500, Greg Menke <··········@toadmail.com> wrote:
> are suited to the same classes of problems. RTEMS does put a lot of
> pressure on vxWorks, which is good for consumers because Wind River is
> well known for their particuarly obnoxious licensing terms. Naturally
[JPL representative]: We are planning a mission to Pluto. How much would a
vxWorks license cost for that?
[Wind River marketing person]: Let's see... Our licensing fees for this
kind of application depend on the distance of the planet from Earth and to
the number of gravity assist maneuvers. Let me have a look at our price
list... It would cost you just XXX$. Wait a minute! I see that your Pluto's
orbit is weird. That will cost you an additional YYY$ as an out of ecliptic
surcharge.
[JPL representative]: Erm... what about a lunar mission?
Paolo
--
Paolo Amoroso <·······@mclink.it>
But I dispute that. I think that's a serious question: why
*should* we pay for something so easily obtained for free? If
the level of effort required to produce software of adequate
quality (as judged by the customer) is no more than people are
willing to invest as a hobby, what's wrong with that?
We are the engineers.
We know more about what our customers "want", in the sense of "if they
aren't suicidal idiots", than they express as their "wants", in the
sense of "what the market demands".
I'm not saying we're omniscient. I'm not saying that customer
priorities don't matter. I'm not saying that when market demands
confound the expectations of engineers that the market is always,
automatically wrong.
But markets have a long history of demanding stupid things from
engineers, and evil engineers have a long history of supplying it.
That's what's wrong.
In addition to hacking, we need to to do "customer education".
"We can, we can, we can drink all of fourty beers",
-t
On 13 Mar 2003 10:15:02 -0500, Kent M Pitman <······@world.std.com> wrote:
> Also, I don't have problems with money spent on tax programs for things
> like NASA or PBS or whatever _if_ there is consent of enough of the public
What is PBS?
Paolo
--
Paolo Amoroso <·······@mclink.it>
In article <····························@4ax.com>, Paolo Amoroso
<·······@mclink.it> wrote:
> On 13 Mar 2003 10:15:02 -0500, Kent M Pitman <······@world.std.com> wrote:
>
> > Also, I don't have problems with money spent on tax programs for things
> > like NASA or PBS or whatever _if_ there is consent of enough of the public
>
> What is PBS?
The Public Broadcasting System, ostensibly educational television in the
United States. Once upon a time PBS was government-sponsored, but
nowadays it's pretty much become just another commercial TV network,
albeit an eclectic one.
E.
Paolo Amoroso <·······@mclink.it> writes:
> On 13 Mar 2003 10:15:02 -0500, Kent M Pitman <······@world.std.com> wrote:
>
> > Also, I don't have problems with money spent on tax programs for things
> > like NASA or PBS or whatever _if_ there is consent of enough of the public
>
> What is PBS?
The public broadcasting system. It brought you (or us, anyway) Sesame
Street. It is therefore something that is almost as uncuttable in the
US budget as social security. Sigh.
In article <···············@shell01.TheWorld.com>,
Kent M Pitman <······@world.std.com> wrote:
> Paolo Amoroso <·······@mclink.it> writes:
>
> > On 13 Mar 2003 10:15:02 -0500, Kent M Pitman <······@world.std.com> wrote:
> >
> > > Also, I don't have problems with money spent on tax programs for things
> > > like NASA or PBS or whatever _if_ there is consent of enough of the public
> >
> > What is PBS?
>
> The public broadcasting system. It brought you (or us, anyway) Sesame
> Street. It is therefore something that is almost as uncuttable in the
> US budget as social security. Sigh.
Alas, not true. It has proven cuttable time after time over the years,
especially when one of its affiliates airs something that congressional
committeefolk consider threatening to the contributors. That might be
one of the reasons that Children's Television Workshop, creators of
Sesame Street, got renamed Sesame Workshop, got bought out by a company
with strict ROI targets, and is busy running its franchise into the
ground by licensing products (such as sugar-filled cookies) that are
demonstrably harmful to children.
PBS is as much of a budgetary sacred cow as Lisp is slow.
paul
Kent M Pitman wrote:
> Paolo Amoroso writes:
>
>
> >On 13 Mar 2003 10:15:02 -0500, Kent M Pitman wrote:
> >
> >
> >>Also, I don't have problems with money spent on tax programs for things
> >>like NASA or PBS or whatever _if_ there is consent of enough of the
> public
> >
> >What is PBS?
>
>
> The public broadcasting system. It brought you (or us, anyway) Sesame
> Street.
And a some of the few watchable news programs in this country.
> It is therefore something that is almost as uncuttable in the
> US budget as social security. Sigh.
And military expenses? More to the point no?
Cheers
--
Marco Antoniotti
Kent M Pitman <······@world.std.com> writes:
>
> I can make a piece of free software, and you all might be grateful,
> but my grocer won't.
>
What if a context exists where you write free software, and other
people write free software, and you get to use each other's software to
write programs that *do* make your grocer grateful?
I'm not a free software zealot. I use some of it--but I think most of
it is junk and find that most of the stuff that I do use was either
initially created by people payed to work or learn or owes its success
to commercial support: Mozilla, CMUCL, X, BSD, arguably Linux, etc. I
deem that the argument that all software should be free is both
ludicrous and naive. I don't contribute to free software, either--I
find it *way* to hard to go home and code in Lisp for free when I've
spent the previous 8 hours getting paid to do it.
But I think you're over-simplifying the case against free software.
The accounting may be more difficult, but, at least in the context of
Common Lisp, I think that there *is* an economic argument for free
software.
From a commercial standpoint, money is to be had by writing marketable
applications. The vast majority of applications require far more
functionality to economically construct then most Lisp environments
provide (*good* database connectivity, sockets, XML parsing,
gui's--the same old list that we've all heard recited a thousand times
before). Therefore, there's a sore need for libraries that implement
these things--but because the ANSI Common Lisp specification address
neither these functions nor the basic operators needed to implement
them (like foreign function interfaces), I don't think there is an
economical way to provide them non-gratis because the market is too
small for the level of work and expense required.
But if programmer A gives away a SQL interface for his platform and
implementation, and programmer B does the same for his, you are going
to be in a much better commercial place when your client comes along
and says "by the way, can you also present information from Foo, which
uses a Sybase database?" Maybe you'll use someone else's free code and
save a lot of time in the process. Maybe you'll respond by releasing
some code that's not specific to your app that Mr. A and Ms. B might
find useful sometime later. Everyone commercially benefits, and Lisp
wins because your customer (and later on A's and B's customers) get a
solid application delivered for less money.
There's also free Lisp software that wouldn't have made economic sense
to produce and distribute for free, but that I still think can be
argued for. For example, CMUCL is a superb implementation, and it
could have been sold commercially. But the original author(s)
certainly gained from producing it. It had value to them: that value
just didn't manifest itself as money.
Money *is* as good a metric as any other for evaluating the worth of
an act or object--but that doesn't mean it's the exclusive metric nor
does it mean there aren't situations where other metrics ultimately
prove to be of more worth. I'll go out on a limb and cite your
postings to comp.lang.lisp as proof--they ultimately cost you money,
but you continue to post.
I've not read "Atlas Shrugged" but I have read "The Fountainhead,"
which was both decent fiction and an articulate argument for a brand
of hedonism that I think is inherent in a lot of the personalities
here. I think a lot of people are drawn to Lisp because it's
empowering. Not empowering like a screwdriver and a box from Ikea,
but empowering like a saw and a forest. Creating something that
satisfies whatever aesthetic need drives them is more important then
money. Understanding how closures work so they know exactly what it
is they're creating when they use one is also empowering. It may not
be necessary to make money, but then neither is Lisp.
How do you, Kent Pitman, balance your desire for a community of
programmers that create the right thing *in the right way* with your
desire for money? I don't mean that in a rhetorical sense--I've often
wondered what I'd do if my only career option was to be yet another
Java drone. I'm also sure it's a question that a lot of people here
have thought about--how many Lispers could have made a lot more money
by using mediocre tools to create mediocre solutions to boring
problems?
Gabe Garza
Hi Kent M Pitman,
> ···@jpl.nasa.gov (Erann Gat) writes:
>
>> Ah, no, this misunderstanding is my fault. I'm mentally flipping back
>> and forth between two different intepretations of "making money."
>>
>> Making money (1) means earning a salary.
>>
>> Making money (2) means owning a share of a profitable business venture.
>
> I meant neither, btw.
>
> I meant "making money = doing something that is of sufficient value to
> one other person or several other people or many other people that they
> will, collectively, do something for you that justifies your having
> spent the time".
>
> I recently read Atlas Shrugged, by Ayn Rand, and cannot recommend it
> highly enough as a defense of what I mean by making money.
>
> When I hear people saying things like "this is valuable to people even
> though no one will pay money for it", the oxymoron indicator light on my
> internal dashboard goes on.
Your oxymoron indicator light is broken. Aligning private incentives with
the efficient provision of products with public good qualities is a known
problem.
There can be significant coordination and contracting costs that make the
private funding of many creations of sufficient value infeasible.
Regards,
Adam
"Adam Warner" <······@consulting.net.nz> writes:
> Hi Kent M Pitman,
> > When I hear people saying things like "this is valuable to
> > people even though no one will pay money for it", the
> > oxymoron indicator light on my internal dashboard goes on.
> Your oxymoron indicator light is broken. Aligning private
> incentives with the efficient provision of products with public
> good qualities is a known problem.
>
> There can be significant coordination and contracting costs
> that make the private funding of many creations of sufficient
> value infeasible.
So, now it's the tax-payer who is supposed to fund software
projects? How does it work out in Cuba?
;-)
Regards,
--
Nils G�sche
Ask not for whom the <CONTROL-G> tolls.
PGP key ID #xD26EF2A0
Hi Nils Goesche,
>> > When I hear people saying things like "this is valuable to people
>> > even though no one will pay money for it", the oxymoron indicator
>> > light on my internal dashboard goes on.
>
>> Your oxymoron indicator light is broken. Aligning private incentives
>> with the efficient provision of products with public good qualities is
>> a known problem.
>>
>> There can be significant coordination and contracting costs that make
>> the private funding of many creations of sufficient value infeasible.
>
> So, now it's the tax-payer who is supposed to fund software projects?
> How does it work out in Cuba?
>
> ;-)
It simply means that some products that would provide value to other
economic agents don't get developed.
Some countries indeed look at ways to subsidise products in their
perceived economic interest. For example the USA has been using illegal
export subsidies to prop up Microsoft Corporation for many years.
http://www.guardian.co.uk/globalisation/story/0,7369,632752,00.html
http://news.bbc.co.uk/2/hi/business/1821231.stm
Illegal tax breaks
The WTO last month found that massive tax breaks for firms like GE,
Boeing and Microsoft amounted to illegal export subsidies.
It was the fourth time in five years that the WTO ruled the tax breaks
illegal.
Regards,
Adam
I can even provide a hypothetical example that doesn't depend on public
good attributes:
> Your oxymoron indicator light is broken. Aligning private incentives
> with the efficient provision of products with public good qualities is a
> known problem.
>
> There can be significant coordination and contracting costs that make
> the private funding of many creations of sufficient value infeasible.
Say you have an idea for a utility that will give $2 of the value to half
the computing world. You would aim to sell the utility for $1. Half the
computing world would definitely buy the utility because they would spend
$1 and get $2 of value. You would also become rich as half the computing
world is a sizable population and the utility won't be too costly to
create. But you are only prepared to develop the product if you can
assured of this large purchasing base.
Now all you have to do is contract with half the computing world that they
will agree to pay you $1 if you produce the utility. Then after you have
successfully developed the utility all you have to do is find a costless
way of extracting $1 from half the computing world that agreed to buy your
product.
Even if you decide not to contract with anyone beforehand there is still
no system available that will allow someone to pay you $1 without you
losing everything in transaction costs.
We can push these numbers quite a bit higher before we get to any point
where someone might reasonably start making a profit, even though there is
millions if not billions of unrealised value before one hits breakeven.
And this one kind of best case scenario since the product can be cheaply
developed once and then sold to half the world without any further
development or marketing costs.
It becomes much more tricky in the software industry when one realises
that there are huge network externalities to overcome that naturally work
against any new entrant. One can't just produce a better product because
the value of the product depends upon what everyone else is using. It's
not hard to produce an operating system or office suite that is better
than what most people are using. What's difficult is getting everyone to
switch. Because it is only at that point that the true value of the new
product is realised. Before that point it's just another format that can't
be shared with others.
Regards,
Adam
Kent M Pitman <······@world.std.com> writes:
> When I hear people saying things like "this is valuable to people even
> though no one will pay money for it", the oxymoron indicator light on
> my internal dashboard goes on.
But I see this happen quite often. Maybe it is because I'm a
mathematician. Most people would not pay money for mathematics, though
it is beneficial and valuable, not only for society as a whole, but
for them personally. Several times I was in a situation where I could
offer advice to people for improving their product/processes and they
were interested until I told them that they should pay for it. They
seem to think that mathematics will not cost them anything.
Andreas
--
Wherever I lay my .emacs, there�s my $HOME.
···@jpl.nasa.gov (Erann Gat) writes:
> Making money (1) means earning a salary.
>
> Making money (2) means owning a share of a profitable business venture.
>
> Knowing C++, Java and Perl is demonstrably more effective than knowing
> Lisp if your goal is to make money (1).
I happen to know Perl also, and have a little Fortran experience and a
lot of system administration on my CV to prove that I could have been
a he-man programmer if I wanted to. But it was my Common Lisp
knowledge which got me the job I have now (which I'm happy as a clam
with!). I also got a very good job offer (I didn't take that job,
though) 1 year before starting in my current job. Also there, CL
experience was my best selling point even though they weren't into CL
at all.
Also, there are many degrees of making money (1). Sure, there are many
more assembly line jobs for one-dimenasional programmers knowing one
of the mainstream languages, but there are many more interesting jobs
out there for flexible people who know several languages and have a
wider palette of skills than pure assembly-line code production.
So, to all the wannabe lisp programmers in this group: Don't hesitate!
The only danger of learning CL is that you might end up with a
distaste for anything else. It's like this: If you get used to high
quality, tasty and varied, home made food, you can't eat the junk food
anymore ;-)
--
(espen)
In article <··············@merced.netfonds.no>, Espen Vestre
<·····@*do-not-spam-me*.vestre.net> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > Making money (1) means earning a salary.
> >
> > Making money (2) means owning a share of a profitable business venture.
> >
> > Knowing C++, Java and Perl is demonstrably more effective than knowing
> > Lisp if your goal is to make money (1).
>
> I happen to know Perl also, and have a little Fortran experience and a
> lot of system administration on my CV to prove that I could have been
> a he-man programmer if I wanted to. But it was my Common Lisp
> knowledge which got me the job I have now (which I'm happy as a clam
> with!). I also got a very good job offer (I didn't take that job,
> though) 1 year before starting in my current job. Also there, CL
> experience was my best selling point even though they weren't into CL
> at all.
>
> Also, there are many degrees of making money (1). Sure, there are many
> more assembly line jobs for one-dimenasional programmers knowing one
> of the mainstream languages, but there are many more interesting jobs
> out there for flexible people who know several languages and have a
> wider palette of skills than pure assembly-line code production.
>
> So, to all the wannabe lisp programmers in this group: Don't hesitate!
> The only danger of learning CL is that you might end up with a
> distaste for anything else. It's like this: If you get used to high
> quality, tasty and varied, home made food, you can't eat the junk food
> anymore ;-)
I guess I should also chime in with my own experience: I owe much of my
professional success (such as it is) to knowing Lisp. It has allowed me
to be an order of magnitude more productive than most of my peers, which
in turn has allowed me to appear to my employer to be a lot smarter than I
really am. As a result, I've done quite well as a salaryman.
But one should not underestimate the negative effects that this can have
on your life. I know lots of people who know Lisp who cannot find Lisp
jobs, who have no choice but to code in C++ or Java or Perl to pay the
rent, and many of them are miserable. (I did this for a year and I was
miserable.) Sometimes ignorance can be bliss. It really depends on what
you want out of life.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> But one should not underestimate the negative effects that this can
> have on your life. I know lots of people who know Lisp who cannot
> find Lisp jobs, who have no choice but to code in C++ or Java or
> Perl to pay the rent, and many of them are miserable.
Add me to your list. Though my C++ knowledge eclipses my CL knowledge
by a factor of ~20, I would gladly take the hit in "technical
stature" to dive into CL full-time.
> (I did this for a year and I was miserable.)
How did you manage to limit it to a year?
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
In article <··············@harris.sdo.us.ray.com>, Steven E. Harris
<········@raytheon.com> wrote:
> > (I did this for a year and I was miserable.)
>
> How did you manage to limit it to a year?
Not sure I understand the question. After a year, I quit. But I suspect
that's not the answer you were looking for.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> After a year, I quit. But I suspect that's not the answer you were
> looking for.
Quitting a job without CL is only partway toward having a job with
CL. I was curious about how you wound up finding that CL job after
only a year of searching.
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
In article <··············@harris.sdo.us.ray.com>, Steven E. Harris
<········@raytheon.com> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > After a year, I quit. But I suspect that's not the answer you were
> > looking for.
>
> Quitting a job without CL is only partway toward having a job with
> CL. I was curious about how you wound up finding that CL job after
> only a year of searching.
Ah. Go back and read what I wrote and you will see that you are making an
unwarranted assumption. I didn't find a CL job.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> But one should not underestimate the negative effects that this can have
> on your life. I know lots of people who know Lisp who cannot find Lisp
> jobs, who have no choice but to code in C++ or Java or Perl to pay the
> rent, and many of them are miserable. (I did this for a year and I was
> miserable.) Sometimes ignorance can be bliss. It really depends on what
> you want out of life.
Sometimes ignorance can be a bliss, but these days I think it's pretty
clear what horrors ignorance can create.
"The evil that is in the world almost always comes of ignorance, and
good intentions may do as much harm as malevolence if they lack
understanding."
Albert Camus
--
(espen)
Espen Vestre wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
>
>>Making money (1) means earning a salary.
>>
>>Making money (2) means owning a share of a profitable business venture.
>>
>>Knowing C++, Java and Perl is demonstrably more effective than knowing
>>Lisp if your goal is to make money (1).
>
>
> I happen to know Perl also, and have a little Fortran experience and a
> lot of system administration on my CV to prove that I could have been
> a he-man programmer if I wanted to. But it was my Common Lisp
> knowledge which got me the job I have now (which I'm happy as a clam
> with!).
Are you working in Norway? If so, can you say anything about the
company you are working for?
I am curious since I might get a job in Norway in a few years
(I am norwegian after all :) when I graduate.
--
Thomas.
···@jpl.nasa.gov (Erann Gat) wrote in message news:<····················@dialin-072.jpl.nasa.gov>...
>
> Making money (2) means owning a share of a profitable business venture.
...
> Very few people have ever made money (2) using Lisp. (I know of only one case.)
There are certainly more than that. Successful Lisp-based startups are
not that numerous but they do exist. Off the top of my head, here are
some companies that have made (or probably will make) at least some of
their founders rich:
- Symbolics (some of the founders cashed out at the right time)
- Afferent (acquired by MDL)
- Viaweb (Paul Graham's company, acquired by Yahoo)
- ITA (doing well, I assume)
I'm sure there are others that I don't know about. The question is,
why aren't there more? If Lisp really makes small teams so much more
productive, it should be the ideal vehicle for startup software
companies. Maybe you are right and it's the combative nature and
un-economic instincts of Lisp programmers in general that stand in the
way.
From: Christopher C. Stacy
Subject: Re: Learning new things
Date:
Message-ID: <usmtqkja4.fsf@dtpq.com>
>>>>> On 13 Mar 2003 10:33:45 -0800, Michael Travers ("Michael") writes:
Michael> The question is, why aren't there more? If Lisp really
Michael> makes small teams so much more productive, it should be the
Michael> ideal vehicle for startup software companies.
I don't think it's a philosophical problem with Lisp programmers,
but simply a demonstration of ignorance by the people who are
creating the start-up companies; partly this comes from the fact
that there are not as many Lisp programmers as other languages,
and the startup-starters see that as an area of unnecessary risk.
Also, I don't think there's a philosophical problem with Lisp
programmers that prevents them from being the ones who conceive
and control the starting up of new companies (any more than any
other computer programming language devotee's psyche).
······@dtpq.com (Christopher C. Stacy) writes:
> >>>>> On 13 Mar 2003 10:33:45 -0800, Michael Travers ("Michael") writes:
> Michael> The question is, why aren't there more? If Lisp really
> Michael> makes small teams so much more productive, it should be the
> Michael> ideal vehicle for startup software companies.
>
> I don't think it's a philosophical problem with Lisp programmers,
> but simply a demonstration of ignorance by the people who are
> creating the start-up companies; partly this comes from the fact
> that there are not as many Lisp programmers as other languages,
> and the startup-starters see that as an area of unnecessary risk.
Actually, as I'm sure you know, this also works from the other end,
too. Failed projects require scapegoats. In recent years, people
invested in companies that weren't making money and pretended that
this was ok, then scapegoated businesses that used ".com" in their
name. In the 1980's, they invested in companies that promised AI
would solve all the world's problems, then blamed LISP (as if C++
could have done better). Come up with a good excuse and you'll
survive to fund yet another startup and blame its failure on some
other contrived fall guy. Worse still, if you do survive, you'll have
to make sure never to use any of that technology you scapegoated
before because if it works this time, you might have to admit it
wasn't the technology but you yourself that caused the earlier
downfall...
Kent M Pitman wrote:
> In the 1980's, they invested in companies that promised AI
> would solve all the world's problems, then blamed LISP (as if C++
> could have done better).
The AI winter might have been avoided if C++ was used. For the simple
reason that C++ would never have gotten peoples hopes up in the first
place.
--
Thomas.
Thomas Stegen CES2000 <··············@cis.strath.ac.uk> writes:
> Kent M Pitman wrote:
> > In the 1980's, they invested in companies that promised AI
> > would solve all the world's problems, then blamed LISP (as if C++
> > could have done better).
>
> The AI winter might have been avoided if C++ was used. For the simple
> reason that C++ would never have gotten peoples hopes up in the first
> place.
I thought of this. And you're right, of course, though what you're
saying implies AI summer would have been avoided, too. Trivially,
most people who's software and ideas are never used never get their
name smeared. Kind of a steep rice to pay for that honor, though.
······@dtpq.com (Christopher C. Stacy) wrote in message news:<·············@dtpq.com>...
> >>>>> On 13 Mar 2003 10:33:45 -0800, Michael Travers ("Michael") writes:
> Michael> The question is, why aren't there more? If Lisp really
> Michael> makes small teams so much more productive, it should be the
> Michael> ideal vehicle for startup software companies.
>
> I don't think it's a philosophical problem with Lisp programmers,
> but simply a demonstration of ignorance by the people who are
> creating the start-up companies;
In all the examples I cited earlier, the founders *were* Lisp hackers
so this problem didn't arise. My question wasn't really "why don't
more startups use Lisp?" but "why don't more Lisp hackers found
startups?"
In other words, I wish people would stop kvetching about how they
aren't allowed to use Lisp, and figure out some solution that will
let them make a living doing what they like to do, and maybe get
rich from it. Not that it's easy, but it is in the realm of possibility.
··@alum.mit.edu (Michael Travers) writes:
> ······@dtpq.com (Christopher C. Stacy) wrote in message news:<·············@dtpq.com>...
> In all the examples I cited earlier, the founders *were* Lisp hackers
> so this problem didn't arise. My question wasn't really "why don't
> more startups use Lisp?" but "why don't more Lisp hackers found
> startups?"
I haven't been following this thread too closely, so someone else
might have already said this...
One answer might be that to found a startup you need money. The
people that give out money, VCs, were burned by AI in the 80's and
Lisp received some of that fallout. After the rise and somewhat fall
of C++, and then the rise of Java, I would say that VCs are currently
more likely to fund a Java-based startup than a Lisp-based startup.
From what I've known of VCs, or people at the this level, it makes
intuitive sense to me. They are people that run with their own
instincts, and these instincts usually do not involve Lisp. My
observation of these types is that they also make quick judgements,
and I think we all know that a quick judgement is likely to go against
Lisp--it's likely to be more conventional, and Lisp is not
conventional.
Aside from this, many of us have anecdotal evidence of VCs criticizing
the worthiness of Lisp and their lack of willingness to support it.
Put it all together and I don't think it is surprising that more Lisp
hackers don't found startups the traditional way. That leaves the
untradional way, using their own capital. Much fewer startups start
this way, with or without Lisp, for the obvious reason.
Kevin Layer <·····@*n*o*s*p*a*m*franz.com> wrote in message news:<··············@*n*o*s*p*a*m*franz.com>...
> ··@alum.mit.edu (Michael Travers) writes:
>
> > ······@dtpq.com (Christopher C. Stacy) wrote in message news:<·············@dtpq.com>...
> > In all the examples I cited earlier, the founders *were* Lisp hackers
> > so this problem didn't arise. My question wasn't really "why don't
> > more startups use Lisp?" but "why don't more Lisp hackers found
> > startups?"
>
> I haven't been following this thread too closely, so someone else
> might have already said this...
>
> One answer might be that to found a startup you need money. The
> people that give out money, VCs, were burned by AI in the 80's and
> Lisp received some of that fallout. After the rise and somewhat fall
> of C++, and then the rise of Java, I would say that VCs are currently
> more likely to fund a Java-based startup than a Lisp-based startup.
Why do you have to reveal that you are Lisp-based? Can you say you use
Java, and then in fact use it to write, say, the splash-screen for the
installer?
Kevin Layer <·····@*n*o*s*p*a*m*franz.com> writes:
> Put it all together and I don't think it is surprising that more
> Lisp hackers don't found startups the traditional way. That leaves
> the untradional way, using their own capital. Much fewer startups
> start this way, with or without Lisp, for the obvious reason.
Of course these days the VC guys aren't writing a lot of checks. So if
you want to do something, now's probably a great time for a
bootstapped startup. And if, as *we* all believe, Lisp gets you there
faster with fewer programmers, then you should be able to dramatically
increase your odds of writing some piece of software that's actually
worth money to someone before you run out of money (your own money, or
that of friends-and-family angel investors). *And* if we further
really believe that that software written in Lisp is more maleable
than that written in other languages, then you also gain the advantage
of after a quick sprint to having *something* you can sell, you can
move right along on to the next bigger-and-better thing that you can
sell for even more. Of course you do still have to come up with that
product idea, as Erann Gat rightly pointed out. But even there, less
so, perhaps, if you use Lisp--when HP started they were just two guys
who knew how to build electronics. And they scrounged around for
projects including goofy stuff like a gutter-ball detector for a
bowling alley. But they managed to build up a profitable company
without a single "big idea". Seems like a few smart Lisp programmers
who keep costs way down and focus relentlessly on writing software
that someone is actually willing to pay for might soon be able to grow
a codebase on which they could build a fine portfolio of products.
Eventually one of those products might be the "next big thing" and
everybody gets rich.
-Peter
--
Peter Seibel ·····@javamonkey.com
The intellectual level needed for system design is in general
grossly underestimated. I am convinced more than ever that this
type of work is very difficult and that every effort to do it with
other than the best people is doomed to either failure or moderate
success at enormous expense. --Edsger Dijkstra
Peter Seibel <·····@javamonkey.com> wrote in message news:<··············@localhost.localdomain>...
> faster with fewer programmers, then you should be able to dramatically
> increase your odds of writing some piece of software that's actually
> worth money to someone before you run out of money (your own money, or
Or if you do run out of money sooner than expected, you can apply
for a loan guaranteed by the Small Business Administration. I don't
know how big such loans tend to be, but they might make all the
difference in being able to continue full time instead of looking for
a job on the side.
Kevin Layer <·····@*n*o*s*p*a*m*franz.com> wrote in message news:<··············@*n*o*s*p*a*m*franz.com>...
> ··@alum.mit.edu (Michael Travers) writes:
>
> > ······@dtpq.com (Christopher C. Stacy) wrote in message news:<·············@dtpq.com>...
> > In all the examples I cited earlier, the founders *were* Lisp hackers
> > so this problem didn't arise. My question wasn't really "why don't
> > more startups use Lisp?" but "why don't more Lisp hackers found
> > startups?"
>
> One answer might be that to found a startup you need money. The
> people that give out money, VCs, were burned by AI in the 80's and
> Lisp received some of that fallout. After the rise and somewhat fall
> of C++, and then the rise of Java, I would say that VCs are currently
> more likely to fund a Java-based startup than a Lisp-based startup.
I have worked for an technology incubator for a time and seen a number
of startups and VCs operate. My impression is that VCs are _not_
interested in technical details (Java vs. CL vs. whatever) at all.
They are interested in how big your market is, how you plan to get
into your market and when you will start making money and how much.
There was a point in history where using Java was "a plus", nowadays
you need a bright idea for a product, a market, and the right
personality to find funding.
In addition, if you are really convinced that using CL brings you a
competitive advantage but you are unable to convince your VCs then you
are probably not the right person for starting a startup in the first
place: It is really important to be able to convince others
(employees, customers) of ones ideas and visions.
So when asking why there were not more startups using Lisp in the past
a number of technical and economical reasons come to mind:
(1) There are not many (Common) Lisp hackers in the first place.
(2) In the past many startups had something to do with the internet.
Library support for internet protocols, database access, etc. is not
as good for CL as it is for other programming languages.
(3) A very small startup might not want to pay license fees for a
commercial Lisp implementation, and library support for free Lisp
implementations might not be sufficient for their needs.
(4) If you need to deliver software to many clients (as opposed to a
few servers only; let's say you distribute a napster-like p2p client)
you do not want users to have to install a CL implementation first.
These are points to consider when starting a startup. Of course, all
these points are well-known, (2) might be changing, (3) might not be
an issue and (4) is solved for some CL implementations.
Matthias
On 15 Mar 2003 04:19:18 -0800, ······@gmx.de (Matthias) wrote:
> So when asking why there were not more startups using Lisp in the past
> a number of technical and economical reasons come to mind:
>
> (1) There are not many (Common) Lisp hackers in the first place.
The growing number of Lispnik groups popping almost everywhere seems to
suggest that the number of Lisp hackers might have been underestimated.
Paolo
--
Paolo Amoroso <·······@mclink.it>
Kevin Layer wrote:
> ··@alum.mit.edu (Michael Travers) writes:
>
>
>>······@dtpq.com (Christopher C. Stacy) wrote in message news:<·············@dtpq.com>...
>>In all the examples I cited earlier, the founders *were* Lisp hackers
>>so this problem didn't arise. My question wasn't really "why don't
>>more startups use Lisp?" but "why don't more Lisp hackers found
>>startups?"
>
> One answer might be that to found a startup you need money. The
> people that give out money, VCs, were burned by AI in the 80's and
> Lisp received some of that fallout. After the rise and somewhat fall
> of C++, and then the rise of Java, I would say that VCs are currently
> more likely to fund a Java-based startup than a Lisp-based startup.
I have worked for a technology incubator for some time and seen a number
of startups and a number of VCs. My impression was that the VCs are
_not_ much interested in technical details as which implementation
language you choose. VCs care much more about how big your market is
and how you plan to get into this market and how you will end up making
money. VCs are more interested in making money than in discussions on
Java-vs-CL.
In addition: If you think there is a strong technical point for using
Lisp but you are not able to explain this point to your VCs then you are
probably not the right person to start a startup in the first place.
Being able to convince other people of one's ideas is really important
for startup founders.
Matthias
M H <··@nospam.org> writes:
> I have worked for a technology incubator for some time and seen a
> number of startups and a number of VCs. My impression was that the
> VCs are _not_ much interested in technical details as which
> implementation language you choose. VCs care much more about how big
> your market is and how you plan to get into this market and how you
> will end up making money. VCs are more interested in making money
> than in discussions on Java-vs-CL.
This is one of at least two possible success scenarios for a business.
The other is where you build something and sell out to another company.
Sometimes if you know the buyer, you may know they are a shop that uses
only a certain language or languages (for better or worse).
In that case, they may have staffing requirements on what they will and
won't take, for whatever reason.
> In addition: If you think there is a strong technical point for using
> Lisp but you are not able to explain this point to your VCs then you
> are probably not the right person to start a startup in the first
> place. Being able to convince other people of one's ideas is really
> important for startup founders.
Or it may be that the strong technical point you see isn't really there.
There are some good reasons to use Lisp, and then there are some reasons
that you only think dictate Lisp. Sometimes when people flounder, it's
because they're not actually pushing an edge Lisp has over something else.
I prefer to try to opt out of such battles as much as I can. I don't use
Lisp because it's provably better than other languages. For all I know,
it's not. I use it because _I_ get more out of it than _I_ get out of
other languages. This allows me to best predict what I can do in what
amount of time, and to meet goals I need to meet.
Once, a long time ago, Stallman noticed that the emacs command m-c
(capitalize next word), m-l (lowercase next word), and m-u (uppercase
next word) were quite often needed at the end of text just typed
[often at the end of the buffer, but sometimes just after a bunch of
self-insertion], and so almost always in those cases preceded by m-b
(go back one word). This was in teco-based emacs, btw, so if you
don't remember this you probably are thinking of the gnu stream.
Anyway, he changed it for a while to make these commands do different
things based on whether the last character was self-inserting or not.
If you had just done a cursor-motion command, then m-c/m-l/m-u all
operated on the NEXT word, but if you had just done a self-inserting
command they operated on PREVIOUS word. This was statistically more
likely at any moment to be what a person needed. HOWEVER, the change
upset pretty much everyone. The command, while smarter, was no longer
very predictable. And it was found that predictability was more important
than smartness in a throughput oriented task. I think there is a
metaphor here to business. Business cares a lot about time to market
and other things. But even more important than time to market is
predictable time. If you can't predict the time it will take reliably,
the length of the prediction (or the result) is not relevant. So sometimes
a mediocre language will suit better if it's more predictable.
For me, at least, Lisp is both faster and more predictable. Get a team
that can do that, and you're good using Lisp. Get a team that is better
with another language AND more predictable with it and you're also good.
But get a mismatch, and you've got a disaster.
* M H wrote:
> I have worked for a technology incubator for some time and seen a
> number of startups and a number of VCs. My impression was that the
> VCs are _not_ much interested in technical details as which
> implementation language you choose. VCs care much more about how big
> your market is and how you plan to get into this market and how you
> will end up making money. VCs are more interested in making money
> than in discussions on Java-vs-CL.
Yes, this is pretty much what tried to say: you have to have an idea
which will make money, and have it at the right time. If you have no
ideas or only bad ideas (like `implement an SMTP library for Lisp')
then you won't win, whatever.
--tim
On 2003-03-15, Tim Bradshaw <···@cley.com> wrote:
> * M H wrote:
> If you have no ideas or only bad ideas (like `implement an SMTP
> library for Lisp') then you won't win, whatever.
I'm curious about your selection of an SMTP library for an idea that
would "be bad" in lisp. I know that certain languages are better than
others for different tasks, but having just written an SMTP server and
just reastarted my Lisp programming, what makes Lisp a bad language
for implementing a task like that?
(As a disclaimer in case this is taken as flaimbait. Normally I test
out languages I'm unfamiliar with by programming something I've done
before in the new language, and having just completed the server it
seems natural to me to apply that knowledge to a new language and see
if it was easier/harder/impossible to do as compared with the the old
one. So, assuming you people have more experience with me and might
have actually tried such a task, I'm asking for your experiences for
something that would traditionally be done in a language like C as
opposed to Lisp).
--
burton samograd
······@hotmail.com
http://kruhftwerk.dydns.org
* Burton Samograd wrote:
> On 2003-03-15, Tim Bradshaw <···@cley.com> wrote:
> I'm curious about your selection of an SMTP library for an idea that
> would "be bad" in lisp. I know that certain languages are better than
> others for different tasks, but having just written an SMTP server and
> just reastarted my Lisp programming, what makes Lisp a bad language
> for implementing a task like that?
Nothing makes it bad. What would be bad is planning to write an SMTP
library (by which I meant something that lets you talk to sendmail &c,
not a sendmail replacement) *as a business plan*. In fact, I'll
extend that: writing an MTA as a business plan is probably not really
a good idea. Writing an SMTP library for fun or education is a
different question.
--tim
Tim Bradshaw <···@cley.com> writes:
> In fact, I'll extend that: writing an MTA as a business plan
> is probably not really a good idea.
not if "writing an MTA" is _the_ bussiness plan. But if you have
a really bright idea for an MTA with an amazingly efficient spam-
filter built in...
--
(espen)
* Espen Vestre wrote:
> not if "writing an MTA" is _the_ bussiness plan. But if you have
> a really bright idea for an MTA with an amazingly efficient spam-
> filter built in...
Yes. Except most of the current MTAs can have filtering plugged in
pretty easily (certainly sendmail can, in the limited sense that
anything is easy with sendmail). So really the business plan I'd go
for would be `writing a spam filter that works and which can be
plugged into a number of popular MTAs'. And look, what's Paul Graham
working on?
--tim
On 2003-03-17, Tim Bradshaw <···@cley.com> wrote:
> Yes. Except most of the current MTAs can have filtering plugged in
> pretty easily (certainly sendmail can, in the limited sense that
> anything is easy with sendmail). So really the business plan I'd go
> for would be `writing a spam filter that works and which can be
> plugged into a number of popular MTAs'. And look, what's Paul Graham
> working on?
Which was exactly what I was working on during my last contract. That
is something that fits Paul Graham's (I think) "6 month/first to
market" window showing how lisp has an advantage over other languages,
except for the fact that I wrote it in 3-4 months in C. The problem
with that business model is that it will be so flooded with competion
in the next few months (but it might be already) that your business
plan will be great but nobody will be around to buy it since they
already can get it for free (even my product was given away open
sourced with a proprietary database version) and I know there are
*many* more out there. Even though it sounds like a good plan for a
business there really is no long range growth in following this trend
IMHO.
--
burton samograd
······@hotmail.com
http://kruhftwerk.dydns.org
Hi Burton Samograd,
> On 2003-03-15, Tim Bradshaw <···@cley.com> wrote:
>> * M H wrote:
>> If you have no ideas or only bad ideas (like `implement an SMTP library
>> for Lisp') then you won't win, whatever.
>
> I'm curious about your selection of an SMTP library for an idea that
> would "be bad" in lisp. I know that certain languages are better than
> others for different tasks, but having just written an SMTP server and
> just reastarted my Lisp programming, what makes Lisp a bad language for
> implementing a task like that?
You completely missed the point being made in the thread :-) It's not a
bad language to implement the task in. You just won't make any money doing
it. A lot of software is now a commodity. Web browsers, servers, whole
operating systems, languages, compilers and editors. If one is looking to
make money selling proprietary software the idea should be innovative
enough to provide a window where one will not be directly competing with
preexisting free/open source/inexpensive commodity software.
I see this as the mistake Kent Pitman made in developing a proprietary web
server: <http://okmij.org/ftp/papers/ILC02-impressions.txt>. Even without
the Franz web server, Apache is extreme competition. Microsoft can't even
make money selling a web server. They just bundle it with some of their
operating systems.
Regards,
Adam
Adam Warner wrote:
> You completely missed the point being made in the thread :-) It's not a
> bad language to implement the task in. You just won't make any money doing
> it. A lot of software is now a commodity. Web browsers, servers, whole
> operating systems, languages, compilers and editors. If one is looking to
> make money selling proprietary software the idea should be innovative
> enough to provide a window where one will not be directly competing with
> preexisting free/open source/inexpensive commodity software.
I tend to disagree for a couple of reasons.
First, any software written in Lisp would be much less susceptible to the
types of buffer overrun attacks, memory allocation errors, etc. that plague
their bretheren written in C and C++. This could make an SMTP server
written in Lisp much more reliable, robust, and secure than the
alternatives. I still think that there is a market that will pay for
security, so if the application touts the security benefits, it can still
make money.
Second, just because there is a "free" alternative doesn't mean that one
cannot make money in the market. There are many free database tools. This
doesn't mean that Oracle and Microsoft can't make money in databases. You
just have to find an underserved niche - like always.
faa
"Frank A. Adrian" <·······@ancar.org> writes:
> Second, just because there is a "free" alternative doesn't mean that one
> cannot make money in the market. There are many free database tools. This
> doesn't mean that Oracle and Microsoft can't make money in databases. You
> just have to find an underserved niche - like always.
But didn't Oracle and others keep the price of databases artificially
high for a really long time when they could have been dropping prices
dramatically? I thought antitrust law attempted to notice when all
vendors appeared to wink at each other and say "let's keep the rates
up" rather than having natural market forces drive it down. I guess I
mean this is a job for antitrust law, not for free software 'avengers'.
At this point, I don't think Oracle is threatened by free software databases
since they are probably already making most of their money on consulting,
support, and other residuals, not on the basic product. A free software
entrant is not likely to bring them down, in other words. What it will do
is keep other commercial entrants from moving in, because it will shave so
much off the potential low end offering price that it will assure there will
be no low end commercial version.
There is a natural motion from a new product offering for something
that becomes popular to things like support contracts, etc. Little
companies that crank out initial product are not capitalized enough to
do an effective job of covering support, and are likely to be made or
broken on their sales to start with. (An exception is when they are
selling the precise thing that another company has said they will come
out with but that was vaporware, and that is where the new company
just gets bought or licensed to fulfill the big company's need. But
that doesn't create competition either. It just lazily implements an
R&D department for the big company with less economic risk to itself.)
I claim that if you undercut the cost of sales on an initial product,
you rob the ability of any new company to start on mere sales of
product, and you therefore injure competition irreparably.
Which is why the example of Oracle is a non-issue. It's too old a
company, and its success or failure out the starting gate is not in
issue. Unlike my (or anyone's) fledgling company, it can afford to
have wasted a half-year of someone's time without the company being
crippled. Established companies can and often do have internal safety
from past revenue, from multiple from multiple products going, perhaps
from multiple new products in the making, from ongoing sales of
existing products to carry it through. New companies have no such
safeguards.
"Frank A. Adrian" <·······@ancar.org> writes:
> There are many free database tools. This doesn't mean that Oracle and
> Microsoft can't make money in databases. You just have to find an
> underserved niche - like always.
Oracle and MS do _not_ succeed today by finding an underserved niche in
DBs and OSes. They don't worry about the free tools for much the same
reason that they don't worry about other commercial competitors: both have
managed to become de facto standards in their industry, and their monopoly
position allows them continued sales regardless of the quality of their
product.
It's a fabulous business position to be in, and one that most other companies
are extremely jealous of. But don't make the mistake of concluding that they
somehow found an underserved niche, and that a new startup could have done the
same thing if only they were clever enough.
Kent M Pitman <······@world.std.com> writes:
> I thought antitrust law attempted to notice when all
> vendors appeared to wink at each other and say "let's keep the rates
> up" rather than having natural market forces drive it down.
I think in this case, the pressure comes from the monopoly power of Oracle
and MS by themselves, not any collaboration with their competitors. (They
generally just ignore their competitors.)
Unfortunately, antitrust law doesn't actually prohibit monopolies. It only
prohibits using the power of a (legal) monopoly in one domain to attack a
new market "unfairly".
Microsoft was never going to be punished for selling the only feasible PC OS.
Instead, it was whether they used that monopoly in order to dominate further
industries like web browsers, office productivity, and online ISPs.
> At this point, I don't think Oracle is threatened by free software databases
> since they are probably already making most of their money on consulting,
> support, and other residuals, not on the basic product.
I don't think the product price is the issue in any case. That's rarely why
people choose Oracle. They choose it because everyone else has already chosen
it, and there are books and consultants who address Oracle, and their other
software already comes with Oracle plug-ins, etc. The price of the basic
product is a very minor part of the decision making.
Ah, isn't it beautiful to own a monopoly platform? :-)
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org ···@geddis.org
When I was a child, there were times when we had to entertain ourselves. And
usually the best way to do that was to turn on the TV.
-- Deep Thoughts, by Jack Handey
Don Geddis wrote:
> both have
> managed to become de facto standards in their industry, and their monopoly
> position allows them continued sales regardless of the quality of their
> product.
Well, the last I checked, MySQL and/or PostgreSQL are not even close to
being equals to eith of the DB servers I mentioned. Especially for
enterprise-level applications.
My point is that I see no particular reason (as one employed in the
for-profit software field) to fear not-for-profit software. You may be
able to put more bodies on the not-for-profit software, but that really
means squat. I guess I have enough faith in my own abilities to believe
that what I can do together with a stable team of peers while focused by
the desire to feed my family can best an ad hoc crew of programming
ragamuffins ding something for a hobby. If I am wrong, then so be it. I
guess I'll sell real estate or something.
My question is why the Randians here see businesses as something that need
to be protected from hobbyists? If the businesses are so weak that they
need this type of protection, then there must not be that large of a demand
for their services and they deserve to fail, huh? Bottom line, you can't
have it both ways. Either you truly believe in a free market and let the
chips fall where they may - even in the face of alternative non-coercive
economic models that may threaten the enterprise - or you don't.
faa
P.S. I don't have this issue since I'm not a Randian.
On Mon, 17 Mar 2003 21:18:00 -0800, "Frank A. Adrian"
<·······@ancar.org> wrote:
>My question is why the Randians here see businesses as something that need
>to be protected from hobbyists?
What Randians? The only person I've seen arguing that is Kent, and
even he hasn't said "need to be protected" so much as "be aware that
what you're doing may have negative consequences as well as positive
ones" - which I agree with.
I don't agree with everything Ayn Rand said, but I have sympathy with
a lot of her views, and I don't think businesses need to be protected
from anyone except criminals (whether they be individuals or
governments).
>If the businesses are so weak that they
>need this type of protection, then there must not be that large of a demand
>for their services and they deserve to fail, huh? Bottom line, you can't
>have it both ways. Either you truly believe in a free market and let the
>chips fall where they may - even in the face of alternative non-coercive
>economic models that may threaten the enterprise - or you don't.
I agree. I would _like_ people to stop giving away free software, but
I don't think I've a moral right to expect that.
I don't think it's the big problem though. Really, the big problem is
that we've a glut of programmers because millions of people took up
the trade when the industry was in its exponential growth stage, and
now it's matured the supply of programmers exceeds the demand.
The solution is for people to take up a different trade instead. As
I've remarked before, as far as I can see one is much better off
trying to find work as an electrician or a carpenter than a programmer
nowadays.
--
"Sore wa himitsu desu."
To reply by email, remove
killer rodent from address.
http://www.esatclear.ie/~rwallace
·············@eircom.net (Russell Wallace) writes:
> On Mon, 17 Mar 2003 21:18:00 -0800, "Frank A. Adrian"
> <·······@ancar.org> wrote:
>
> >My question is why the Randians here see businesses as something
> >that need to be protected from hobbyists?
>
> What Randians? The only person I've seen arguing that is Kent, and
> even he hasn't said "need to be protected" so much as "be aware that
> what you're doing may have negative consequences as well as positive
> ones" - which I agree with.
>
> I don't agree with everything Ayn Rand said, but I have sympathy with
> a lot of her views, and I don't think businesses need to be protected
> from anyone except criminals (whether they be individuals or
> governments).
Sometimes society must also be protected from lunatics and irrational
philosophies. Communists caused a lot of havoc and suffering in the
20th century (and their intellectual heirs still do), notwithstanding
that their economic system was rather inefficient, for instance. And
that islamic fundamentalists are crazy doesn't mean they can't cause a
lot of damage.
Hobbyists? Don't know about you but the truly hobbyist programmers I
met simply cannot write any significant program, free or not. The
people who wrote Apache certainly weren't hobbyists, and I wouldn't
call Linus Torvalds a hobbyist, either. Somebody is paying for all
that programmer time, be it the tax-payer or their parents. Somebody
is putting money into their education, and even when they are
self-taught, somebody is paying for their food and rent while they do.
If they are professional programmers working in their spare time, it's
themselves who is subsidizing free software.
Now, if it indeed happened that professional software can't be written
anymore because most or all software companies are driven out of
business because of competition by thusly subsidized free products,
where is the next generation of free software developers supposed to
come from? Neither the tax-payer nor Mom and Dad are going to spend
any money anymore for making Little Joe Would-Be-Hacker a professional
programmer if it is clear that they are not going to be able to make
one cent with their education. They'll tell him to become a lawyer
instead. And the remaining professional programmers won't have any
job and cannot subsidize anything, either, anymore.
So, apparently all those professional programmers (and soon-to-be
professional programmers like CS students) are working against their
very own self-interest. When this happens, it is most likely because
somebody is indoctrinating them with irrational philosophies
(typically of some socialist kind in our universities).
> >If the businesses are so weak that they need this type of
> >protection, then there must not be that large of a demand for their
> >services and they deserve to fail, huh? Bottom line, you can't
> >have it both ways. Either you truly believe in a free market and
> >let the chips fall where they may - even in the face of alternative
> >non-coercive economic models that may threaten the enterprise - or
> >you don't.
>
> I agree. I would _like_ people to stop giving away free software,
> but I don't think I've a moral right to expect that.
Nobody is arguing that the /police/ should stop people from making
free software ;-) But it might help if more people start telling them
that they are, irrationally, working against their very own
self-interest (and thus, following Rand, ultimately against everybody
else's interest, too).
Maybe free software won't kill all software companies. Can't say I
truly expect that. But it might indeed do damage. It would be nice
if people would consider that, too, for a change.
> To reply by email, remove
> killer rodent from address.
Why? If it attacked you, you might get a peace nobel price, too.
Although maybe you'd have to ruin a major economy, first. Can't say I
really understand the criteria for getting that price anymore ;-)
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
Nils Goesche <······@cartan.de> writes:
> Maybe free software won't kill all software companies. Can't say I
> truly expect that. But it might indeed do damage. It would be nice
> if people would consider that, too, for a change.
[I wanted to expand on this point.]
The most attractive (but I think still misleading) argument that I hear is
that "there are still ways of making money".
But the problem I have with that is that again it transforms the market
from "competition over the product" to "competition over the support of
the product".
We spend enormous time and text here touting the value of Lisp and wondering
why people are not buying it. But capitalism only rewards successes in the
market. It doesn't dissect the internal components of a product and say
"you know, the support for this product is not as good but wow the internals
are cool". So any time that inferior software gets wrapped with better
support, you're going to end up using inferior software.
And since existing organizations are probably the ones with better support,
because support requires heavy capitalization and a pre-existing company
is in the position to offer that better, then existing organizational
preferences for tools are going to prevail. That means that if people
used to not like Lisp, existing organizations are going to carry that
prejudice along.
And so it's not necessary for companies to "go out of business" for it to be
bad for Lisp that free software is out there. If only the "success scenario"
that some people advance happens, that is, if only the competition domain
becomes not "Lisp" but "language+support", then already Lisp (or any technology
tool per se) has the odds stacked against it.
So you might as well stop caring about the answer to the question "what
technology is better" once you take the capitalistic lens off of its focus
on the technology. You are no longer competing on that basis.
So if you want Lisp to succeed, it is not in your self-interest to transform
the market to not be about languages.
I think it's premature to blame free software for killing
professional software development.
That is because I believe that there are potential business models
(not "support" -- but models in which people are paid for original
programming) that are compatible with free software and, in fact,
for which free software licenses are a better business tool than
proprietary licenses. Would it be in scope here to talk about
those models? Perhaps someone here can help to implement them.
I think it is not too soon to raise some eyebrows at the companies who
are making money with free software. _By design_, pretty much
universally, they are limiting their f.s. R&D investment to some very
short term, tactical plays -- and they are planning on getting more
general R&D "for free" from hobbyists and university students and
university researchers. They aren't trying to "solve the problem" of
moving to free software while keeping a thriving R&D engine flowing --
they're taking advantage of a new 0-price commodity without addressing
where it comes from. They are taking careful aim at their own feet,
if you ask me.
That _is_ destructive. And it is also not rationally self interested.
Interpreted as being about those companies, rather than about free
software, a lot of Kent's statements make great sense.
As an example: It isn't hobbiests who are killing the unix industry.
Yes, volunteers provided a lot of raw materials but, ca. 1994, those
raw materials could not compete against, for example, Solaris in the
commercial market. That critical last delta came from short-term
tactical R&D by the companies, and sadly, it was implemented without
any apparent care in the world about where the next generation of "raw
materials" would come from.
No...I take that back. They had some thoughts. Company policies
along the lines of: "If, instead of taking a coffee break, you want to
spend some time on a free software project of your choosing -- that's
cool: we won't try to stop you. (And implicitly: it will help you at
review time.)" Gee. Thanks.
In this sense, I think Kent is right about free software hobbiests: a
general strike might budge those companies. But I don't see that on
the horizon.
As a strong advocate of free software, I find some of the old rhetoric
from RMS' writings about whether and how will people get paid
embarassing in retrospect. I don't think they're essential to public
licensing and preserving the option for cooperation among programmers
at all.
(Thanks Kent, for sparking a thoughtful and intersting thread.)
-t
····@emf.emf.net (Tom Lord) writes:
> I think it's premature to blame free software for killing
> professional software development.
>
> That is because I believe that there are potential business models
> (not "support" -- but models in which people are paid for original
> programming) that are compatible with free software and, in fact,
> for which free software licenses are a better business tool than
> proprietary licenses. Would it be in scope here to talk about
> those models? Perhaps someone here can help to implement them.
But did you see my post i which I remarked that this means "capitalism"
is in play, but if you think of capitalism as a feedback loop that hones
the "product" that it is focused on (loosely, "the market"), cranking out
better product, then capitalism is distracted from making better "lisp"
and is focused on making better product. This is maybe locally better for
industry but is worse for "lisp". I'll go a step further here, to avoid
simply having repeated myself, and say that I think the reason for caring
about Lisp per se (which you might argue the world should not care about,
per se) is to avoid a "hill climbing problem". Capitalism, and, more
generally, conventional Darwinism, is narrowly focused on "the moment".
If you believe that the technology of the moment is not the best technology
for the long term, then you have to use the available tools to figure out
how to make a non-favored tool survive to compete another day. And the
best tool I can think for doing that is "not volunteering yourself up for
slaughter by economically disempowering yourself" and "not taking down
other projects you care about by driving down their commercial cost and
bankrupting the people doing them". I know, it's a clumsy tool. But
I don't have a better one to suggest.
Sociology is a curious thing. In some ways the argument is that it's like
trying to talk a hurricane into taking another direction. But the thing
about a hurricane that is different than a society is that it's not very
swayed by rhetoric. A lot of the existing problem (as I see it), was caused
by people spouting rhetoric. So I have to believe that spouting some
counter-rhetoric will have at least _some_ effect.
> As an example: It isn't hobbiests who are killing the unix industry.
> Yes, volunteers provided a lot of raw materials but, ca. 1994, those
> raw materials could not compete against, for example, Solaris in the
> commercial market. That critical last delta came from short-term
> tactical R&D by the companies, and sadly, it was implemented without
> any apparent care in the world about where the next generation of "raw
> materials" would come from.
This is hard for me to follow because I haven't got enough background
in the actual events and people you're referring to in order to parse
through it. Can you perhaps expand a bit?
> No...I take that back. They had some thoughts. Company policies
> along the lines of: "If, instead of taking a coffee break, you want to
> spend some time on a free software project of your choosing -- that's
> cool: we won't try to stop you. (And implicitly: it will help you at
> review time.)" Gee. Thanks.
(This problem is far more general than free software. Didn't I see a
news story about Walmart or some such place getting tagged for having
some company policy of having managers watch for employees leaving and
punching out and then as soon as they do asking them to do 'just one
more thing', getting an extra tiny percentage of work out of unpaid
employees? Sigh.)
> In this sense, I think Kent is right about free software hobbiests: a
> general strike might budge those companies. But I don't see that on
> the horizon.
I agree. Although investigating some alternate business models might wake
things up.
Having software, even open source software, that is for non-commercial
use only and that requires a license for any use in a business is a
possible way to go. I don't have any personal experience with this,
but I bet this is abused once in a while, but in general I bet most
companies won't risk their investment on components where they
licenses underlying are not solid.
The idea of trying to come up with and popularize better paradigms that
are more favorable to individuals making the software is certainly something
I think is worth doing.
This isn't just because I want people to make lots of money. It's
because smart people can and do find other ways to make money. That
means they industry will get left with the people who are not smart
enough to retarget. Ultimately, that hurts the industry. (Viz,
recent advice by someone in this thread that the market is glutted and
that another market might be a better home for one's career. That
good advice could ultimately mean some would-be great programmers
don't become programmers. The idea behind capitalism is to attract
the people who are producers, by offering them incentives, not to
simply weedle things down by getting rid of people at random and being
stuck with everyone who is so rigid they can't figure out how to
change specialties. (You see this sometimes in companies that are
about to have layoffs where they make life miserable for everyone,
hoping some people will leave and they won't need to have layoffs, not
realizing that the people who leave are the most valuable, and hence
most easily re-hired, leaving mostly the people who no one else wanted
to carry on. Mmmm. Nice strategy.)
Kent M Pitman wrote:
> Having software, even open source software, that is for non-commercial
> use only and that requires a license for any use in a business is a
> possible way to go. I don't have any personal experience with this,
> but I bet this is abused once in a while, but in general I bet most
> companies won't risk their investment on components where they
> licenses underlying are not solid.
I arrived at the same conclusion.
I recently announced some software here on exactly which I have made
available on exactly that sort of licence. I expected some criticism
for doing this, and received some elsewhere, but not here. I couldn't
call it "open source" despite my supplying the source, and only the
source, or "free", despite my not charging for it, in case someone
thought it was GPLed and used it for/at their work.
Anyone else who is thinking of releasing their own software for non-
commercial use might consider using my licence. If you don't like
it, the Microsoft CLI Shared Source License seems to be the best
alternative.
Many, and especially larger, companies, do take a dim view of software
piracy and so are unlikely to want to pirate shared-source software.
> The idea of trying to come up with and popularize better paradigms that
> are more favorable to individuals making the software is certainly something
> I think is worth doing.
I don't think that the proliferation of "free" software is the
main reason so many programmers are out of work, but it doesn't
help matters. For systems programmers, the catastrophic decline
in diversity (now only two operating systems still actively
developed) has been a more important long-term factor.
R&D nas declined because of rampant short-termism. The creative
people have not died off or suddenly lost their creativity. They're
just doing non-creative work, or are out of work altogether. If
they start doing innovative work again in their spare time, and release
it on a non-commercial licence, and this gets known, some people in
industry might start to take notice, and hire them, pay for a
commercail licence, fund them or compete with them. If it's released
on the GPL, companies will simply take it and use it, without rewarding
the innovator.
> This isn't just because I want people to make lots of money. It's
> because smart people can and do find other ways to make money. That
> means they industry will get left with the people who are not smart
> enough to retarget. Ultimately, that hurts the industry. (Viz,
> recent advice by someone in this thread that the market is glutted and
> that another market might be a better home for one's career. That
> good advice could ultimately mean some would-be great programmers
> don't become programmers. The idea behind capitalism is to attract
> the people who are producers, by offering them incentives, not to
> simply weedle things down by getting rid of people at random and being
> stuck with everyone who is so rigid they can't figure out how to
> change specialties. (You see this sometimes in companies that are
> about to have layoffs where they make life miserable for everyone,
> hoping some people will leave and they won't need to have layoffs, not
> realizing that the people who leave are the most valuable, and hence
> most easily re-hired, leaving mostly the people who no one else wanted
> to carry on. Mmmm. Nice strategy.)
Industry's solution seems to be to /reduce/ dependence on smart
people, and try to compensate by standardizing their processes.
This is obviously bad. The answer for industry is to find a way
to recognize who the smart people are. The answer for individuals
is to make sure that they have colleagues who are smarter than they
are (or at least as smart), and who have some influence within the
organization. If you're the smartest person around and have no
influence, people who are less smart than you won't appreciate this,
and often won't even be aware of it.
Le Hibou
--
In any large organization, mediocrity is almost by definition
an overwhelming phenomenon; the systematic disqualification
of competence, however, is the managers' own invention, for
the sad consequences of which they should bear the full blame.
-- Edsger W. Dijkstra, 1986.
On 18 Mar 2003, Kent M Pitman wrote:
> But the problem I have with that is that again it transforms the market
> from "competition over the product" to "competition over the support of
> the product".
In software, the difference between development and support is illusory.
It's all programming -- whether you're being paid for it as a service, or
as a product. The question is, which is closest to reality?
On 18 Mar 2003 16:12:54 +0100, Nils Goesche <······@cartan.de> wrote:
>Sometimes society must also be protected from lunatics and irrational
>philosophies. Communists caused a lot of havoc and suffering in the
>20th century (and their intellectual heirs still do), notwithstanding
>that their economic system was rather inefficient, for instance. And
>that islamic fundamentalists are crazy doesn't mean they can't cause a
>lot of damage.
I agree completely; like Ayn Rand, I regard communists and Islamic
fundamentalists as on the same footing as any other gang of looters
and murderers, irrespective of whether they've managed to gain control
of the laws of their home country or not.
However, I wouldn't quite put the GCC team in the same category :)
>Nobody is arguing that the /police/ should stop people from making
>free software ;-) But it might help if more people start telling them
>that they are, irrationally, working against their very own
>self-interest (and thus, following Rand, ultimately against everybody
>else's interest, too).
I agree. [1]
However, I'll suggest that it would be more helpful if someone told
young people that unless you have a much cleverer plan than "get a job
as a programmer", going into the software industry _at all_ is against
your own self-interest (and probably ultimately against everybody
else's interest too).
>Why? If it attacked you, you might get a peace nobel price, too.
Dunno, did any of Arthur's knights get prizes?...
>Although maybe you'd have to ruin a major economy, first. Can't say I
>really understand the criteria for getting that price anymore ;-)
I never understood them in the first place :)
[1] Yes there's some free software on my web page, but it's mostly
research stuff; there's no market for it. If there was, I'd be trying
to sell it instead of give it away :)
--
"Sore wa himitsu desu."
To reply by email, remove
killer rodent from address.
http://www.esatclear.ie/~rwallace
·············@eircom.net (Russell Wallace) writes:
> On 18 Mar 2003 16:12:54 +0100, Nils Goesche <······@cartan.de> wrote:
>
> >Sometimes society must also be protected from lunatics and
> >irrational philosophies.
> However, I wouldn't quite put the GCC team in the same category :)
Just for the record: Neither would I. That was just an /example/ :-)
> However, I'll suggest that it would be more helpful if someone told
> young people that unless you have a much cleverer plan than "get a
> job as a programmer", going into the software industry _at all_ is
> against your own self-interest (and probably ultimately against
> everybody else's interest too).
Why? If somebody likes programming (and nobody is going to kill the
software industry as a whole ;-) becoming a professional programmer
might be just the right choice for him.
> >Why? If it attacked you, you might get a peace nobel price, too.
>
> Dunno, did any of Arthur's knights get prizes?...
Darn; looks like I'm getting old. I took it for granted that you are
referring to the killer rabbit that almost assassinated a US president
many years ago. I should have asked Amy for advice before posting.
> [1] Yes there's some free software on my web page, but it's mostly
> research stuff; there's no market for it. If there was, I'd be
> trying to sell it instead of give it away :)
Oops, I hope I can still reach the small commando I just sent off to
protect the evil interests of the military-industrial complex...
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
On 18 Mar 2003 18:15:41 +0100, Nils Goesche <······@cartan.de> wrote:
>Why? If somebody likes programming (and nobody is going to kill the
>software industry as a whole ;-) becoming a professional programmer
>might be just the right choice for him.
If he's truly dedicated to programming and nothing else will fulfil
his life's ambition, then no advice is going to dissuade him.
However if he's looking for a profession where he can find a job with
reasonable working conditions, programming is a bad choice and likely
to remain so for a long time. (The current glut of programmers in the
West will likely diminish slowly, given that a lot of them are still
relatively young - probably more slowly than more competition from
Asia and Eastern Europe comes in.)
>Darn; looks like I'm getting old. I took it for granted that you are
>referring to the killer rabbit that almost assassinated a US president
>many years ago. I should have asked Amy for advice before posting.
*blink blink* How did that happen?
>Oops, I hope I can still reach the small commando I just sent off to
>protect the evil interests of the military-industrial complex...
^.^
--
"Sore wa himitsu desu."
To reply by email, remove
killer rodent from address.
http://www.esatclear.ie/~rwallace
·············@eircom.net (Russell Wallace) writes:
> On 18 Mar 2003 18:15:41 +0100, Nils Goesche <······@cartan.de> wrote:
>
> >Darn; looks like I'm getting old. I took it for granted that you
> >are referring to the killer rabbit that almost assassinated a US
> >president many years ago. I should have asked Amy for advice
> >before posting.
>
> *blink blink* How did that happen?
See
http://www.straightdope.com/classics/a4_019.html
Also, in 1980, he said in a public debate with Ronald Reagan:
"I think to close out this discussion, it would be better to put into
perspective what we're talking about. I had a discussion with my
daughter, Amy, the other day, before I came here, to ask her what the
most important issue was. She said she thought nuclear weaponry --
and the control of nuclear arms."
Amy was about 13 years old at the time. Many people thought that it
would really explain something if it was in fact a little girl who
told the president how to deal with the Iran hostages, for instance.
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
On 18 Mar 2003 19:23:13 +0100, Nils Goesche <······@cartan.de> wrote:
> http://www.straightdope.com/classics/a4_019.html
Ah! *rotfl*
>Also, in 1980, he said in a public debate with Ronald Reagan:
>
> "I think to close out this discussion, it would be better to put into
> perspective what we're talking about. I had a discussion with my
> daughter, Amy, the other day, before I came here, to ask her what the
> most important issue was. She said she thought nuclear weaponry --
> and the control of nuclear arms."
>
>Amy was about 13 years old at the time. Many people thought that it
>would really explain something if it was in fact a little girl who
>told the president how to deal with the Iran hostages, for instance.
They should have tried just putting her in charge instead of him. The
results would have been unlikely to be worse, and just might have been
better.
--
"Sore wa himitsu desu."
To reply by email, remove
killer rodent from address.
http://www.esatclear.ie/~rwallace
Nils Goesche wrote:
>> However, I wouldn't quite put the GCC team in the same category :)
>
> Just for the record: Neither would I. That was just an example :-)
I don't understand. Why not? They're doing the same thing as anyone else
in the not-for-profit software community. Why are they somehow immune from
the same criticism?
faa
"Frank A. Adrian" <·······@ancar.org> writes:
> Nils Goesche wrote:
>
> >> However, I wouldn't quite put the GCC team in the same category :)
> >
> > Just for the record: Neither would I. That was just an example :-)
>
> I don't understand. Why not? They're doing the same thing as
> anyone else in the not-for-profit software community. Why are
> they somehow immune from the same criticism?
They aren't. They are not in /this/ category, however:
http://www.amazon.com/exec/obidos/ASIN/0674076087/qid=1048052320/sr=2-1/ref=sr_2_1/103-7463820-8493429
Regards,
--
Nils G�sche
Ask not for whom the <CONTROL-G> tolls.
PGP key ID #xD26EF2A0
On 18 Mar 2003, Nils Goesche wrote:
> Hobbyists? Don't know about you but the truly hobbyist programmers I
> met simply cannot write any significant program, free or not. The
> people who wrote Apache certainly weren't hobbyists, and I wouldn't
> call Linus Torvalds a hobbyist, either. Somebody is paying for all
> that programmer time, be it the tax-payer or their parents. Somebody
> is putting money into their education, and even when they are
> self-taught, somebody is paying for their food and rent while they do.
> If they are professional programmers working in their spare time, it's
> themselves who is subsidizing free software.
If people are willing and able to subsidize "free" software now, what
makes you think it would be any different if there weren't any traditional
software?
I think this whole issue can be cleared up if we accept some things about
software:
1. it is technology; it "makes money" simply by existing, because it makes
people more efficient
2. it is ongoing; as with any technology, there is always room for
improvement
3. individual copies of software are economically worthless, since they
cost nothing to produce, though the software itself may be quite
valuable
Point 1 tells us that it will always be worth it to someone that software
gets written. Point 2 tells us that there will always be new software to
write. Point 3 explains why free software makes more sense economically --
people should be paid for the act of producing the software, not for the
act of copying it. And, all three together say that once the software is
made and paid for, it benefits the entire economy to take advantage of this
cheap copying.
One can still argue that paying for /consumer/ software is an unsolved
problem -- it's hard to tell the point at which the benefit to the economy
(and therefore you) by releasing the software outweighs the profits you
could make by controlling it. Judging by the number of companies taking
interest in open-source models, this point is probably way sooner than
people used to think.
Heck, in the worst case, what's to stop consumers from getting together,
pooling their resources, and forming a syndicate to get the software they
want written?
> So, apparently all those professional programmers (and soon-to-be
> professional programmers like CS students) are working against their
> very own self-interest. When this happens, it is most likely because
> somebody is indoctrinating them with irrational philosophies
Perhaps they believe that the benefits they personally would gain from a
society full of free software outweigh the possible, debatable impact on
their /current/ source of income.
-- Adrian Kubala
Adrian Kubala <·······@sixfingeredman.net> writes:
> On 18 Mar 2003, Nils Goesche wrote:
>
> > Hobbyists? Don't know about you but the truly hobbyist programmers I
> > met simply cannot write any significant program, free or not. The
> > people who wrote Apache certainly weren't hobbyists, and I wouldn't
> > call Linus Torvalds a hobbyist, either. Somebody is paying for all
> > that programmer time, be it the tax-payer or their parents. Somebody
> > is putting money into their education, and even when they are
> > self-taught, somebody is paying for their food and rent while they do.
> > If they are professional programmers working in their spare time, it's
> > themselves who is subsidizing free software.
>
> If people are willing and able to subsidize "free" software now, what
> makes you think it would be any different if there weren't any traditional
> software?
But what if the people who are suppling the money do not want to
subsidize it? For example a college student who spends 20-30 hrs/week
working on some free software. The reason he can do this is that his
parents are funding it unknowingly. Now if he found a job coding and
put those same hours in he could reduce the amount of money he is
taking from his parents.
>
> I think this whole issue can be cleared up if we accept some things about
> software:
> 1. it is technology; it "makes money" simply by existing, because it makes
> people more efficient
This has been proven to not always be the case. One counter example
is the study ATT did on technical writing, one group got troff and the
other group got a new word processor package. The group group using
the word processor was less productive. What they produced was of
lower quality, in content, and not consistent in layout. The reason
given for this result was that everybody was "playing" with the look
of the document in the wp group, fonts, line spacing, indenting ...,
when they should have been writing documentation. So ATT stuck with
Troff because it removed all these temptations from the work place.
> 2. it is ongoing; as with any technology, there is always room for
> improvement
There may always be room, but is there a economic need?
> 3. individual copies of software are economically worthless, since they
> cost nothing to produce, though the software itself may be quite
> valuable
Well that is saying that like saying that all the R&D cost on a car is
something that the producer should eat. This is a recipe for no new
cars.
marc
Marc Spitzer <········@optonline.net> writes:
> Adrian Kubala <·······@sixfingeredman.net> writes:
>
> > I think this whole issue can be cleared up if we accept some things about
> > software:
>
> > 1. it is technology; it "makes money" simply by existing,
> > because it makes people more efficient
Just so you know, money is not made by things simply existing.
Money is something that is owned. It is a reward for services rendered.
When you don't charge it, there is no one to reward. The item becomes
taken for granted.
There is no fixed baseline that is "no efficiency" and no threshold
that is "enough efficiency". What matters are deltas in efficiency.
When you contribute something that raises someone's efficiency OVER
SOMEONE ELSE'S you have an edge for which someone might meaningfully
pay money for. When you contribute something that affects everyone
equally, there is nothing to pay for because you are not changing the
relative distance from the moving baseline.
The only sense in which you've made something that can create money
for is the sense in which you have failed to do the whole job of making
the service available to everyone, either because it is buggy or because
it does not run on every machine or because not everyone can afford a
machine, and so you have enriched only certain people and those people
now have an edge over those you have failed to enrich. But that money
even then may not flow back to you--it will flow back to the person who
figures out how to package the new technology in a fashion that will be
saleable to those who haven't figured out how to get the thing for free.
These people may be contributing far less than you do, but the customer
may be paying for the value you have provided 'free' because the real
value is in the accessibility which has been, for reasons beyond your
intent, denied to them.
But if your contribution really went to everyone, that would be like
going to no one. It no longer offers economic advantage.
It may enrich the world, as do many things like love and friendship that
we do not pay for in the world, but it does not put food on the table,
just as love and friendship do not.
> > 2. it is ongoing; as with any technology, there is always room for
> > improvement
>
> There may always be room, but is there a economic need?
Not when the GPL forbids charging for the value in the improvement.
One makes serious money in the world by having economic leverage. By
doing something once that you can reuse. For example, I might spend
months working to afford a machine that I can use to make my cost lower.
With the machine, I might make lower priced stuff, but a GPL theory would
say that I shouldn't be able to charge for the machine, or certainly should
not be able to charge MORE than I paid for the machine. Such theories
do not reward me for the risk that the machine might not make things that
sell, or might break, or might need ongoing maintenance, nor even for the
fact that I had to eat peanut butter sandwiches instead of steak for months
in order to afford the machine. I see no difference between this and
the issue of working 3 days on something that I can only bill for an hour's
time on, in hopes that I will sell than 24 copies (3 days * 8 hours)
in order to break even on the time spent, or more than 24 copies (in order
to make a profit to compensate me for risk).
Risk is a real thing, and something that people who are in college reason
poorly about. A good rule of thumb someone taught me long ago, which I
have sometimes applied to good success, and more often failed to apply
and been sorry for: Never take on extra risk without being paid extra money.
In the end, you will see that it costs real money, and when you don't
ask for extra money, the world will make sure you see that. Risk is just
the probabilistic assertion of certain expense, and when you don't charge
for it, you are banking that the oddsmakers are wrong and that the probability
of certain expense was zero. The oddsmakers are usually not wrong like
that.
The GPL effectively requires that the reuse not be paid for, and so
basically assures a peasant class existence where any enduring value
you add to the world by improving it is not paid for--all that can be
paid for is your time, at a rate that is only appropriate to a single
consumer, and not at all proportional to the number of people
benefited.
This is a possible political theory, but not one that makes any attempt
to fairly compensate the doer in any kind of free capitalistic sense.
In spite of the heavy insistence on the use of 'free' all over the place,
and on controlling the definition in the cynical hope that no one will
challenge whether in fact this is NOT a good definition of free,
it ties the hands of the content producers.
It is, IMO, an entirely communist ('from each whatever we can squeeze
out of him, and to each whatever we think he needs to survive until
the next time we need to squeeze him for help') kind of thing.
Assuring that no economic power comes from the action assures that the
person doing it won't ever get too uppity. Pay a person poorly enough
and eventually he'll be grateful for what little you pay him.
> > 3. individual copies of software are economically worthless, since they
> > cost nothing to produce, though the software itself may be quite
> > valuable
>
> Well that is saying that like saying that all the R&D cost on a car is
> something that the producer should eat. This is a recipe for no new
> cars.
well said.
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> > Adrian Kubala <·······@sixfingeredman.net> writes:
> >
> > > I think this whole issue can be cleared up if we accept some things about
> > > software:
> >
> > > 1. it is technology; it "makes money" simply by existing,
> > > because it makes people more efficient
>
> Just so you know, money is not made by things simply existing.
That's true, but "makes money" was in scare quotes, so it's possible that
what Adrian really meant was the technology "creates wealth" simply by
existing. This is in fact true.
> Money is something that is owned.
That is true.
> It is a reward for services rendered.
That is not necessarily true, and in fact, most people who have lots of
money did not make it by rendering services.
> It may enrich the world, as do many things like love and friendship that
> we do not pay for in the world, but it does not put food on the table,
> just as love and friendship do not.
That's not true. Love and friendship *do* put food on the table in many
instances.
> > > 2. it is ongoing; as with any technology, there is always room for
> > > improvement
> >
> > There may always be room, but is there a economic need?
>
> Not when the GPL forbids charging for the value in the improvement.
GPL does not forbid this.
> One makes serious money in the world by having economic leverage. By
> doing something once that you can reuse. For example, I might spend
> months working to afford a machine that I can use to make my cost lower.
> With the machine, I might make lower priced stuff, but a GPL theory would
> say that I shouldn't be able to charge for the machine, or certainly should
> not be able to charge MORE than I paid for the machine.
Why would you want to charge for the machine? In your hypothetical
scenario you're not selling machines, you're selling "stuff" that the
machine allows you to make at lower cost.
The problem is (as I have said before) that you don't want to make stuff
(products), you want to make machines (programs), and the bottom has
dropped out of the machine market because these particular machines
(programs) are self-reproducing.
Your situation is not unlike that of a farmer who can't make a living
farming any more because of the low price of commodities, and who is
responding to the situation by trying to organize all the farmers into a
cartel to limit production in order to drive prices back up. Your
argument that the GPL works against the interests of individual
programmers is valid, but rotsa ruck trying to convince enough people of
this that you actually achieve the ends you desire.
A much more effective strategy, I submit, if your goal is to make money is
to change your business strategy. Instead of insisting on being a
producer of an underpriced commodity and tilting at windmills to get the
price up, why not instead become a consumer of these underpriced
commodities? If, as you have said in the past, there are so many things
that computers could do for us (and that presumably people would be
willing to pay for), why not build one of those things on top of a GPL
infrastructure (like GNU/Linux say), but make it a separate work? Oracle,
Inktomi, and Google all make money doing exactly that.
> The GPL effectively requires that the reuse not be paid for
Yes. So? How does this prevent you from writing a separate work and
charging for it?
> It is, IMO, an entirely communist ('from each whatever we can squeeze
> out of him, and to each whatever we think he needs to survive until
> the next time we need to squeeze him for help') kind of thing.
With the significant difference that people adopt the GPL of their own
free will and not at gunpoint. If someone chooses to live as a peasant in
exchange for being able to spend their lives pursuing their intellectual
interests on their own terms, what's wrong with that?
E.
--
The opinions expressed here are my own and do not necessarily
reflect the views of JPL or NASA.
Economic entities exist not independently but in a community.
Infrastructure must exist to support the communities. GPL software is
successful because it provides an infrastructure of economic
community-enabling software services filling roles similar to those such
as the roadways and waterworks which governments provide for
physically-proximant communities.
I read "Atlas Shrugged" about ten years ago. I remember that a railroad
company played a (the) prominent role. Throughout the world, do the
companies own the rails themselves? If so, at least they are protected
by regional or national governments, or else every little hamlet could
claim the property in the same way they do when building roads. Does
the railroad company own the stations or are they provided by
governments? If even the stations are owned by the company, does the
company accept money, which is administered by a government, from
passengers or do the passengers bring chickens to pay for their tickets?
Any given economic entity either is part of a larger system or is the
larger system itself.
Whenever an entity is part of a larger system, there exist means,
methods, and accepted practices within the larger system allowing the
system's components/members to cooperate. This "grease" certainly
includes the monetary system but also much more. Think of all the
governmental services that exist, or think only of those that should
exist (the size of government isn't my point).
Consider roads. Every economic entity in a country uses them, or uses
vendors who use them, or supplies customers who use them, or has
employees who use them. Should roads be owned by private corporations?
It is possible. They often are built by private corporations under
government contract and could be run the same way. Every road could be
a toll road. It is possible to make the argument but it hasn't much
application to the world today. Governments build roads, governments
own them, and the populace uses them toll-free in most of my experience.
It is a system that has benefits, that has worked and is working, that
provides a nearly unmeasurable benefit to people, and is one underlying
girder of our entire economic system.
Operating systems and networks have become the roads across which
populations must travel to engage in economic, recreational, and private
activities within the software world. There are disadvantages when
every road is a toll road and advantages when toll-free roads exist. The
same advantages apply when toll-free roads are available in the software
world. This does not mean an end to the ability of companies to engage
successfully in software-related economic activity any more than
Coca-Cola being delivered via trucks driving on toll-free roads puts
Coca-Cola out of business. It does mean that business plans relying
upon the collection of tolls must be adjusted.
GPL software's rise came because many talented people believed it was
needed and, as roads are paid for with taxes, they taxed themselves to
produce the software. It is absolutely an economic activity with costs
and rewards. Think of the money they would have had to pay for the GPL
software if it had been sold under a traditional model. The GPLers's
transactions are barter that, so far at least, has avoided taxation.
While GPLers do not get money from software sales, they avoid paying
money and, due to the numbers of people involved, they obtain software
of greater value than their individual effort cost them. They actually
have more cash left over than if they had paid for the equivalent
programs sold the traditional way. (They could not have afforded that
software sold the traditional way and would have a zero or negative cash
balance.) Given that software has value, and it clearly does to most
every GPL developer as well as to many others besides, this represents a
gain to each person and meets the criteria of economic activites. That
the result of GPLers's self-taxation has impacted others is nothing more
than old-fashioned competition.
Kent Pitman suggested that people should start thinking more about
building things with Lisp and less about building Lisp itself. It may
be worth thinking more about building things with, or on top of, GPL
software and less about building software which exists in the GPL world.
Jeff
Erann Gat wrote:
...
>> For example, I might spend
>>months working to afford a machine that I can use to make my cost lower.
>>With the machine, I might make lower priced stuff, but a GPL theory would
>>say that I shouldn't be able to charge for the machine, or certainly should
>>not be able to charge MORE than I paid for the machine.
>
> ... people adopt the GPL of their own
> free will and not at gunpoint. If someone chooses to live as a peasant in
> exchange for being able to spend their lives pursuing their intellectual
> interests on their own terms, what's wrong with that?
>
> E.
>
From: Bulent Murtezaoglu
Subject: Re: Learning new things
Date:
Message-ID: <87wuiiav8x.fsf@acm.org>
>>>>> "JC" == Jeff Caldwell <·····@yahoo.com> writes:
[I deleted the the parts I understood]
JC> GPL software's rise came because many talented people believed
JC> it was needed and, as roads are paid for with taxes, they
JC> taxed themselves to produce the software. It is absolutely an
JC> economic activity with costs and rewards. Think of the money
JC> they would have had to pay for the GPL software if it had been
JC> sold under a traditional model. The GPLers's transactions are
JC> barter that, so far at least, has avoided taxation.
This seems to assume that there's some isolated GPL society somewhere.
That is not so and I think it is important for KMP's argument that some
of the _same_ people who produce GPL'ed software also produce other
kinds of software and _most_ consumers of GPL'ed software are not in
this GPL society (since they are not programmers). The consumers get
GPL'e software not through barter but for free, some of the producers
hurt themselves by moonlighting to make their paid jobs not pay as much.
That is my understanding of KMP's argument as it applies to your
paragraph.
JC> While GPLers do not get money from software sales, they avoid
JC> paying money and, due to the numbers of people involved, they
JC> obtain software of greater value than their individual effort
JC> cost them.
This is true in a way you didn't intend it to, I think. If their
individual effort is not worth much, then you are right. KMP claims
that they themselves are making sure that their individual effort is
losing its value thru GPL. Now I would love to see a convincing
argument for the opposite side, but the above doesn't seem to me to
be it.
JC> They actually have more cash left over than if
JC> they had paid for the equivalent programs sold the traditional
JC> way.
Where did this cash actually come from? From some other activity?
Taxation? Grants?
JC> (They could not have afforded that software sold the
JC> traditional way and would have a zero or negative cash
JC> balance.) [...]
A good experienced programmer in a decent economy can (or used to be
able to) fetch 6-figs. You seem to be starting from the assumption
that programmers are very poor. KMP is saying they don't need to be
and they probably would make a whole lot more through programming had
it not been the competition from GPL'ed SW. I can see, however, how
your argument can be appealing when the audience consisting of
students (I was one, and I did not start using linux because of GPL
but because a PC+Linux was much cheaper than an equivalent Sun+SunOS).
I still find Kent's arguments more persuasive than the pro-GPL arguments.
I think it is important to understand what he's saying, though: he is not
saying that GPL is bad for software, he's saying ethusiasm about producing
programs under GPL is undermining the potential programmers have for
making sizeable sums of money through programming. Whether or not
programmers _should_ make sizeable sums of money through programming
is another question. I am more concerned with the descriptive parts of
his writings and I suspect he might be right.
cheers,
BM
Bulent Murtezaoglu <··@acm.org> writes:
> A good experienced programmer in a decent economy can (or used to be
> able to) fetch 6-figs. You seem to be starting from the assumption
> that programmers are very poor. KMP is saying they don't need to be
> and they probably would make a whole lot more through programming had
> it not been the competition from GPL'ed SW. I can see, however, how
> your argument can be appealing when the audience consisting of
> students (I was one, and I did not start using linux because of GPL
> but because a PC+Linux was much cheaper than an equivalent Sun+SunOS).
>
> I still find Kent's arguments more persuasive than the pro-GPL arguments.
> I think it is important to understand what he's saying, though: he is not
> saying that GPL is bad for software, he's saying ethusiasm about producing
> programs under GPL is undermining the potential programmers have for
> making sizeable sums of money through programming. Whether or not
> programmers _should_ make sizeable sums of money through programming
> is another question. I am more concerned with the descriptive parts of
> his writings and I suspect he might be right.
>
In all the discussion about the influence of GPL on the ability of the
single programmer to make money of his skills, one has carefully to
look at what kind of software the programmer does work.
Indeed if you think of shrink-wrapped software like a text processor
or a graphics program, free software might hurt sales. I say might here,
because especially the example of Star Office shows that commercial
and free software can co-exist very well. Why is it possible that
SUN can sell actually almost the identical product that is available
for download as Open Office ? Because lot of consuments (meaning
especially companies with interest into the product) are willing to
pay a reasonable sum to get "polished" version of the product.
Polished in this case means, that SUN bundles some extras (fonts etc.)
with the package as well as putting some extra effort in making
that version running smoothly. So not even shrink-wrapped software
based upon an open source product is killed by OSS so I assume there
is plenty of market for other "closed" products.
But, what in my opinion is much more important, is the market of
programmers, to which I may count myself, who do not write shring-wrapped
software. I do not have any concrete numbers, I can only make a statistic
of the programmers I met up to now. And the majority is paid by their
companies because the company wants to have the software they produce,
for its own uses, not to sell the software. Software just for internal
uses in the workings of the companies. This kind of software is most
of the times tailor-made for the task at hand, so no off-the shelf
solutions excist, be they commercial or open source. So in effect
it comes down that GPL-software can mean some savings in investment,
but most of the times it becomes interesting because the programmer
has access to the source of the software to use, which means, he
doesn't have to circumnavigate the bugs in the software he uses.
I have been part in some untertakings where quite some amount
of the whole time spent on the project indeed was spent on trying
to cope with bugs in the software used. With access to the source,
at least that time could have shortened drastically.
So in my eyes, GPL software means you do not have to reinvent the
wheel again and again - but to stay in the picture, this doesnt
affect the ability to market the car your are building. In fact,
it can mean even that the company can spend the money saved in
not reinventing the wheel the actual development process they
are out to do.
Peter
--
Peter Herth
Dawn of the Ages
http://dawn.netcologne.de
Bulent Murtezaoglu <··@acm.org> writes:
> >>>>> "JC" == Jeff Caldwell <·····@yahoo.com> writes:
> [I deleted the the parts I understood]
> JC> GPL software's rise came because many talented people
> JC> believed it was needed and, as roads are paid for with
> JC> taxes, they taxed themselves to produce the software. It is
> JC> absolutely an economic activity with costs and rewards.
> JC> Think of the money they would have had to pay for the GPL
> JC> software if it had been sold under a traditional model. The
> JC> GPLers's transactions are barter that, so far at least, has
> JC> avoided taxation.
>
> This seems to assume that there's some isolated GPL society
> somewhere. That is not so and I think it is important for KMP's
> argument that some of the _same_ people who produce GPL'ed software
> also produce other kinds of software and _most_ consumers of GPL'ed
> software are not in this GPL society (since they are not
> programmers). The consumers get GPL'e software not through barter
> but for free, some of the producers hurt themselves by moonlighting
> to make their paid jobs not pay as much. That is my understanding of
> KMP's argument as it applies to your paragraph.
>
> JC> While GPLers do not get money from software sales, they
> JC> avoid paying money and, due to the numbers of people
> JC> involved, they obtain software of greater value than their
> JC> individual effort cost them.
>
> This is true in a way you didn't intend it to, I think. If their
> individual effort is not worth much, then you are right. KMP claims
> that they themselves are making sure that their individual effort is
> losing its value thru GPL. Now I would love to see a convincing
> argument for the opposite side, but the above doesn't seem to me to
> be it.
I don't know if this is going to be convincing but here's another
version of what I take to be Jeff's argument:
Those of us who write software for a living can make money to the
extent that there is market demand for software that exceeds the
current supply. Kent's argument--as I understand it--is that folks who
write free (gratis) software decrease the market value of other
software by increasing the supply. But what happens to the *demand*
for software as a consequence of people writing free software?
Software isn't razor blades--writing a useful Foo library, while it
will probably decrease the demand for Foo libraries, may *increase*
the demand for software generally--there may be whole new markets
created that want software *using* this now readily available Foo
library. In that case, all software developers can benefit from the
expanded demand.
A case in point: As stupid as it was, the recent tech bubble was gravy
times for us software developers. And much of the software that
sparked the rise of the web was free. Do you think the web would have
taken off if Tim Berners-Lee had quit his job at CERN and started a
company trying to figure out how to commercialize HTML/HTTP. Or if the
availability of free software such as NCSA HTTP server and then Apache
hadn't made it economically feasable for tens of thousands of folks to
experiment with putting up a web site.
For us Lisp folks, keeping in mind that software may not be a zero sum
game is--I think--particularly important. If AllegroServe being freely
available increases the number of places where folks might use Lisp
rather than Java or Python, that's only to my benefit as Lisp
developer.
I'm not saying this is always the case--any given piece of software
can increase, decrease, or not affect at all the demand for other
software. But to say that people writing free software necesarily
harms the economic interests of other software developers seems to
simplistic.
-Peter
--
Peter Seibel ·····@javamonkey.com
The intellectual level needed for system design is in general
grossly underestimated. I am convinced more than ever that this
type of work is very difficult and that every effort to do it with
other than the best people is doomed to either failure or moderate
success at enormous expense. --Edsger Dijkstra
Peter Seibel <·····@javamonkey.com> writes:
[I have some quibbles with various things you said, but I'm going to
just respond to a couple because of time and energy issues.]
> Do you think the web would have
> taken off if Tim Berners-Lee had quit his job at CERN and started a
> company trying to figure out how to commercialize HTML/HTTP.
Yes. It would have gone just like Lotus 1-2-3, including probably
the obligatory look and feel suits over browser issues. But it was
a cool device that I and others surely would have paid money for.
I'm not sure what this proves one way or another in this discussion
of free software, but I didn't want to let stand a claim that appeared
to suggest that the web would only have come to a rise due to free
software. I'm quite sure that it was an idea whose time had come and
that would not be stopped. It might have come more slowly, but the
likely effect of that is that web shopping would have been worked out
in an orderly fashion, including possibly micropayments, and perhaps
people all over the world who supplied content would have gotten paid
for that content.
I hadn't thought about this but the web is actually a perfect example
of what I'm talking about. So many people offered content for free
that it drove down the value that could be charged for that content
EVEN THOUGH (a) there was real value being offered that people would
have paid for and (b) it actively COST money for people to put stuff
onto the web.
I and others speculated in content production, trying to get money back
on advertising, and failed. Micropayments probably would have succeeded,
if they had been a debugged, accepted way of doing business. But people
were not used to doing that, and so they rejected (often angrily) the idea
of paying even pennies for content that took me way more than pennies to
produce. The web quite suddenly made so much content available that the
content was commercially valueless. Nothing bad would have happened to
the world if it had been more orderly about this, and a lot of people with
some very nice content might have been rewarded better instead of being
kicked in the teeth and told their content was commercially worthless.
> ... to say that people writing free software necesarily
> harms the economic interests of other software developers seems to
> simplistic.
I, at least, have not said this. What I have said is that it is not
the case that writing free software is sure not to harm the economic
interests of other software developers.
That is, I have said that one must think carefully in each case what
the effect would be.
Kent M Pitman <······@world.std.com> writes:
> > ... to say that people writing free software necesarily harms the
> > economic interests of other software developers seems to
> > simplistic.
>
> I, at least, have not said this. What I have said is that it is not
> the case that writing free software is sure not to harm the economic
> interests of other software developers.
>
> That is, I have said that one must think carefully in each case what
> the effect would be.
Then we agree, it seems.
-Peter
--
Peter Seibel ·····@javamonkey.com
The intellectual level needed for system design is in general
grossly underestimated. I am convinced more than ever that this
type of work is very difficult and that every effort to do it with
other than the best people is doomed to either failure or moderate
success at enormous expense. --Edsger Dijkstra
Kent M Pitman <······@world.std.com> writes:
> Peter Seibel <·····@javamonkey.com> writes:
>
> > Do you think the web would have
> > taken off if Tim Berners-Lee had quit his job at CERN and started a
> > company trying to figure out how to commercialize HTML/HTTP.
>
> Yes. It would have gone just like Lotus 1-2-3, including probably
> the obligatory look and feel suits over browser issues.
I am not so convinced. The web is more like infrastructure than like
individual useful programs.
As an example, 20 or more years ago, France managed to create a
nationwide infrastructure around its Minitel system, whereas all other
countries failed to do something similar. I believe the reason is
that in order for infrastructure to come into existence, you either
need subsides on a big scale, say national, or else it has to grow
incrementally (and therefore very slowly).
The road system exists because roads were used by horses before cars
and roads developed from footpaths that were needed by humans before
they used horses. Railways exist in most countries because a huge
nationwide program was created in order to make them happen.
As far as the Minitel is concerned, most countries failed because
consumers were unwilling to buy the equipment until there were a
fairly large number of services, and the services were unwilling to
invest as long as there were few users. The French phone company
solved the problem by giving away a rudimentary terminal and
providing one service, the phone book. That was enough to get the
ball rolling.
The web might very well have gone the same way as the failed Minitel
systems: nobody would pay for the web browser if there was little or
nothing to search for, and nobody would make web sites if few people
had a browser.
--
Robert Strandh
+ Robert STRANDH <·······@labri.u-bordeaux.fr>:
| The web might very well have gone the same way as the failed Minitel
| systems: nobody would pay for the web browser if there was little or
| nothing to search for, and nobody would make web sites if few people
| had a browser.
A perhaps even more relevant example is project Xanadu - the ultimate
vaporware project. A couple links:
http://www.xanadu.com.au/
http://www.xanadu.com.au/archive/6w-paper.html
The second one - Where World Wide Web Went Wrong - seems particularly
interesting. The world might well have been a better place if Xanadu
had gotten off the ground before the web exploded, but it didn't.
There must be a lesson in there somewhere. ...
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Yes it works in practice - but does it work in theory?
* Robert STRANDH wrote:
> As far as the Minitel is concerned, most countries failed because
> consumers were unwilling to buy the equipment until there were a
> fairly large number of services, and the services were unwilling to
> invest as long as there were few users. The French phone company
> solved the problem by giving away a rudimentary terminal and
> providing one service, the phone book. That was enough to get the
> ball rolling.
This argument could hold for, say, SMS. It's no use until lots of
people have compatible mobile phones, and until the various networks
will talk to each other. So clearly SMS can't succeed in a commercial
environment, right? Well, over 1.5 billion SMSs were sent in the UK
in February this year.
--tim
In article <···············@cley.com>, Tim Bradshaw <···@cley.com>
wrote:
> This argument could hold for, say, SMS. It's no use until lots of
> people have compatible mobile phones, and until the various networks
> will talk to each other. So clearly SMS can't succeed in a commercial
> environment, right? Well, over 1.5 billion SMSs were sent in the UK
> in February this year.
And the phone companies just *love* them, as they get to charge about
the same as ten seconds of voice time for data that takes a fifth of a
second (maximum) to send ... the profit margins are *huge*.
-- Bruce
* Bruce Hoult wrote:
> And the phone companies just *love* them, as they get to charge about
> the same as ten seconds of voice time for data that takes a fifth of a
> second (maximum) to send ... the profit margins are *huge*.
I'm kind of surprised by this (I mean: I'm not surprised by the huge
profit thing: SMS is obviously a rip-off, since it should be possible
to send stuff in the idle time of the network as there are no
real-time constraints like there are for speech). In the UK there are
4 networks, so they ought to be competing and prices should come down,
but evidently not so. Actually, here the differential is worse - I
think peak time voice is ~30p a minute (except no one pays that
because it's all done by obscure `inclusive minutes' tricks, while an
SMS is ~8p. Off-peak voice is almost free (we get 50mins a day
bundled for L10/month or something) so it's even worse.
But really, the message behind all this is that if you invent
something people *actually want* then they will pay for it, and even
pay over the odds. SMS is useful, and although I get annoyed by being
overcharged I still use it really quite a lot.
So if the web wouldn't have taken off without free software, how much,
actually, was it worth to people? I guess nothing.
--tim
In article <···············@cley.com>, Tim Bradshaw <···@cley.com>
wrote:
> But really, the message behind all this is that if you invent
> something people *actually want* then they will pay for it, and even
> pay over the odds. SMS is useful, and although I get annoyed by being
> overcharged I still use it really quite a lot.
SMS is useful because it's simple to use (a la "worse is better"), and
it allows you to do both create and consume content in a community with
your peers. The information you share might be trivial, but it brings
you "closer" to your peers.
> So if the web wouldn't have taken off without free software, how much,
> actually, was it worth to people? I guess nothing.
There were commercial precursors to the web, like AOL, compuserve and
before that, teletext (correct?). Again, the web is more attractive to a
larger group of people because it's simple to use and allows everyone in
relatively simple ways to share content via homepages, chatrooms,
newsgroups and more recently weblogs.
The problem with most commercial approaches in the web is that they are
unidirectional, from provider to consumer. Things work better when you
also provide paths between users. I guess that's one of the reasons why
ebay works, and also why amazon works. (Think about the reviews, etc.)
Perhaps that's also a reason why open source works - it provides many
ways for communication between users. That's a thing you usually don't
have with commercial software.
Note that the web is worth to people - they usually pay for the
connection.
Just my 0.02�
Pascal
--
"If I could explain it, I wouldn't be able to do it."
A.M.McKenzie
Tim Bradshaw <···@cley.com> writes:
> * Robert STRANDH wrote:
>
> > As far as the Minitel is concerned, most countries failed because
> > consumers were unwilling to buy the equipment until there were a
> > fairly large number of services, and the services were unwilling to
> > invest as long as there were few users. The French phone company
> > solved the problem by giving away a rudimentary terminal and
> > providing one service, the phone book. That was enough to get the
> > ball rolling.
>
> This argument could hold for, say, SMS. It's no use until lots of
> people have compatible mobile phones, and until the various networks
> will talk to each other. So clearly SMS can't succeed in a commercial
> environment, right? Well, over 1.5 billion SMSs were sent in the UK
> in February this year.
Though SMS was introduced for switches and base stations to send
simple messages to a central point, so the infrastructure was already
part of the GSM specification and (thus) getting things from one
network to another is (at most) not very hard. Also, based on
observing the GSM roll-out (from a consumer perspective) in Sweden,
SMS didn't get wide usage before ca 1997-1998, with the early hand
terminals popping up *way* earlier (and with SMS capability in them).
//Ingvar
--
Self-referencing
Five, seven, five syllables
This haiku contains
On 29 Mar 2003 18:18:50 -0500, Kent M Pitman <······@world.std.com> wrote:
> of free software, but I didn't want to let stand a claim that appeared
> to suggest that the web would only have come to a rise due to free
> software. I'm quite sure that it was an idea whose time had come and
> that would not be stopped. It might have come more slowly, but the
> likely effect of that is that web shopping would have been worked out
> in an orderly fashion, including possibly micropayments, and perhaps
> people all over the world who supplied content would have gotten paid
> for that content.
Wasn't Xanadu supposed to address at least part of that?
Paolo
--
Paolo Amoroso <·······@mclink.it>
From: Bulent Murtezaoglu
Subject: Re: Learning new things
Date:
Message-ID: <87k7egbtxt.fsf@acm.org>
>>>>> "PS" == Peter Seibel <·····@javamonkey.com> writes:
[...]
PS> Those of us who write software for a living can make money to
PS> the extent that there is market demand for software that
PS> exceeds the current supply. Kent's argument--as I understand
PS> it--is that folks who write free (gratis) software decrease
PS> the market value of other software by increasing the
PS> supply. But what happens to the *demand* for software as a
PS> consequence of people writing free software?
Ah, I wasn't overlooking that (at least not in my head). I suspect
you use free software in the non-GPL sense. In that case at least
_one_ of KMP's complaints disappear or get weaker (that GPL is
advertised as a panacea with zeal without and without much thought on
self-interest).
PS> Software isn't
PS> razor blades--writing a useful Foo library, while it will
PS> probably decrease the demand for Foo libraries, may *increase*
PS> the demand for software generally--there may be whole new
PS> markets created that want software *using* this now readily
PS> available Foo library. In that case, all software developers
PS> can benefit from the expanded demand.
That is right. Reference implemantations etc. do that (BSD TCP/IP
stack comes to mind).
PS> [...] Do you
PS> think the web would have taken off if Tim Berners-Lee had quit
PS> his job at CERN and started a company trying to figure out how
PS> to commercialize HTML/HTTP. Or if the availability of free
PS> software such as NCSA HTTP server and then Apache hadn't made
PS> it economically feasable for tens of thousands of folks to
PS> experiment with putting up a web site.
I'll part ways with KMP here and say no I am not convinced that the
WWW would have been as successful had it not been for its availability
in no monetary cost form at the start. I am unsure what would have
happened and whether we'd be using HTTP or some other stateful scheme
instead or indeed how long (months surely at that point) it would have
taken for something as potentially pervasive to emerge. But this is
an argument for sharing technology/code among techies not GPL and
ceratinly not GPL zealots. Mosaic was not under GPL. I am unsure
about Cern httpd. Apache certainly is not GPL'ed.
[...]
PS> I'm not saying this is always the case--any given piece of
PS> software can increase, decrease, or not affect at all the
PS> demand for other software. But to say that people writing free
PS> software necesarily harms the economic interests of other
PS> software developers seems to simplistic.
Nobody worth responding to is arguing that (I say while scratching my
head trying to think if _I_ said it). KMP is making the point that
it _might_ (and offers an existence proof).
cheers,
BM
Bulent Murtezaoglu <··@acm.org> writes:
> >>>>> "PS" == Peter Seibel <·····@javamonkey.com> writes:
> [...]
> PS> Those of us who write software for a living can make money to
> PS> the extent that there is market demand for software that
> PS> exceeds the current supply. Kent's argument--as I understand
> PS> it--is that folks who write free (gratis) software decrease
> PS> the market value of other software by increasing the
> PS> supply. But what happens to the *demand* for software as a
> PS> consequence of people writing free software?
>
> Ah, I wasn't overlooking that (at least not in my head). I suspect
> you use free software in the non-GPL sense. In that case at least
> _one_ of KMP's complaints disappear or get weaker (that GPL is
> advertised as a panacea with zeal without and without much thought
> on self-interest).
Yeah. The GPL complicates things. (Personally I have a feeling that
there's a way to build a reasonable software while GPL'ing one's own
software. But until I prove that it's possible by doing it I won't
drag us there. ;-))
> PS> [...] Do you
> PS> think the web would have taken off if Tim Berners-Lee had quit
> PS> his job at CERN and started a company trying to figure out how
> PS> to commercialize HTML/HTTP. Or if the availability of free
> PS> software such as NCSA HTTP server and then Apache hadn't made
> PS> it economically feasable for tens of thousands of folks to
> PS> experiment with putting up a web site.
>
> I'll part ways with KMP here and say no I am not convinced that the
> WWW would have been as successful had it not been for its
> availability in no monetary cost form at the start. I am unsure what
> would have happened and whether we'd be using HTTP or some other
> stateful scheme instead or indeed how long (months surely at that
> point) it would have taken for something as potentially pervasive to
> emerge. But this is an argument for sharing technology/code among
> techies not GPL and ceratinly not GPL zealots. Mosaic was not under
> GPL. I am unsure about Cern httpd. Apache certainly is not GPL'ed.
Well, Linux is a better example then--it's GPL'd. But how much of the
tech economy right now is devoted to Linux related foo? Probably a
fair bit. That's my point--the existence of a piece of software can
create new markets which means more demand which means higher prices
for us software types.
> [...]
> PS> I'm not saying this is always the case--any given piece of
> PS> software can increase, decrease, or not affect at all the
> PS> demand for other software. But to say that people writing free
> PS> software necesarily harms the economic interests of other
> PS> software developers seems to simplistic.
>
> Nobody worth responding to is arguing that (I say while scratching
> my head trying to think if _I_ said it). KMP is making the point
> that it _might_ (and offers an existence proof).
Which was the existince proof? AllegroServe vs. his HTTP server? That
has always seemed like a bit of a strange example of "free software"
hurting developers; isn't that an example of a commercial entity
acting in what it considered its own best economic interest.
Loss-leaders are not a free software phenomenon. Or was there another
example he used?
-Peter
--
Peter Seibel ·····@javamonkey.com
The intellectual level needed for system design is in general
grossly underestimated. I am convinced more than ever that this
type of work is very difficult and that every effort to do it with
other than the best people is doomed to either failure or moderate
success at enormous expense. --Edsger Dijkstra
From: Bulent Murtezaoglu
Subject: Re: Learning new things
Date:
Message-ID: <87el4obnxx.fsf@acm.org>
>>>>> "PS" == Peter Seibel <·····@javamonkey.com> writes:
[...]
PS> Yeah. The GPL complicates things. (Personally I have a feeling
PS> that there's a way to build a reasonable software while
PS> GPL'ing one's own software. But until I prove that it's
PS> possible by doing it I won't drag us there. ;-))
Oh I'd believe it. Quite a few people do that I suspect.
[...]
PS> Well, Linux is a better example then--it's GPL'd. But how much
PS> of the tech economy right now is devoted to Linux related foo?
I wonder about that. I know that delivering specialized solutions on
top of Linux can make one money (be it embedded of otherwise). I am
not sure about the rest. It seems like support and glue/adaptation
work is the bulk of the remainder.
PS> Probably a fair bit. That's my point--the existence of a piece
PS> of software can create new markets which means more demand
PS> which means higher prices for us software types.
Point taken as stated, and I agree. But still, I think KMP's point
stands that it is not clear where GPL fits in all this and it isn't
clear it's popularity is harmless. But this branch of the thread is
wandering away a bit I think. I see two main areas here that seem
relevant:
1- GPL and the culture around it and whether it is disempowering for
the professional programmer.
2- The availability of inexpensive software that is lowish level (the
infrastructure argument is similar) to be built upon creates demand
for more software (that is of the for-money kind)
I think these are distinct although I think I can see how when the aim
is GPLing everything those two can merge and an argument can be
constructed where the programmer sorts basically give the society a
gift and make their lives easier while doing it.
[...]
PS> Which was the existince proof? AllegroServe vs. his HTTP
PS> server?
That's the one I know.
PS> That has always seemed like a bit of a strange example
PS> of "free software" hurting developers; isn't that an example
PS> of a commercial entity acting in what it considered its own
PS> best economic interest. Loss-leaders are not a free software
PS> phenomenon.
Oh but they are in the sense we have been using 'free.' One can make
the same argument about how, with Allegroserve, we are now able to do
more work (and indeed that's what Franz wanted I suspect).
cheers,
BM
Bulent Murtezaoglu <··@acm.org> writes:
> A good experienced programmer in a decent economy can (or used to be
> able to) fetch 6-figs.
With the increasing trend in outsourcing programming to India, the
current glut of cheap programmers, and the well-known propensity of
most hiring companies to hire numerous cheap and replaceable
developers rather than a few expensive (and more difficult to
replace) programmers, I don't think that the outlook is nearly as
good as you say, for most "good experienced programmers." And I
don't think the presence of GPLed software matters that much in the
face of other factors.
Unless you restrict "good experienced programmers" to those who can
actually find jobs of that sort and assume that none of the people
who have troubles finding jobs must have faults of some sort.
--
Alan Shutko <···@acm.org> - I am the rocks.
Looking for a developer in St. Louis? http://web.springies.com/~ats/
Then the 3-headed alien in the arboretum said,"We want...a shrubbery!"
From: Bulent Murtezaoglu
Subject: Re: Learning new things
Date:
Message-ID: <87smt4bv1y.fsf@acm.org>
>>>>> "AS" == Alan Shutko <···@acm.org> writes:
AS> Bulent Murtezaoglu <··@acm.org> writes:
>> A good experienced programmer in a decent economy can (or used
>> to be able to) fetch 6-figs.
AS> [agreement elided] And I don't think the presence of
AS> GPLed software matters that much in the face of other factors.
As KMP clarified, the essertion is not that there clearly is overall
effect there (though, there certainly was in his particular case).
AS> Unless you restrict "good experienced programmers" to those
AS> who can actually find jobs of that sort and assume that none
AS> of the people who have troubles finding jobs must have faults
AS> of some sort.
I tried to qualify what I wrote to avoid the latter implication from
being inferred. Apparently I failed.
cheers,
BM
I understand's Kent's position this way:
1) He wants to write a program that, then, many people
use and benefit from.
2) He wants a little money from each of them (or in proportion
to their numbers) so that he gets a lot of money
for writing that program.
3) He believes that GPL precludes this, while non-public licensing
supports it. He further believes that a programmer writing GPL
code can _at best_ get paid for his time; and likely less than
that. Therefore, as he puts it, GPL turns programmers into a
peasant class.
(1) and (2) are fine goals and I share them.
(3) is problematic for several reasons.
*) non-public licensing doesn't fix the problem
The myth of the killer-app writer who goes home with a bundle
is mostly a false myth. It almost never happens that way.
When it happens that way with any reliability in a given market,
almost immediately, some big companies muscle in and shut out the
small players. The treatment of programmers by those big companies
is, as a rule of thumb, to pay them (as little as possible) for
their time. While a few K of people made killings during the
bubble from stock options, going forward it's clear that that will
always be the rare exception, not the rule.
The "windfall" Kent wants is collected: but, as in the major-label
recording industry, it doesn't benefit the artists very much.
So yes, Kent, there are pressures to reduce programmers and other
laborers to peasants -- but they do not depend on the choice of
license.
*) Bad logic
Kent's thesis is based on a logical fallacy:
a) *One* way to make a windfall from a popular program is by
selling licenses.
b) GPL doesn't permit selling licenses.
c) Therefore GPL doesn't permit a programmer to collect a
windfall.
To complete the argument, Kent would have to show that the *only*
way to to make a windfall from a popular program is by selling
licenses.
The reason to point out the fallacy is that our shared goal is (1)
and (2) above -- now we know that to achieve our goal:
c') GPL's influence, if we believe it is dominant, requires
us to find *another* way to make a windfall from a
popular program.
There is reason to be disheartened, though: so far as I know,
nobody has succeeded at collecting a windfall for a GPL program.
At least a few have made windfalls from non-public licenses.
My (purely thought experiment) solution is along these lines:
*) Enter lisp
Lemme get all poetic and gushy for a moment. Much of my early
experience while learning to program was writing Emacs extensions.
With very little code, I could quickly write very powerful
applications. Here was this "basis set"/framework (emacs) -- with a
very rich "span" -- and picking of targets within that span was
cheap and fun. I had a similar experience when I was learning by
writing classic-style unix shell tools. Those two are amazing
architectures with the interesting economic characteristic than an
up-front steep investment in making the platform leads to a huge
space of inexpensive opportunities.
Both of those are "retro" environments. They're both behind the
times in a lot of ways. You have a hard (not impossible, but hard)
time generating extensions in them for gramma, or jonny-school-kid,
or susie-suburbia, ollie-office-worker. Similar architectures have
yet to be achieved in spaces like modern gui apps, productivity
software, games, household mgt. etc. I think it can be done --
I'm pretty much certain it can be done -- but I don't personally
have the capital to cover the up-front costs.
*) Enter the Internet and Web
One thing that I think the GPL doesn't preclude, as a practical
matter: charging $5-$15 for a distribution. And since the
marginal cost of sending such a distribution is pennies, that's a
big chunk of change for a popular app.
Why should anyone buy that distro from _me_, though, when Joe down
the street can grab a copy and sell it for $1-2 less?
*) Programming is a Feedback Loop; The Quality of the Total Customer
Experience Matters; There's Strength in Numbers
This post is too long already and my expansion on this point would
be hopelessly speculative. There's also tons and tons of specific
variations on the abstract formula.
Here's one variation:
http://newsforge.com/article.pl?sid=02/11/05/1254241
-t
Suppose you would like to increase the total wealth of all programmers
on the theory that you are a programmer, you would like to have more
wealth, and if programmers in general are wealthier your odds are better.
No species survives by eating their young. Developers using personal
money to buy proprietary development software is an exercise in income
redistribution. Cash moved from one developer to another does not
increase the total cash held by all developers. In fact, total cash held
by programmers decreases when programmers spend personal cash for
development tools since marketing, accounting, shipping, etc. take their
cuts from the software's price.
When software companies buy development tools a portion of the total
cash brought in by the marketing-accounting-programming combination is
moved to another organization which goes through the same layers in
reverse. Another wash for total developer cash.
When non-software companies with a programming staff purchase
development tools, the tools help the non-software company's programmers
help their company stay afloat, which keeps those programmers employed,
and the purchase of development tools helps the tools company stay
afloat. It's win-win but one company paid, the other received, total
programmer cash is a wash. (Think about non-software companies with
large staff of programmers and tool companies with a small staff; then
think about the opposite situation. Total cash to programmers is the same.)
When a software company or a company with programmers uses GPL software,
that company has lower costs and is more competitive. They have cash to
retain their programmers and possibly hire more. In total, another wash.
It is only when non-software companies with no programmers use GPL
non-tool software (what would they do with tools, they have no
developers) that the total income of all programmers decreases.
Everything else is more-or-less-wash income redistribution between
developers. I think this is the situation to which kmp refers.
The only hope for increasing the total wealth of programmers is to bring
in cash from the outside. Those who would like to make money with Lisp
must develop software for people who do things other than develop software.
Otherwise, developing products for non-developers requires knowing
something about what people need and knowing about what they do and how
their businesses work, and being willing to do that work for them.
Jeff
In article <·······················@news1.news.adelphia.net>,
Jeff Caldwell <·····@yahoo.com> wrote:
> It is only when non-software companies with no programmers use GPL
> non-tool software (what would they do with tools, they have no
> developers) that the total income of all programmers decreases.
> Everything else is more-or-less-wash income redistribution between
> developers. I think this is the situation to which kmp refers.
So kmp should have no problem with gcc, emacs, gmake, perl, or for that
matter, linux.
It is Open Office that should be rooted out and destroyed.
Interesting theory.
I do know that I personally have no qualms about feeding back
improvements to development tools, and have done so a number of times,
for a number of tools.
-- Bruce
On Sun, 30 Mar 2003, Jeff Caldwell wrote:
> Cash moved from one developer to another does not
> increase the total cash held by all developers.
You're assuming software is a commodity. What if I have a consumer product
which I can only make and release using a tool developed by another
company? Then my buying that product will (indirectly) increase my wealth.
Pretty much all buying decisions are like this -- software is a technology
which enables you to do more faster, i.e. it is an investment which will
bring you profit.
> It is only when non-software companies with no programmers use GPL
> non-tool software (what would they do with tools, they have no
> developers) that the total income of all programmers decreases.
You assume programmers and non-programmers live in totally separate
economies. Programmers also use consumer software. And they benefit from
living in a society where everyone is more efficient. And they enjoy
all the other personal benefits of using open source.
The question is, do these benefits outweigh the direct benefits you get
from charging for your software? I'm inclined to say, yes, very often if
not always.
Kent M Pitman <······@world.std.com> writes:
> Marc Spitzer <········@optonline.net> writes:
>
> > Adrian Kubala <·······@sixfingeredman.net> writes:
> >
> >
> > > 2. it is ongoing; as with any technology, there is always room for
> > > improvement
> >
> > There may always be room, but is there a economic need?
>
> Not when the GPL forbids charging for the value in the improvement.
I was not thinking about the gpl at all. What I was thinking about
is the cost vs benefit curve. For example compiler A produces 10%
faster code then compiler B, but compiler A cost 5 times as much as B.
Most places will not buy compiler A, if they have a choice in the
matter.
>
> > > 3. individual copies of software are economically worthless, since they
> > > cost nothing to produce, though the software itself may be quite
> > > valuable
> >
> > Well that is saying that like saying that all the R&D cost on a car is
> > something that the producer should eat. This is a recipe for no new
> > cars.
>
> well said.
I just wanted to make sure the above comment got in google again ;)
marc
* Kent M Pitman wrote:
> At this point, I don't think Oracle is threatened by free software
> databases since they are probably already making most of their money
> on consulting, support, and other residuals, not on the basic
> product. A free software entrant is not likely to bring them down,
> in other words. What it will do is keep other commercial entrants
> from moving in, because it will shave so much off the potential low
> end offering price that it will assure there will be no low end
> commercial version.
I think they're also not threatened by the free software databases
because they just suck for a lot of purposes for which people are
willing to pay big money. Like doing *really* reliable, scalable
transaction processing. That kind of stuff is just extremely hard and
expensive to get to work right.
--tim
On Sun, Mar 16, 2003 at 09:38:22PM -0800, Frank A. Adrian wrote:
> First, any software written in Lisp would be much less susceptible to
> the types of buffer overrun attacks, memory allocation errors, etc.
> that plague their bretheren written in C and C++. This could make an
> SMTP server written in Lisp much more reliable, robust, and secure
> than the alternatives. I still think that there is a market that will
> pay for security, so if the application touts the security benefits,
> it can still make money.
However, qmail's already filled that particular niche ;-) I think there
is an outstanding reward of $500, unclaimed since March 1997, to the
first person who finds a security flaw in qmail.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
* Matthew Danish wrote:
> However, qmail's already filled that particular niche ;-) I think
> there is an outstanding reward of $500, unclaimed since March 1997,
> to the first person who finds a security flaw in qmail.
But there are 9 billion other bits of software which suffer from
buffer overflows. I rebuilt samba today, for instance.
--tim
On 2003-03-17, Matthew Danish <·······@andrew.cmu.edu> wrote:
> However, qmail's already filled that particular niche ;-) I think there
> is an outstanding reward of $500, unclaimed since March 1997, to the
> first person who finds a security flaw in qmail.
Funny thing you should bring up qmail, since I just rewrote the SMTP
server for it to handle user based anti spam rules. My version was
all written in C and (due to my own custom string handling 'class' and
some other security things I know about) *I think* it's secure, but
due to the nature of the language I have my doubts and fears that
there is probably something in there that could rear it's ugly head.
qmail is very interesting in it's approach to security and is very
well thought out; from it's owners and permissions given to it's
seperate components to it's extensive use of obfiscation libraries
(the code has to be some of the most unreadable, yet quite well
written code I've ever seen and I think that was on purpose since it
takes quite a bit of dedication to reverse engineer it...i know it was
hell at first).
Which brings me up to an interesting thing that reverse engineering
the qmail code. The harder your code is to read, the harder it for
someone to go in and find the bugs, which I can see as being good for
Lisp since it uses a programming methodology which many people are
unfamiliar with as well as being more secure (or at least as secure as
the underlying implementation), which is quite a big part of keeping
the black hats out of the code...maybe.
--
burton samograd
······@hotmail.com
http://kruhftwerk.dydns.org
* Burton Samograd wrote:
> Which brings me up to an interesting thing that reverse engineering
> the qmail code. The harder your code is to read, the harder it for
> someone to go in and find the bugs, which I can see as being good for
> Lisp since it uses a programming methodology which many people are
> unfamiliar with as well as being more secure (or at least as secure as
> the underlying implementation), which is quite a big part of keeping
> the black hats out of the code...maybe.
I don't think this is really right. `Security through obscurity' is
notoriously something that is not a good idea.
--tim
+ Tim Bradshaw <···@cley.com>:
| * Burton Samograd wrote:
|
| > Which brings me up to an interesting thing that reverse engineering
| > the qmail code. The harder your code is to read, the harder it for
| > someone to go in and find the bugs, which I can see as being good for
| > Lisp since it uses a programming methodology which many people are
| > unfamiliar with as well as being more secure (or at least as secure as
| > the underlying implementation), which is quite a big part of keeping
| > the black hats out of the code...maybe.
|
| I don't think this is really right. `Security through obscurity' is
| notoriously something that is not a good idea.
While I certainly agree with this, I don't think the qmail code is
/that/ hard to read. It does take a while to get going, until you
have figured out the string handling and i/o code, but then it's no
harder to read than any other C code I have seen.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Yes it works in practice - but does it work in theory?
On 2003-03-20, Harald Hanche-Olsen <······@math.ntnu.no> wrote:
> While I certainly agree with this, I don't think the qmail code is
> /that/ hard to read. It does take a while to get going, until you
> have figured out the string handling and i/o code, but then it's no
> harder to read than any other C code I have seen.
True, but there is that initial hurdle which would keep a number of
people out. The source code that I would choose to read (which, to be
honest, really is a very small set of what is available and it's
usually only for a specific section that would help my understanding
of it) would not be encumbered by those barriers ie. if I wasn't being
paid to reverse engineer it, I wouldn't have looked at it for more
than two seconds, given up and gone to look at the postfix code, which
is much nicer to look at.
But by doing that, there is far less of a chance of me finding a bug
which might be located somewhere in there. I think that's how most
security flaws are found; not people explicitly looking for bugs but
people looking to fix things somewhere and then they stumble upon
them. This might not be the case all the time, but I've found just
reading code looking for security flaws to be *very* hard, and knowing
what I find difficult, would probably be hard for others as well.
Given that, I didn't find any bugs in the qmail code although I read
all of it (for the smtp and delivery part that is). So, in my mind,
there is a good correlation between the odd obfiscations and keeping
people out initially, and thus keeping people from finding exploits
since I like to think of people as white hats rather than black.
--
burton samograd
······@hotmail.com
http://kruhftwerk.dydns.org
Burton Samograd <······@hotmail.com> wrote:
+---------------
| If I wasn't being paid to reverse engineer it, I wouldn't have looked
| at it for more than two seconds, given up and gone to look at the postfix
| code, which is much nicer to look at.
|
| But by doing that, there is far less of a chance of me finding a bug
| which might be located somewhere in there. I think that's how most
| security flaws are found; not people explicitly looking for bugs but
| people looking to fix things somewhere and then they stumble upon them.
+---------------
And not just security flaws. All sorts of problems -- data size, code
bloat, speed issues -- seem to get fixed mainly when looking for some
*other* bug and then "just stumbling upon them" while reading the code.
In the 1970's, DEC started writing a lot of their PDP-10 systems code
(compilers, batch system) in the programming language BLISS (instead of
MACRO-10 assembler, which is what everything had been written in up to
that time). When users (of which I was one) started complaining that
the new FORTRAN-10 compiler (written in BLISS) was *huge* compared to
the old, beloved F40 compiler (written in assembler), as the fan of
BLISS myself I proposed a half-humorous/half-serious "Warnock's Law
for why BLISS programs are big", which was that since BLISS programming
was *so* much less error-prone than programming in assembler, once the
code had been written it was (mostly) never read again! And *therefore*
it missed out on all of the opportunities for optimization that ordinarily
occurred during "debugging".
Just consider: How many times have you dived into a piece of C code to
track down some simple bug, only to stumble across some *really* stupid
algorithm [e.g., a bubble sort of a large dataset instead of quicksort,
or a linear search of a large list of items rather than a hash table, or
massively-repetitious inlining of a large code snippet that could just
as easily be factored out into a subroutine, etc.] that you just fixed
"just in passing"?
In those same early 1970's, at Digital Communications Assoc. in Atlanta
we discovered how to write (nearly-)error-free assembler code [because
we *had* to -- we didn't have enough money to keep sending out updated
versions of the PROMs with the embedded code for our communications
processors!]. It was very simple, actually: We just made sure that
*every* line of code that went out the door had been read -- not just
glanced at, but actively *proofread*, with an eye towards "breaking"
it -- by *at least* 2 or 3 programmers other than the one who wrote it.
Read & read & read & tweaked & read & read & read some more. Expensive
(from one point of view), but very effective. Especially if the "readers"
get to look at the code in small, managable sections as its being written.
[At DCA, when one "came up for air" after coding any sizable subroutine,
one would grab a fresh cup of coffee and round up a couple of of people
to go into a conference room and have a "design review" (what we called
it -- really a line-by-line "break me if you can" walkthrough). Because
the reviews were frequent (a couple a day) and relatively short (~30min),
they were a natural part of the work flow and actually happened, rather
than being some monster "Project Design Review" event occuring entirely
late in the devlopment process to change anything!!]
But these days, try getting a manager of a C or C++ development team to
even *allow* people time to read other people's code, much less require it!!
[Though XP's "pair programming" is a re-invention of part of the spirit
of it, though with far too much rigidity of process for my taste.]
The implications for Lisp programming should be obvious. We speak
of avoiding premature optimization [which is good] during hyper-fast
incremental and interactive development, but once the resulting program
works (for some value of "work") how many of us -- honestly, now! --
always go back and perform a profiling and/or optimization pass over
the code? Or even just a "cleanup" pass?
Maybe I should retitle it "Warnock's Law for why {BLISS,Lisp,Dylan,ML}
programs are big"... ;-} ;-}
-Rob
-----
Rob Warnock, PP-ASEL-IA <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On 2003-03-21, Rob Warnock <····@rpw3.org> wrote:
> And not just security flaws. All sorts of problems -- data size, code
> bloat, speed issues -- seem to get fixed mainly when looking for some
> *other* bug and then "just stumbling upon them" while reading the
> code.
True, but I would like to point out that I am only talking about qmail
and it's development as a stand alone mail system written and modified
by only one person. I think that the code is not difficult for him to
read or debug (much like mine isn't to me) and I'm sure he has gone
over it many times, simply because of his bug wrangler fee, which I've
only seen on other programmer, Donald Knuth, do.
> Just consider: How many times have you dived into a piece of C code to
> track down some simple bug, only to stumble across some *really* stupid
> algorithm [e.g., a bubble sort of a large dataset instead of quicksort,
> or a linear search of a large list of items rather than a hash table, or
> massively-repetitious inlining of a large code snippet that could just
> as easily be factored out into a subroutine, etc.] that you just fixed
> "just in passing"?
Stumbled across too many times, usually in my own code. Having the
skills/ability/time to replace the problem has not been possible
during my career. I've seen and done so many wrong implimentations in
the past and being scared to death of horribly breaking a working
system I generally pass on such things and do a complete rewrite. I
hate modifying code (other people's C especially) due to the massive
amount of side effects that are usually present and undocumented.
> In those same early 1970's, at Digital Communications Assoc. in Atlanta
> we discovered how to write (nearly-)error-free assembler code [because
> we *had* to -- we didn't have enough money to keep sending out updated
> versions of the PROMs with the embedded code for our communications
> processors!]. It was very simple, actually: We just made sure that
> *every* line of code that went out the door had been read -- not just
> glanced at, but actively *proofread*, with an eye towards "breaking"
> it -- by *at least* 2 or 3 programmers other than the one who wrote it.
> Read & read & read & tweaked & read & read & read some more. Expensive
> (from one point of view), but very effective. Especially if the "readers"
> get to look at the code in small, managable sections as its being
> written.
I was also in the same boat when writing gameboy games but I was lucky
enough to be the guy doing most of the coding. I proofread my code
extensively simply because I didn't want to send the game to testing
just to have it sent back with a 20-100 page bug list. Games aren't
quite the same as communication satellites, but they do have quite
varying requirements that are generally not seen in such systems.
> [At DCA, when one "came up for air" after coding any sizable subroutine,
> one would grab a fresh cup of coffee and round up a couple of of people
> to go into a conference room and have a "design review" (what we called
> it -- really a line-by-line "break me if you can" walkthrough). Because
> the reviews were frequent (a couple a day) and relatively short (~30min),
> they were a natural part of the work flow and actually happened, rather
> than being some monster "Project Design Review" event occuring entirely
> late in the devlopment process to change anything!!]
That's pretty much how I've always written code, C or assembly, but I
find that so much easier with interactive development.
> But these days, try getting a manager of a C or C++ development team to
> even *allow* people time to read other people's code, much less require it!!
> [Though XP's "pair programming" is a re-invention of part of the spirit
> of it, though with far too much rigidity of process for my taste.]
Everywhere I've been the idea of code reviews has been laughed (or
shouted) out of the room, and I'd have to say even by myself. I'm
starting to get into reading other people's code, but it's way more
fun to write, but i'd hate to see what a generation of book writers
would produce if they just ran out of the gates after they learned the
basics of english. I guess as i get older I see a much greater
importance to learning styles and what can be learned from them.
> The implications for Lisp programming should be obvious. We speak
> of avoiding premature optimization [which is good] during hyper-fast
> incremental and interactive development, but once the resulting program
> works (for some value of "work") how many of us -- honestly, now! --
> always go back and perform a profiling and/or optimization pass over
> the code? Or even just a "cleanup" pass?
I've never worked on a project that had such a concept as the "pass".
It was always "get it done as fast as you can and get it out the
door". Why I'm looking at alternative programming techniques is to
reduce the time to finish to enable these passes, since everybody
always talks about them but nobody seems to actually "do" them (ok,
maybe just me). I always feel like I learned to code things the
fastest way (machine wise, not algorithm wise, but I'm quite aware
that I always use arrays instead of trees in hopes that I'll get an
optimization time later on), but not having time to check or analyse
my code, I would think I'm wrong in some of my basic assumptions.
> Maybe I should retitle it "Warnock's Law for why {BLISS,Lisp,Dylan,ML}
> programs are big"... ;-} ;-}
I've seen the same thing happen with C. I don't think the language
matters, it's the lack of desire to see what's already out there and
just write it again, since that's more fun than digging through code.
I can see a big market for a new generation of code analysis and
querying tools in the near future, but what they might be I'm still
trying to figure out.
--
burton samograd
······@hotmail.com
http://kruhftwerk.dydns.org
After takin a swig o' Arrakan spice grog, Burton Samograd <······@hotmail.com> belched out...:
> On 2003-03-21, Rob Warnock <····@rpw3.org> wrote:
>> And not just security flaws. All sorts of problems -- data size,
>> code bloat, speed issues -- seem to get fixed mainly when looking
>> for some *other* bug and then "just stumbling upon them" while
>> reading the code.
> True, but I would like to point out that I am only talking about
> qmail and it's development as a stand alone mail system written and
> modified by only one person. I think that the code is not difficult
> for him to read or debug (much like mine isn't to me) and I'm sure
> he has gone over it many times, simply because of his bug wrangler
> fee, which I've only seen on other programmer, Donald Knuth, do.
The criteria for evaluating qmail seems pretty different from that for
systems in general.
qmail is a system that does something very well-defined, namely to
transfer mail using the SMTP protocol.
There are certainly some complexities involved, but they can be fairly
strictly restricted, that represents one of the merits of qmail's
architecture, namely that it splits processing off into several
processes that communicate in tightly defined ways. The components
are small, and it is straightforward for someone prepared to review
the code carefully to verify that it does what it is expected to do.
It is pretty easy to work up a pretty good level of confidence that
qmail transfers mail quite securely, and that it is inherently
invulnerable to many of the exploits to which Sendmail has often been
vulnerable.
But it is only a solution to one well-defined problem. The world is
filled with problems that are ill-defined, for which it is difficult
to come up with general solutions.
--
(concatenate 'string "aa454" ·@freenet.carleton.ca")
http://www.ntlug.org/~cbbrowne/linux.html
Rules of the Evil Overlord #7. "When I've captured my adversary and he
says, "Look, before you kill me, will you at least tell me what this
is all about?" I'll say, "No." and shoot him. No, on second thought
I'll shoot him then say "No."" <http://www.eviloverlord.com/>
In article <······················@speakeasy.net>,
····@rpw3.org (Rob Warnock) wrote:
> But these days, try getting a manager of a C or C++ development team to
> even *allow* people time to read other people's code, much less require it!!
The place I've been working the last five months just introduced
precisely such a rule: you can't send code to testing until one of four
designated people (out of about fifteen total) has looked at your code.
I'm one of the four, and I've got to have my code looked at by one of
the other three...
-- Bruce
According to Bruce Hoult <·····@hoult.org>:
> The place I've been working the last five months just introduced
> precisely such a rule: you can't send code to testing until one of four
> designated people (out of about fifteen total) has looked at your code.
Do you write your own unit tests or are they written by the testing people?
--
Ng Pheng Siong <····@netmemetic.com>
http://firewall.rulemaker.net -+- Manage Your Firewall Rulebase Changes
http://www.post1.com/home/ngps -+- Open Source Python Crypto & SSL
In article <············@mawar.singnet.com.sg>,
····@netmemetic.com (Ng Pheng Siong) wrote:
> According to Bruce Hoult <·····@hoult.org>:
> > The place I've been working the last five months just introduced
> > precisely such a rule: you can't send code to testing until one of four
> > designated people (out of about fifteen total) has looked at your code.
>
> Do you write your own unit tests or are they written by the testing people?
At the moment I'm in support, so I'm implicitly starting from a failure
situation and write a test case to attempt to duplicate the reported bug.
-- Bruce
Bruce Hoult <·····@hoult.org> writes:
> In article <······················@speakeasy.net>,
> ····@rpw3.org (Rob Warnock) wrote:
>
> > But these days, try getting a manager of a C or C++ development team
> > to even *allow* people time to read other people's code, much less
> > require it!!
>
> The place I've been working the last five months just introduced
> precisely such a rule: you can't send code to testing until one of four
> designated people (out of about fifteen total) has looked at your code.
> I'm one of the four, and I've got to have my code looked at by one of
> the other three...
I'm wondering if it can lead to conflicts inside the team? For example,
if the person you gave your code doesn't like it too much (for the style
or some architectural decisions, etc.) but you think it is OK? Could he
force you to change the code? Or it is only about looking for possible
errors, has the form of advice, and doesn't impose any responsibility on
the person looking your code?
Aleksandr Skobelev <···········@list.ru> writes:
> Bruce Hoult <·····@hoult.org> writes:
>
> > In article <······················@speakeasy.net>,
> > ····@rpw3.org (Rob Warnock) wrote:
> >
> > > But these days, try getting a manager of a C or C++ development team
> > > to even *allow* people time to read other people's code, much less
> > > require it!!
> >
> > The place I've been working the last five months just introduced
> > precisely such a rule: you can't send code to testing until one of four
> > designated people (out of about fifteen total) has looked at your code.
> > I'm one of the four, and I've got to have my code looked at by one of
> > the other three...
>
> I'm wondering if it can lead to conflicts inside the team? For example,
> if the person you gave your code doesn't like it too much (for the style
> or some architectural decisions, etc.) but you think it is OK? Could he
> force you to change the code? Or it is only about looking for possible
> errors, has the form of advice, and doesn't impose any responsibility on
> the person looking your code?
In my experience, sometimes these things cause problems in the short
run, but in the long run anyone with product deadlines does not hold
'style' up as a reason to not meet a deadline.
Discussions of 'style' tend to consume slack resources that come when
you don't feel the pressure of a release.
The language standards themselves had this same issue. We argued incessantly
about certain issues in ANSI CL until we started to feel that we were going to
miss our deadline, and then we learned to make snap decisions.
Likewise at the ISO level, there was utter deadlock over a number of issues
that required 'international consensus' to move ahead. Some people (different
people at different times, I'm not trying to single out any person or people
as especially good or bad) saw their role as 'to keep bad things from
happening' until they started to realize that the side effect was also
'keeping good things from happening'. Faced with failure and shutdown by a
specific date, the ISO working group became suddenly more cooperative, with
all parties finally starting to understand their need to reach out more to
appreciate the others' points of view and to make accomodations where there
wasn't a truly compelling reason not to.
The Scheme standard, by contrast, has floundered over style, almost
never moving forward. We argued literally years over issues of
whether #f and () should be the same object, over whether (define (f
x) x) should be shorthand for (define f (lambda (x) x)), and so on.
IMO, this would never happen inside the walls of a moneymaking
operation. This kind of deadlock due to style kept the language tiny,
to some people's great excitement and to others' chagrin. I'd claim
the enabling factor in letting the deadlock persis is that the
language never really had any commercial deadline pressure. (Indeed,
there were actually discussions among the authors in which some
asserted their desire not to make the language "too useful" because
then it would take on a life of their own and the committee would lose
its ability to have its own deliberative control.) Scheme
_implementations_ had deadline pressures, but long ago learned to
extend the language where they needed to _on their own_, and not to
wait for deadlock to clear among people on the authors' committee, who
(IMO) really never seemed to feel any overriding collective need to
clear long-standing, petty deadlocks.
Someone once described a computer as a 'relentless judge of
incompleteness.' Probably there is some corollary that identifies the
market as a 'relentless judge of usefulness.' In fairness, this
always means 'locally useful' and those on the Scheme committee who
are more conservative claim they are designing for the long run, as a
way of saying that the short run doesn't matter. There's some merit
to that. But it hides a lot of sins, too. Whether #f and () are the
same might actually matter in the long run. Whether you allow (define
(f x) x) probably really does not matter in the long run. Both of
these discussions, mercifully, did ultimately terminate. But, at least
the in the case of the 'define' discussion, it went on way longer than
it needed to before this happened.
Kent M Pitman <······@world.std.com> writes:
> Someone once described a computer as a 'relentless judge of
> incompleteness.' Probably there is some corollary that identifies the
> market as a 'relentless judge of usefulness.'
Well, I'm not sure if I understand you properly, but I would prefer to
replace 'market' here with some like 'time'. For I unable to understand
how the market, that craves for cheap things so badly and that is subject
to the advertising tricks, can be 'a judge' and moreover 'a relentless
judge'. IMO tt can be used only (and it is used) for metering of a
'popularity' of some sort and not for a very long period of time.
According to Aleksandr Skobelev <···········@list.ru>:
> Well, I'm not sure if I understand you properly, but I would prefer to
> replace 'market' here with some like 'time'. For I unable to understand
> how the market, that craves for cheap things so badly and that is subject
> to the advertising tricks, can be 'a judge' and moreover 'a relentless
> judge'. IMO tt can be used only (and it is used) for metering of a
> 'popularity' of some sort and not for a very long period of time.
In the short run the market is a voting machine.
In the long run the market is a weighing machine.
Ben Graham said that, I think.
--
Ng Pheng Siong <····@netmemetic.com>
http://firewall.rulemaker.net -+- Manage Your Firewall Rulebase Changes
http://www.post1.com/home/ngps -+- Open Source Python Crypto & SSL
In article <···············@shell01.TheWorld.com>,
Kent M Pitman <······@world.std.com> wrote:
> Aleksandr Skobelev <···········@list.ru> writes:
>
> > Bruce Hoult <·····@hoult.org> writes:
> >
> > > In article <······················@speakeasy.net>,
> > > ····@rpw3.org (Rob Warnock) wrote:
> > >
> > > > But these days, try getting a manager of a C or C++ development team
> > > > to even *allow* people time to read other people's code, much less
> > > > require it!!
> > >
> > > The place I've been working the last five months just introduced
> > > precisely such a rule: you can't send code to testing until one of four
> > > designated people (out of about fifteen total) has looked at your code.
> > > I'm one of the four, and I've got to have my code looked at by one of
> > > the other three...
> >
> > I'm wondering if it can lead to conflicts inside the team? For example,
> > if the person you gave your code doesn't like it too much (for the style
> > or some architectural decisions, etc.) but you think it is OK? Could he
> > force you to change the code? Or it is only about looking for possible
> > errors, has the form of advice, and doesn't impose any responsibility on
> > the person looking your code?
>
> In my experience, sometimes these things cause problems in the short
> run, but in the long run anyone with product deadlines does not hold
> 'style' up as a reason to not meet a deadline.
>
> Discussions of 'style' tend to consume slack resources that come when
> you don't feel the pressure of a release.
Style isn't a reason to miss a tight deadline, but it *is* important --
not so much issues of indenting or variable naming or the like, but
sloppy and hard to maintain things such as duplication of code or
convoluted logic. The company is five years young, growing fast (I
started in October, four programmers in the support team have been there
longer than me and eight started after me), and some of the coding style
compromises that I am sure were absolutely necessary in the early days
in order to make deadlines and let the company survive are now starting
to look rather cowboyish and are definitely hurting our bug rate and the
five nines service availability that our newer customers are demanding.
-- Bruce
Bruce Hoult <·····@hoult.org> writes:
> > Discussions of 'style' tend to consume slack resources that come when
> > you don't feel the pressure of a release.
>
> Style isn't a reason to miss a tight deadline, but it *is* important --
> not so much issues of indenting or variable naming or the like, but
> sloppy and hard to maintain things such as duplication of code or
> convoluted logic. The company is five years young, growing fast (I
> started in October, four programmers in the support team have been there
> longer than me and eight started after me), and some of the coding style
> compromises that I am sure were absolutely necessary in the early days
> in order to make deadlines and let the company survive are now starting
> to look rather cowboyish and are definitely hurting our bug rate and the
> five nines service availability that our newer customers are demanding.
Certainly. In my day we had to invent the notion of style, since it really
didn't exist.
Just even to take the variable naming issue, btw, if you go back to
the Fortran Coloring Book (a really fun teaching document of the era),
for example, you see passages remarking on how you can use any
variable name you like because it doesn't matter. The author suggests
names like HISTORY and GEOGRAPHY are fine variable names. :) At that
time, there were not many programs big enough nor reused enough that
people had a clear understanding of the bad consequences of bad style,
and I agree your scenario shows the counterexample that my generation
had to come to grips with.
Nevertheless, some style issues are just that. For example, whether
to use #'(lambda ...) or (lambda ...), which you might regard as just
a naming/indenting thing but some have strong political feelings about.
Whether to use recursion or iteration gets more into the technical.
Whether to use LOOP is probably one of the biggest and most hard-fought
kind of style things, since both the LOOP and anti-LOOP people have
extremely strong reasons for believing that their personal position will
lead to good code later, and for believing the others' will lead to bad
code. Ultimately, I have come to believe that LOOP can be used competently,
and that arguments by others that it cannot be are petty and dismissive.
It's fine to opt not to use it when writing original code, but it's not fine
to tell someone who's written competent and correct code in it that they
should not have, and it's not fine to tell someone that you don't approve
someone else's code merely because you refuse to learn enough about LOOP
to be able to judge what competent and correct code is. (Just my opinion,
of course.) My basis for thinking this isn't rabid support for LOOP, btw,
but rather rabid support for getting work done and moving on toward deadline.
Kent M Pitman <······@world.std.com> writes:
> Certainly. In my day we had to invent the notion of style, since it really
> didn't exist.
You had style?! We used to DREAM about having style.....
In article <··············@machine.athome>,
Aleksandr Skobelev <···········@list.ru> wrote:
> Bruce Hoult <·····@hoult.org> writes:
>
> > In article <······················@speakeasy.net>,
> > ····@rpw3.org (Rob Warnock) wrote:
> >
> > > But these days, try getting a manager of a C or C++ development team
> > > to even *allow* people time to read other people's code, much less
> > > require it!!
> >
> > The place I've been working the last five months just introduced
> > precisely such a rule: you can't send code to testing until one of four
> > designated people (out of about fifteen total) has looked at your code.
> > I'm one of the four, and I've got to have my code looked at by one of
> > the other three...
>
> I'm wondering if it can lead to conflicts inside the team?
That's possible, of course. I haven't seen any yet, but it's only been
a few weeks.
> For example, if the person you gave your code doesn't like it too
> much (for the style or some architectural decisions, etc.) but you
> think it is OK? Could he force you to change the code?
He could refuse to sign off on it, as indeed I've done a couple of times
already. Or, yesterday, I didn't want to sign off on someone's change
because they'd done some cut&paste duplication of code [1] that I wanted
factored out, and several things were reported only in debug builds that
I thought they should be syslogged as warnings (the situation was when a
prompt couldn't be found in the end user's preferred language, and we
reverted to the default language). The original programmer was happy to
make my suggested changes, but that would result in a patch slipping so
we escalated the issue and got a decision to ship it as it is for now,
and fix my concerns for the next patch.
> Or it is only about looking for possible errors, has the form of
> advice, and doesn't impose any responsibility on the person looking
> your code?
It's largely advice, but if you don't sign off on it then it doesn't
ship. Signing off implies at least shared responsibility for the
results, possibly the bulk of the responsibility of the other programmer
is considerably less experienced.
-- Bruce
[1] to be totally fair, the cut&paste wasn't done by the guy whose
change I was reviewing, but in an earlier cvs transaction against the
same bug by another guy who has since left the team.
* Burton Samograd wrote:
> Given that, I didn't find any bugs in the qmail code although I read
> all of it (for the smtp and delivery part that is). So, in my mind,
> there is a good correlation between the odd obfiscations and keeping
> people out initially, and thus keeping people from finding exploits
> since I like to think of people as white hats rather than black.
But there seems to be an understanding that it's *bad* to find bugs &
exploits. It's not, it's *good* to find them if they are there. Or
rather, it's good to find them before the people who will write
exploits do. I think obfuscation counts negatively here (it favours
the nasty people). The reason I think that is basically economic: I
think that the people who write or debug systems tend to be charging
for their time and therefore their time is expensive and often scarce:
these people can't afford to spend a huge amount of time poring over
some obfuscated code. However the bad guys are students &c whose time
is essentially free: they *are* willing to spend really a long time
grovelling over code to find some exploit.
However, from what you said, it sounds like qmail isn't really
obfuscated as such, it's just written in a curious and idiosyncratic
style that its author happens to like.
As an aside, I posted a somewhat obfuscated bit of Lisp the other day
(I'll repeat it below). How hard is it to spot the bug in this code?
--tim
--cut--
(eval-when (:load-toplevel :compie-toplevel :execute)
(set-syntax-from-char #\] #\))
(set-macro-character #\[
#'(lambda (stream char)
(declare (ignore char))
`(funcall ,@(read-delimited-list #\] stream t)))))
(defmacro ! (name (&rest args) &body code)
`(defun ,name (,@args) ,@code))
(defmacro ^ ((&rest args) &body code)
`(lambda (,@args) ,@code))
(defmacro ?? (test then &optional else)
`(if ,test ,then ,else))
(! <~ (x) (first x))
(! ~> (x) (rest x))
(! <~> (x y) (cons x y))
(! <?> (x) (consp x))
(! ~ (x) (not x))
(! == (x y) (eql x y))
;;; Exercise: given the below, provide the above. For added points,
;;; rewrite it sanely (using LOOP say, as the /sane one above).
;;;
(! mr (form)
;; If FORM is a list, remove every occurrence of the first element
;; from the rest of the list. Do this recursively on sublists.
;; If it is not, return it.
[(^ (o)
[o o form])
(^ (o l/a)
(?? (<?> l/a)
[(^ (i)
[i i (<~ l/a) (~> l/a)])
(^ (i e r)
(?? (~ r)
'()
(?? (== (<~ r) e)
[i i e (~> r)]
(<~> [o o (<~ r)]
[i i e (~> r)]))))]
l/a))])
Tim Bradshaw <···@cley.com> writes:
> As an aside, I posted a somewhat obfuscated bit of Lisp the other day
> (I'll repeat it below). How hard is it to spot the bug in this code?
>
> --tim
>
> --cut--
> (eval-when (:load-toplevel :compie-toplevel :execute)
^^^^^^^^^^^^^^^^
Not very :-)
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Tim Bradshaw <···@cley.com> wrote:
> However, from what you said, it sounds like qmail isn't really
> obfuscated as such, it's just written in a curious and idiosyncratic
> style that its author happens to like.
Just so.
qmail (and its author) are known for a number of "curiosities and
idiosyncracies" not only in terms of coding but also in terms of
portability and licensing.
There's a whole lot of "do as I say, but not as I do" that is possible
there; DJB makes portability recommendations that he breaks within his
own software, and similarly expects everyone else to work to
accomodate his licensing expectations, whilst not doing much to
accomodate others.
He's a professor with tenure, so he can personally afford to be rather
obstinate; it nonetheless has led to a lot of people getting their
backs up, and the sheer mention of his name is, in some places, a
flame war in and of itself.
--
(reverse (concatenate 'string ····················@" "454aa"))
http://cbbrowne.com/info/multiplexor.html
Rules of the Evil Overlord #59. "I will never build a sentient
computer smarter than I am." <http://www.eviloverlord.com/>
* Frank A Adrian wrote:
> First, any software written in Lisp would be much less susceptible to the
> types of buffer overrun attacks, memory allocation errors, etc. that plague
> their bretheren written in C and C++. This could make an SMTP server
> written in Lisp much more reliable, robust, and secure than the
> alternatives. I still think that there is a market that will pay for
> security, so if the application touts the security benefits, it can still
> make money.
This is a *really* good point. I can't stress how good I think it is
enough, actually.
> Second, just because there is a "free" alternative doesn't mean that one
> cannot make money in the market. There are many free database tools. This
> doesn't mean that Oracle and Microsoft can't make money in databases. You
> just have to find an underserved niche - like always.
But this misses the point. The issue is whether a new entrant to the
marked can do well: would writing a new RDBMS at this point be a
sensible commercial move? The only way I think it would be is if you
could spot a market in which Oracle, say, performed really badly, or a
new and shortly-to-be-prevalent sort of hardware (I don't mean just a
new processor, I mean, say, a new kind of pll machine) on which Oracle
performed really badly.
(And incidentally, there really aren't very many free database tools
that compete with the big commercial RDBMSs on their own ground).
--tim
"Adam Warner" <······@consulting.net.nz> writes:
> I see this as the mistake Kent Pitman made in developing a proprietary web
> server: <http://okmij.org/ftp/papers/ILC02-impressions.txt>. Even without
> the Franz web server, Apache is extreme competition.
Well, I doubt his market would be the kinds of people who use Apache
and IIS; rather, it would have been the people who'd use
AllegroServe[1] or CL-HTTPD.
FWIW, I think a big point in all of this is: There's a sore, gaping
need for standardized Common Lisp interfaces for I/O that's more
complicated then terminals and files. Trying to develop and market
such interfaces is not a viable business model because you can't
charge very much[2] and there are major technical and financial
hurdles to being able to market your products to the entire Common
Lisp community (not too big to begin with), instead of just to a
single implementation/platform.
Gabe Garza
[1] "Portable AllegroServe" would probabbly be more accurate, since
IIRC he uses LispWorks.
[2] The price has to be less then the value of the time it would take
to do it yourself. For a lot of things, it doesn't take *that* long
to write a buggy 80% solution using the FFI...
Gabe Garza <·······@ix.netcom.com> writes:
> "Adam Warner" <······@consulting.net.nz> writes:
>
> > I see this as the mistake Kent Pitman made in developing a proprietary web
> > server: <http://okmij.org/ftp/papers/ILC02-impressions.txt>. Even without
> > the Franz web server, Apache is extreme competition.
>
> Well, I doubt his market would be the kinds of people who use Apache
> and IIS; rather, it would have been the people who'd use
> AllegroServe[1] or CL-HTTPD.
>
> FWIW, I think a big point in all of this is: There's a sore, gaping
> need for standardized Common Lisp interfaces for I/O that's more
> complicated then terminals and files. Trying to develop and market
> such interfaces is not a viable business model because you can't
> charge very much[2] and there are major technical and financial
> hurdles to being able to market your products to the entire Common
> Lisp community (not too big to begin with), instead of just to a
> single implementation/platform.
>
> Gabe Garza
>
> [1] "Portable AllegroServe" would probabbly be more accurate, since
> IIRC he uses LispWorks.
I had planned to put it out for all platforms I could get my hands on.
What I use for development is not relevant.
> [2] The price has to be less then the value of the time it would take
> to do it yourself. For a lot of things, it doesn't take *that* long
> to write a buggy 80% solution using the FFI...
Certainly that's so, but that's always so. I was looking at the next tier
up. When I started, there was only CL-HTTP, and its intellectual property
status was sufficiently unclear that a number of commercial settings I'd
seen that wanted web-based products had not been willing to wager their
business that the platform they were building on would not turn out to be
encumbered if they proceeded with CL-HTTP, so I figured the market was ripe
for something else. My sense is that anyone who had invested that amount
of time and was charging to recover the cost would have been possible to
compete against, but not someone who didn't care about recovering that
cost through product sales, as was the case for Franz. Franz wants the
lisp licenses and, more importantly, the follow-on consulting/support, and
so is using AllegroServe as a loss-leader. For a smaller house like me,
that was enough to basically erase 6 months of investment on my part.
What remained in my tools that were different from theirs was not enough
worth stirring up the market about, and the amount I could charge would get
me such minimal return that it wasn't worth proceeding on. I had to back
up and just take the time and effort I did on that as a loss. I've tried
to retarget some of that effort so that it's not entirely a waste, but if I
had that time to spend over again, I would have spent it very, very
differently.
And this is a general risk of free software, in my opinion.
It completely undercuts a legitimate sales market. It annexes side markets
that can be used to recover the market, but in so doing it does not allow
normal capitalistic survival of the fittest to operate because what you are
now testing is whether "their browser + their support" is better than "my
browser + my support". You aren't factoring things out so that you find
out if my browser might have been better (perhaps with their support).
And the people at Franz are my friends! They didn't do this to sabotage me.
They did it as innocently as these kinds of things are likely to happen.
Which is to say that the problem is, I think, with the paradigm of free
software, not with some application of hard-nosed tactical plotting on their
part. It might have been in their best interest, had they known I was doing
a browser, not to bother. But it wasn't in my best interest, and isn't in
the best interest of any commercial enterprise in general, to let the market
know before you're a long distance into things that you're working on
something, since it can force other commercial competition you don't want.
And so, if you don't know what commerce you might be destroying and commercial
entities can't volunteer the info, ... it's just a bad situation.
Kent M Pitman <······@world.std.com> writes:
> [...]
>
> And this is a general risk of free software, in my opinion. It
> completely undercuts a legitimate sales market. It annexes side
> markets that can be used to recover the market, but in so doing it
> does not allow normal capitalistic survival of the fittest to
> operate because what you are now testing is whether "their browser +
> their support" is better than "my browser + my support". You aren't
> factoring things out so that you find out if my browser might have
> been better (perhaps with their support).
There are certainly lots of issues with "free software"[1] and I'm
definitely not a free software zealot. I'm a paying customer of
Xanalys, Corman Technologies, and many other commercial software
vendors, and I'd rather pay a reasonable price for good quality and
support than fight with a 90% solution no matter how "free" it is.
However, I fail to see what you're aiming at, i.e. what the
consequences should be if people subscribed to your arguments. Do you
think it would improve the overall economical situation of the
software industry if "free software" was forbidden or somehow
regulated?
What is your take on companies like Microsoft (good example, I think)
which use their economical power to enter into new markets by not
producing "free software" but giving away software for free (IIS, IE,
you name it) or using dumping strategies?
And don't you think it is legitimate for companies and individuals to
have other business models than you have? I'm pretty sure, that, e.g.,
the core Apache developers don't get paid by their moms and dads and
they don't get paid by universities either. AFAIK most of them pay
their rent with consulting jobs and I'd say that's their business
model. ("Hey, Mr. Behlendorf, that's a pretty steep consulting rate
you're charging!" "Well, OK, but I'm one of the guys who wrote this
web server. I should pretty much know what I'm doing." "Uh, OK, I
see.")
I think you'll just have to live with the fact that not everybody
wants to make their living by selling commodity software. And some of
these competitors of yours happen to see "free software" as a vehicle
to improve their position in the market segment they're in. Unless you
want to severely regulate the whole software business you'll just have
to live with that. At least I can't see that your position is morally
superior or something like that.[2]
Cheers,
Edi.
Two remarks:
A. I personally think that Microsoft is a rather special case and they
/should/ be regulated - because they are /not/ using legitimate
business practises but are instead breaking the laws. This has been
confirmed by several court decisions but it seems to be the current
political will to ignore this.
B. On the other hand I don't see that Franz' behaviour with respect to
AllegroServe is in any way comparable to MS tactics. Of course,
they gave it away for free to increase their sales in other areas
but they explicitely made porting attempts to other CL
implementations possible and even supported them. What's wrong with
that? They just happen to have more developers than HyperMeta or my
one-man company. So what?
Footnotes:
[1] From this threads and other postings of yours I assume that you're
talking about "free software" as defined by the FSF or at least
the OSI - not about software given away for free in
general. Otherwise my whole point here is moot.
[2] You didn't explicitely say that but this is how I understand your
position.
Edi Weitz <···@agharta.de> writes:
> However, I fail to see what you're aiming at, i.e. what the
> consequences should be if people subscribed to your arguments. Do you
> think it would improve the overall economical situation of the
> software industry if "free software" was forbidden or somehow
> regulated?
As a first order of business, I think it would serve the overall software
industry if free software were not regarded as a panacea. I'm leary of
anything which is a mechanism that is regarded as "automatically good".
I believe that it's outcome, not mechanism, that matters. I have the
same problem with church dogma. Dogma is a focus on compiled-in mechanism
and fights thought. Saying there is no clear answer and that one has to
_think_ makes things more complicated, but is more satisfying to me.
I don't know that thinking will always yield a correct answer, but I
suspect that not thinking will not out-perform it.
> I think you'll just have to live with the fact that not everybody
> wants to make their living by selling commodity software.
The problem is that the present climate makes it so that hardly anyone
and may be no one can do it. And the case I'm making is that this is
an impoverished world model.
Free software, in case you don't know, started with richard stallman
being sad that he wasn't going to be able to afford to be a programmer
any more because the complex weave of commercialism left him nowhere
to go that made him The plight of him and others like him plight used
to matter to me more until I found how little my plight mattered to
them. And in the end, the same problem exists.
The reason why I think you should care is not that you should pity me,
but rather that you should feel sad that the world is not economically
empowering people who do programming to do OTHER than programming. Rich
people don't have to spend their riches in the area they earned them.
There is a lot wrong with the world that someone with a keen understanding
of process dynamics could help with. But free software is systematically
economically disempowering the class of people who have this skill, assuring
that the people who want to solve political problems creatively will
not have the resouces to involve themselves in this. The skills required
to succeed in programming+support are mostly things like customer relations.
We who understand process are just the technopeasants of the field, and
we will have nothing to say on the world stage after the one time in history
where we might have.
This assures that politics will be business as usual by people who don't
know what they are doing for pretty much forever after.
Money doesn't always buy good. But diversity does. And by not
assuring that a new class of people will have money, we reduce
diversity and specifically disempower "our own kind". Those of us who
enable this pretty much deserve what they get, in my opinion, but I'm
being dragged down in the process and I resent that. That is, I don't
resent personally not being rich, but I resist that there are not lots
more rich programmers.
This conversation, or one of these nearby threads, started with a discussion
of why there aren't more Lisp things getting started, and this is my
answer: the computer science world has disempowered people who know the
difference between Lisp and a rock. People haven't heard of Lisp, or if they
have, they've heard bad stuff. They aren't personally capable of overcoming
that prejudice by force of thought, so Lisp gets held down.
Lisp could compete in a market only if Lisp were the market. When
"support" becomes the market, no market forces act on Lisp itself to
make the language succeed on its own merits. It succeeds or fails
onlyon the aspects of it that serve its marketing department, not on
those that serve its programmers.
But moreover, the dynamic way of thinking that Lisp is about also does not
get into the world. So we elect politicians who are static thinkers. We
ask them lots of questions before they are elected to assure they will vote
as we want when in office. We compile out their thought processes. If they
EVER shift position, we call them wishy-washy and unpredictable rather than
brave and willing to learn new things. That, too, is a casualty of Lisp
not succeeding wildly, IMO.
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> Free software, in case you don't know, started with richard stallman
> being sad that he wasn't going to be able to afford to be a programmer
> any more because the complex weave of commercialism left him nowhere
> to go that made him The plight of him and others like him plight used
> to matter to me more until I found how little my plight mattered to
> them. And in the end, the same problem exists.
I think something got inadvertantly snipped from that description, but it
doesn't seem entirely accurate. The definitive telling of the story can
be found at http://www.oreilly.com/openbook/freedom/
> The reason why I think you should care is not that you should pity me,
> but rather that you should feel sad that the world is not economically
> empowering people who do programming to do OTHER than programming.
Why should be mourn the disempowerment of programmers any more than the
disempowerment of, say, blacksmiths?
> This assures that politics will be business as usual by people who don't
> know what they are doing for pretty much forever after.
But most programmers are C++ and Perl weenies who also, by the community
standards of c.l.l., don't know what they are doing, so how would
empowering them help?
> This conversation, or one of these nearby threads, started with a discussion
> of why there aren't more Lisp things getting started, and this is my
> answer: the computer science world has disempowered people who know the
> difference between Lisp and a rock. People haven't heard of Lisp, or if they
> have, they've heard bad stuff. They aren't personally capable of overcoming
> that prejudice by force of thought, so Lisp gets held down.
Actually, this thread started with a disagreement about whether learning
something new is axiomatically a good thing. (Look at the title of the
thread.) You said it wasn't, that learning something new is only good if
it leads (potentialy) to making money. I disagree, and nothing you have
said has come close to making me change my mind.
> Lisp could compete in a market only if Lisp were the market.
Paul Graham disagrees. He says that Lisp can compete in any market that
relies on server-side software. And he backs up his claim by being one of
the few people who has actually made money using Lisp, and his market
wasn't Lisp, it was e-commerce. I don't see any reason why Lisp cannot
continue to compete in server-side apps. The main reason it isn't is that
no one seems to be trying (with Orbitz being a notable, and so far
apparently successful, exception).
> But moreover, the dynamic way of thinking that Lisp is about also does not
> get into the world. So we elect politicians who are static thinkers. We
> ask them lots of questions before they are elected to assure they will vote
> as we want when in office. We compile out their thought processes. If they
> EVER shift position, we call them wishy-washy and unpredictable rather than
> brave and willing to learn new things. That, too, is a casualty of Lisp
> not succeeding wildly, IMO.
Wow, that's quite a leap. How do you account for the fact that exactly
the same processes seemed to be at work long before Lisp failed, indeed,
long before computers were invented? I think you've got the causality
backwards here, in which case trying to solve politics by trying to solve
programming will be about as effective as pushing a string.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <···············@shell01.TheWorld.com>, Kent M Pitman
> <······@world.std.com> wrote:
>
> > Free software, in case you don't know, started with richard stallman
> > being sad that he wasn't going to be able to afford to be a programmer
> > any more because the complex weave of commercialism left him nowhere
> > to go that made him The plight of him and others like him plight used
> > to matter to me more until I found how little my plight mattered to
> > them. And in the end, the same problem exists.
>
> I think something got inadvertantly snipped from that description, but it
> doesn't seem entirely accurate. The definitive telling of the story can
> be found at http://www.oreilly.com/openbook/freedom/
You mean it doesn't match what has been told to you by other sources.
Conflicting information doesn't mean that the first person you heard from
is right and the other wrong.
I was part of Richard's community at MIT. . I spoke to him personally
about this. I was at MIT when it got started and had many
interactions with him over this. I watched the emergence of free
software happen in person, not just through what I read in books. I
stand by my account of the story as being "a reasonable assessment"
based on firsthand knowledge. I don't feel a need to yield to some
other person's account as if this were a matter for which there was
only one valid point of view. The whole notion of a "definitive
telling" of history should be suspect to anyone as an abstract notion
in any context, not just this one.
Besides, the "official" lines I've seen from Stallman and others
tend to romanticize what happened in ways that make him seem more of a
folk hero than just the selfish and angry person he always seemed to
me to be. That's not to say I don't think Stallman has done some good
through it all; I just don't like the after-the-fact rewriting of a
very complex history into overly simplistic terms nor the resulting
religion that has resulted from the whitewash.
Btw, even in the best case, truth is often in the middle of multiple
viewpoints and however accurate I may assert my point of view to be, I
urge you to read the alternate accounts, which I suspect is more than
the opposing side will advise you to do. But saying you should read other
opinions is not the same as saying you should ignore me. I have what I
believe is a legitimate perspective based on firsthand conversations over
a span of 2 decades. I am not asserting my opinion to be synonymous
with fact, but I'm claiming it represents a true view of what it looked
like to me as it came down.
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <···············@shell01.TheWorld.com>, Kent M Pitman
> > <······@world.std.com> wrote:
> >
> > > Free software, in case you don't know, started with richard stallman
> > > being sad that he wasn't going to be able to afford to be a programmer
> > > any more because the complex weave of commercialism left him nowhere
> > > to go that made him The plight of him and others like him plight used
> > > to matter to me more until I found how little my plight mattered to
> > > them. And in the end, the same problem exists.
> >
> > I think something got inadvertantly snipped from that description, but it
> > doesn't seem entirely accurate. The definitive telling of the story can
> > be found at http://www.oreilly.com/openbook/freedom/
>
> You mean it doesn't match what has been told to you by other sources.
> Conflicting information doesn't mean that the first person you heard from
> is right and the other wrong.
>
> I was part of Richard's community at MIT. . I spoke to him personally
> about this. I was at MIT when it got started and had many
> interactions with him over this. I watched the emergence of free
> software happen in person, not just through what I read in books. I
> stand by my account of the story as being "a reasonable assessment"
> based on firsthand knowledge. I don't feel a need to yield to some
> other person's account as if this were a matter for which there was
> only one valid point of view. The whole notion of a "definitive
> telling" of history should be suspect to anyone as an abstract notion
> in any context, not just this one.
>
> Besides, the "official" lines I've seen from Stallman and others
> tend to romanticize what happened in ways that make him seem more of a
> folk hero than just the selfish and angry person he always seemed to
> me to be. That's not to say I don't think Stallman has done some good
> through it all; I just don't like the after-the-fact rewriting of a
> very complex history into overly simplistic terms nor the resulting
> religion that has resulted from the whitewash.
>
> Btw, even in the best case, truth is often in the middle of multiple
> viewpoints and however accurate I may assert my point of view to be, I
> urge you to read the alternate accounts, which I suspect is more than
> the opposing side will advise you to do. But saying you should read other
> opinions is not the same as saying you should ignore me. I have what I
> believe is a legitimate perspective based on firsthand conversations over
> a span of 2 decades. I am not asserting my opinion to be synonymous
> with fact, but I'm claiming it represents a true view of what it looked
> like to me as it came down.
Well, you didn't give an account of what happened at all, you gave an
interpretation, that is, you told us (your beliefs about) Stallman's
motivations but said nothing about what actually *happened*. The
reference I cited at least claims to report historical events that are
objectively verifiable so that the reader can draw their own conclusion.
But your point is well taken. I withdraw my characterization of the
reference I cited as "the definitive" account", and simply point it out as
an alternative point of view.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> Why should be mourn the disempowerment of programmers any more than the
> disempowerment of, say, blacksmiths?
For the sam reason as we should protest against the trend to move
development projects offshore to places like India where skilled
employees will be happy to work for some small percentage of what the
average first world programming prima donna pays in rent - never mind
what he'd actually demand in salary.
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
···@jpl.nasa.gov (Erann Gat) writes:
> Why should be mourn the disempowerment of programmers any more than the
> disempowerment of, say, blacksmiths?
Blacksmiths were *not* replaced by amateur blacksmiths,
working for free. Typesetters were not replaced by amateur typesetters
working for free, either.
Disempowerment of traditional programmers is inevitable the
moment there is an economically viable alternative.
On the other hand, blacksmiths and typesetters were replaced
by combinations of people and machines that were capable of building
better, faster and cheaper. Doesn't this sound like a case for
replacing C++/Java/whatever people with Lisp people :-?
--
Raymond Wiker Mail: ·············@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
Raymond Wiker wrote:
> Disempowerment of traditional programmers is inevitable the
> moment there is an economically viable alternative.
Absolutely true. And this is why I believe that not-for-profit and
for-profit software can co-exist. There will always be some software that
people want to write enough that it can be provided for free and software
that you'll have to pay someone to write. There are also differences in
quality, depth of quality assurance, levels of support, etc. that will
continue to differentiate the market. The bottom line is that no one wants
to pay to see me play golf, while Tiger Woods has no problem getting people
to do the same. Similarly, no one will want to have some newbie programmer
write some mission-critical application that they depend on.
All-in-all, I see the whole debate as a bit of a red herring. The free
software types seem to think that their not working for profit gives them
some sort of moral superiority, while those who rail agains the same seem
to think that they hold the same ground by defending against the death of
software in general. In the final analysis, neither hold this ground.
Programming is a fairly mundane activity and those who have a proclivity
for it will sometimes do it for free as well as for profit. To quote the
Red 'Lectroid at the end of "The Adventures of Buckaroo Bonzai Accross the
Eighth Dimension", "So what. Big deal..."
faa
Raymond Wiker <·············@fast.no> writes:
> On the other hand, blacksmiths and typesetters were replaced
> by combinations of people and machines that were capable of building
> better, faster and cheaper. Doesn't this sound like a case for
> replacing C++/Java/whatever people with Lisp people :-?
I am a bit disturbed by the type of advocacy for Lisp presented in
this thread, and in other threads about Lisp vs. Other Languages. I
find this analogous to an ad for fancy basketball shoes that promise
to make me dunk like Michael Jordan. There's a big catch that the
advertisers neglected to disclose to the audience.
I consider myself a rookie programmer. I've been using Lisp in my
work for many reasons (I'm quite the exception because the code
I'm writing is heavily reliant on other Lisp software, so using
Lisp is a requirement in addition to a pleasure) and although I can
clearly see the noble approaches to problems that are offered in Lisp
(which are so "out" of the realm of problem-solving in other
languages), using Lisp did not make me an amazingly efficient, more creative, or
better programmer. The quality of my code has increased because:
- The code I'm using relies on other Lisp libraries, which are all
very well written. (More on this below)
- The noble constructs in Lisp allow some complicated tasks to be
written fairly simply.
However, in the eyes of the readers of this newsgroup, my code would
still be considered lame. It is only in comparison to my previous experiences of
programming in C, Perl, and so on, that this code is better. So while
I was exposed and enlightened to noble thinking methodologies by using
Lisp, I cannot say that I am "improved" enough to employ them
appropriately to every situation to gain advantage over competing
non-Lisp programmers.
I can confidently claim that most competent Lisp programmers
(*especially* the regulars on this newsgroup) are above and beyond
most C++, Java, Perl programmers when it comes to programming,
abstract thinking, and problem-solving knowledge in general. I think
that this is constantly overlooked by Lisp advocators on this group.
When people like Wiker, Pitman, Naggum, Gat and others use Lisp, it is
perfectly reasonable to make those fantastic claims about Lisp's
efficiency, power and so on. But let's be frank guys, it's probably
90% because of your abilities and only 10% due to Lisp's elegance and
facilities.
So yes, Lisp can make you fly like Michael Jordan (or code like Donald
Knuth), *IF* you're capable of understanding it enough to fully
utilize its advantages over other languages. This, in my mind,
requires a lot of capability that few people in the programming
community in general have. That's why Lisp programmers are in the
minority.
--
Yarden Katz <····@underlevel.net> | Mind the gap
Yarden Katz wrote:
> Raymond Wiker <·············@fast.no> writes:
>
>
>> On the other hand, blacksmiths and typesetters were replaced
>>by combinations of people and machines that were capable of building
>>better, faster and cheaper. Doesn't this sound like a case for
>>replacing C++/Java/whatever people with Lisp people :-?
>
>
> I am a bit disturbed by the type of advocacy for Lisp presented in
> this thread, and in other threads about Lisp vs. Other Languages. I
> find this analogous to an ad for fancy basketball shoes that promise
> to make me dunk like Michael Jordan.
the quotation above at any rate does not say "it's the shoes!!". don't
know what other threads you are referring to.
that quote just says that Lisp people (combo of people and machines)
will outchop even a Paul Bunyan using Java.
and I think the quotation presumes competency in Lisp, while you concede
you are a rookie programmer, never mind rookie Lisper.
otherwise I agree with you. :) Lisp would be wasted on most programmers.
hell, I worked with a guy who cut and pasted instead of making a
subroutine.
but (here I go again) I would not go so far as to say one has to be
gifted to excel with Lisp, just solid. that eliminates 80-90% of the
programmers out there, but it does not make those of us who use Lisp
effectively into superstars.
but the combo of a solid engineer and Lisp does have us dunking from the
foul line compared to folks using lesser sneakers.
> I can confidently claim that most competent Lisp programmers
> (*especially* the regulars on this newsgroup) are above and beyond
> most C++, Java, Perl programmers when it comes to programming,
Agreed, but it is not hard to be better than most programmers.
> But let's be frank guys, it's probably
> 90% because of your abilities and only 10% due to Lisp's elegance and
> facilities.
This must be wrong. Lisp has better people only because it is so much
better that good people find their way to it and once there won't let go
of it. If Lisp were only 10% better than Java or C you would not see
such a disproportionate number of strong people using it, they would be
evenly distributed amongst the 90% solutions and Lisp would be dead,
because "10% better" does not keep you alive once your market share is,
well, negliligible by some measures such as job openings.
If I had to put a number on Lisp's superiority I would start at an order
of magnitude, back down to maybe 500% in the face of the howls of derision.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
Kenny Tilton <·······@nyc.rr.com> writes:
> Agreed, but it is not hard to be better than most programmers.
Most programmers would disagree with that.
--
Pekka P. Pirinen
The power of accurate observation is frequently called cynicism by
those who don't have it. - George Bernard Shaw
···············@globalgraphics.com (Pekka P. Pirinen) writes:
> Kenny Tilton <·······@nyc.rr.com> writes:
> > Agreed, but it is not hard to be better than most programmers.
>
> Most programmers would disagree with that.
But the question is: are they right?
At my last job there were two technical groups that I was familiar
with, engineering and IT. The main focus for IT was not getting
blamed for anything. They had meetings just to make sure that
everyone knew the party line and stuck to it, before they went to the
real meeting. There was massive office politics going on with them
also. All this wast came about from fear, everyone over there was
afraid of being blamed. Now in engineering was a nice place to work.
When I made a mistake I just fixed it accepted responsibility for it
and got on with my job.
I think the fundamental difference was in engineering everyone knew
they were competent, at all levels. And that IT knew they were not
competent at all levels. So the groups in IT tried to make other
groups look bad because they believed that they could not look good on
there own merits.
marc
ps I think your sig also applies to Kenny's comment.
> --
> Pekka P. Pirinen
> The power of accurate observation is frequently called cynicism by
> those who don't have it. - George Bernard Shaw
Pekka P. Pirinen wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>>Agreed, but it is not hard to be better than most programmers.
>
>
> Most programmers would disagree with that.
The sad thing is that they would not. Most programmers would not even
pretend that they were serious about the craft. They would freely admit
they got into it just for the career path. That is why they suck,
because they do not love it. That is why it is easy to be better than
them, you just have to love programming. You do not have to be a genius,
you just have to want to program well.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
Kenny Tilton <·······@nyc.rr.com> writes:
> Pekka P. Pirinen wrote:
> > Kenny Tilton <·······@nyc.rr.com> writes:
> >
> >>Agreed, but it is not hard to be better than most programmers.
> >
> >
> > Most programmers would disagree with that.
>
> The sad thing is that they would not. Most programmers would not even
> pretend that they were serious about the craft. They would freely admit
> they got into it just for the career path. That is why they suck,
> because they do not love it. That is why it is easy to be better than
> them, you just have to love programming. You do not have to be a genius,
> you just have to want to program well.
I just finished reading _The Practice of Programming_, by Kernighan
and Pike, after having had it recommended to me for the 1000'th time.
It's a really good book, and I would highly recommend it to anyone
working in a C/Unix, C++, etc., environment. While I found it
enjoyable, and I did probably get a little something from it, mostly I
just read it for fun, and didn't learn anything. Not because I'm a
super-genius, but exactly because I'm the type of person to read a
book like _The Practice of Programming_. The people who could really
benefit from books like this, the ones who, if they followed its
recommendations, would produce code an order of magnitude better --
they're exactly the people who probably won't read it. They produce
such lousy code because they don't think it matters.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Yarden Katz <····@underlevel.net> writes:
> I can confidently claim that most competent Lisp programmers
> (*especially* the regulars on this newsgroup) are above and beyond
> most C++, Java, Perl programmers when it comes to programming,
> abstract thinking, and problem-solving knowledge in general. I think
> that this is constantly overlooked by Lisp advocators on this group.
> When people like Wiker, Pitman, Naggum, Gat and others use Lisp, it is
> perfectly reasonable to make those fantastic claims about Lisp's
> efficiency, power and so on. But let's be frank guys, it's probably
> 90% because of your abilities and only 10% due to Lisp's elegance and
> facilities.
I'm most definitely *not* anywhere near in the same class as
Pitman, Naggum and Gat (and quite a few others).
That said, even if I'm just dabbling in Lisp, it is quite
clear to me that I can write working code faster in Lisp, and with a
bit of work, it may even be faster code. FWIW, the alternatives (for
me) are C, C++ and Python, with occasional excursions into Perl and
shell programming.
--
Raymond Wiker Mail: ·············@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
In article <··············@underlevel.net>, Yarden Katz
<····@underlevel.net> wrote:
> I can confidently claim that most competent Lisp programmers
> (*especially* the regulars on this newsgroup) are above and beyond
> most C++, Java, Perl programmers when it comes to programming,
> abstract thinking, and problem-solving knowledge in general. I think
> that this is constantly overlooked by Lisp advocators on this group.
> When people like Wiker, Pitman, Naggum, Gat and others use Lisp, it is
> perfectly reasonable to make those fantastic claims about Lisp's
> efficiency, power and so on. But let's be frank guys, it's probably
> 90% because of your abilities and only 10% due to Lisp's elegance and
> facilities.
Well, I'm flattered, but how can you make that claim so confidently when
you've never met me?
I think I'm actually a mediocre programmer, which is precisely why I get
so much leverage out of Lisp. Lisp is essentially a library of very
sophisticated programming tools that are packaged up in an
easy-to-understand and easy-to-use API. In fact, the API is so easy to
use that it's not immediately apparent just how sophisticated the tools
are that lie behind it.
I think my main strength is not that I'm a good programmer but that I have
a pretty good bullshit filter. I can cut through the buzzwordy crap that
surrounds most software technology, understand the core idea, and evaluate
its merits. That ability let me recognize Lisp early on for what it was:
a huge programming lever, and I used it to leverage a (so far) successful
career. But it's not because I'm a good programmer, it's because I didn't
have to waste time understanding things like memory management and how to
use gdb to debug a core dump.
There are good programmers out there, but one of the things that
characterizes them is that they are pretty much equally comfortable in any
language. Bruno Haible, for example, is to me one of the towering figures
in the Lisp world for having created CLisp, but he's actually a C and C++
programmer (and an awesomely good one too). His code Just Works. It
takes me ten minutes to understand how to use it, and months of struggle
to understand how he did it. But they key is: I don't *have* to
understand how he did it in order to make good use of it.
> So yes, Lisp can make you fly like Michael Jordan (or code like Donald
> Knuth), *IF* you're capable of understanding it enough to fully
> utilize its advantages over other languages. This, in my mind,
> requires a lot of capability that few people in the programming
> community in general have. That's why Lisp programmers are in the
> minority.
No, you've got it exactly backwards. Lisp allows you to fly like Michael
Jordan precisely because it does *not* require you to understand it fully
in order to use it effectively.
E.
--
The opinions expressed here are my own and do not necessarily
reflect the views of JPL or NASA.
···@jpl.nasa.gov (Erann Gat) writes:
> No, you've got it exactly backwards. Lisp allows you to fly like Michael
> Jordan precisely because it does *not* require you to understand it fully
> in order to use it effectively.
This is consistent with this quotation of A.N. Whitehead:
It is a profoundly erroneous truism, repeated by all copy-books and
by eminent people when they are making speeches, that we should cultivate
the habit of thinking about what we are doing. The precise opposite is the
case. Civilization advances by extending the numbers of important operations
which we can perform without thinking about them. Operations of thought are
like cavalry charges in battle -- they are strictly limited in number, they
require fresh horses, and must only be made at decisive moments.
[ Fran�ois-Ren� �VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[ TUNES project for a Free Reflective Computing System | http://tunes.org ]
/let theory guide your observations/, but till your reputation is well
established, be sparing in publishing theory. It makes persons doubt your
observations. -- Charles Darwin to a young botanist
[Speaking crudely, not precisely:]
About:
So yes, Lisp can make you fly like Michael Jordan (or code
like Donald Knuth), *IF* you're capable of understanding it
enough to fully utilize its advantages over other languages.
This, in my mind, requires a lot of capability that few people
in the programming community in general have. That's why Lisp
programmers are in the minority.
and
> But let's be frank guys, it's probably 90% because of your
> abilities and only 10% due to Lisp's elegance and
> facilities.
This must be wrong. Lisp has better people only because it is
so much better that good people find their way to it and once
there won't let go of it. If Lisp were only 10% better than
Java or C you would not see such a disproportionate number of
strong people using it, they would be evenly distributed
amongst the 90% solutions and Lisp would be dead, because "10%
better" does not keep you alive once your market share is,
well, negliligible by some measures such as job openings.
I have a slightly different perspective, that I suspect is shared.
Lisp (in a broad sense) is not an accident. It's a fundamental.
Compressed into the design of lisp is a lot of wisdom about computing
in general. When you learn lisp, and see some examples of how it's
applied by good lisp programmers, really -- you're learning a lot of
deep, hard-to-articulate-directly truths about computing.
It isn't simply that "good programmers migrate to lisp" -- it's also
that "lisp intrinsicly helps people become good programmers".
Lisp programmers aren't in the minority because the skills to use lisp
well are a rarity -- lisp programmers are in the minority because the
economy is dominated by (effectively, regardless of their intentions)
shortsighted, irrationally selfish idiots.
Some well-placed people like to sell crap they don't really
understand, and they were either born with the right social
connections to make that happen, or attracted the repressed sexual
attraction of those born with those connections. Their standards for
_some_ of the finer things in life (cars, wine, boats) may be high
(though not a few fake that) -- but their standards for quality in
computing systems are low. But there are so few of these well-place
people, and it's such an exclusive club, and the sufficient capital
needed to mount a challenge via engineering sufficiently large, that
they get away with it in a masturbatatory hermeneutic of glad-handing.
And then economists come along, put on blinders, and analyze the
exclusive poker game those folks are playing, discover that the
players aren't completely irrational within the context of that stupid
game, and say "We can explain all this" -- but they never get around
to explaining the exclusivity.
Quality _can_ sell, but there's a customer education speed-bump to get
past first. Meanwhile, civilization falls apart.
"You are not expected to understand this."
-t
Tom Lord wrote:
> About:
>
>> So yes, Lisp can make you fly like Michael Jordan (or code
>> like Donald Knuth), *IF* you're capable of understanding it
>> enough to fully utilize its advantages over other languages.
[...]
> Lisp programmers aren't in the minority because the skills to use lisp
> well are a rarity -- lisp programmers are in the minority because the
> economy is dominated by (effectively, regardless of their intentions)
> shortsighted, irrationally selfish idiots.
The other reason why Lisp is often not used in industry is that sometimes it
is not rational to do so. Donald Knuth is _not_ a "shortsighted,
irrationally selfish idiot", and he wrote TeX in C, not in Lisp. This was
a good decision (esp. at the time when TeX started).
After Common Lisp was standardized (because of market pressure, by the way),
many bright people realized that while CL probably was "the best Lisp for
now" the language design had issues [1] and sometime in the future there
would be a next Lisp with more modular design, better interfacing with
non-Lisp-Machine OS, etc.
Today, people stop thinking about how to make Lisp (even) better. Instead
they call not-Lisp-users idiots. While this is far simpler and more funny,
it is not helpful.
Matthias
[1] See Richard P. Gabriel's "A Critique of Common Lisp" (1984), "Good News
Bad News How To Win Big" (19??), Steele and Gabriel "The Evolution of Lisp"
(1993), also Jeff Dalton's "Common Lisp Pitfalls" (posted to usenet 1995).
* Matthias Heiler wrote:
> The other reason why Lisp is often not used in industry is that sometimes it
> is not rational to do so. Donald Knuth is _not_ a "shortsighted,
> irrationally selfish idiot", and he wrote TeX in C, not in Lisp. This was
> a good decision (esp. at the time when TeX started).
Umm, no he didn't. He wrote it in Web, which was Pascal-based. Well,
it's based precisely on the dialect of Pascal that ran on SAIL at the
time. It's in one big source file because Pascal can't do separate
compilation. For a long time TeX couldn't really hack European
languages (that's not `international' that's `not American') because
it was really 7-bit not 8-bit, so didn't have room in its character
set for accented characters.
I think you've just blown your whole leg off.
--tim
Tim Bradshaw wrote:
> * Matthias Heiler wrote:
>
>> The other reason why Lisp is often not used in industry is that sometimes
>> it
>> is not rational to do so. Donald Knuth is _not_ a "shortsighted,
>> irrationally selfish idiot", and he wrote TeX in C, not in Lisp. This
>> was a good decision (esp. at the time when TeX started).
>
> Umm, no he didn't. He wrote it in Web, which was Pascal-based. Well,
> it's based precisely on the dialect of Pascal that ran on SAIL at the
> time. It's in one big source file because Pascal can't do separate
> compilation. For a long time TeX couldn't really hack European
> languages (that's not `international' that's `not American') because
> it was really 7-bit not 8-bit, so didn't have room in its character
> set for accented characters.
>
> I think you've just blown your whole leg off.
No. Just replace "wrote" by "rewrote" in my original posting. If I googled
correctly, Knuth replaced Pascal by C in the late 80s/early 90s. At this
time we even had (not-yet-ansi) CL. And I still do not think Knuth is a
"shortsighted, irrationally selfish idiot".
The intention of my original post was twofold: (1) To make clear that it is
not useful to bash at other language users. (2) To point out that people
who participated in CL standardization at least at some point suggested
there should be a Lisp beyond CL.
Lisp is the best language family for building abstractions I know, and
building (on) abstractions is powerful. But there are a number of other
aspects contributing to productivity. And not in every one Common Lisp
looks best. Just ignoring that means not developing.
Matthias
Matthias Heiler wrote:
> Tim Bradshaw wrote:
>
>
>>* Matthias Heiler wrote:
>>
>>
>>>The other reason why Lisp is often not used in industry is that sometimes
>>>it
>>>is not rational to do so. Donald Knuth is _not_ a "shortsighted,
>>>irrationally selfish idiot", and he wrote TeX in C, not in Lisp. This
>>>was a good decision (esp. at the time when TeX started).
>>
>>Umm, no he didn't. He wrote it in Web, which was Pascal-based.
...snip...
>
>
> No. Just replace "wrote" by "rewrote" in my original posting. If I googled
> correctly, Knuth replaced Pascal by C in the late 80s/early 90s. At this
> time we even had (not-yet-ansi) CL. And I still do not think Knuth is a
> "shortsighted, irrationally selfish idiot".
Anybody got the Sorting volume of Knuth's Art of CP series?
I recall from somewhere[*] very early (preface? forward? intro?) him
pooh-poohing Lisp (not sure if by name), saying "it's not /that/ hard to
maintain a linked list".
That encouraged me to port my educational app from Logo to C, setting me
back about ten years until someone turned me on to MCL. Thx, Don! :)
Anyway, he was wrong, machine language is not the equivalent of Lisp, so
I would not consider it a feather in any language's cap that The Donald
chose to use it.
[*] I'd look for the citation myself, but the book got tossed recently
along with a bunch of VB books I got when... well, different story.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
Kenny Tilton wrote:
> Anybody got the Sorting volume of Knuth's Art of CP series?
May have been the Fundamental Algorithms volume, I had both.
>
> I recall from somewhere[*] very early (preface? forward? intro?) him
> pooh-poohing Lisp (not sure if by name), saying "it's not /that/ hard to
> maintain a linked list".
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
"Kenny Tilton" <·······@nyc.rr.com> wrote in message ·····················@nyc.rr.com...
>
>
> Kenny Tilton wrote:
> > Anybody got the Sorting volume of Knuth's Art of CP series?
>
> May have been the Fundamental Algorithms volume, I had both.
>
> >
> > I recall from somewhere[*] very early (preface? forward? intro?) him
> > pooh-poohing Lisp (not sure if by name), saying "it's not /that/ hard to
> > maintain a linked list".
>
Hmm..
Much of the material we will discuss is often called "List processing,"
since a number of programming systems such as LISP have been designed
to facilitate working with general kinds of structures called Lists.
...
Although List processing systems are useful in a large number of situations,
they impose constraints on the programmer that are often unnecessary; it is
usually better to use the methods of this chapter directly in one's own
programs, tailoring the data format and the processing algorithms to the
particular application. Many people unfortunately still feel that List
processing techniques are quite complicated (so that it is necessary to
use someone else's carefully written interpretive system or a prefabricated
set of subroutines), and that List processing must be done only in a certain
fixed way.
...
-D.E.Knuth, TACP vol 1, Fundamental Algorithms
Chapter 2, Information Structures, 6th paragraph.
What a memory, it really must have irked you. :-)
Although Lisp is his chosen whipping boy, it is true a lot of programmers
jump through hoops fitting data to a container they know how to use rather
than finding and learning to use a more appropriate one, let alone implementing
it. Look at all the fixed-length buffer overruns that still occur in C/C++
programs just because an array is 'easier'.
--
Geoff
In article <·····················@news20.bellglobal.com>, "Geoffrey
Summerhayes" <·············@hotmail.com> wrote:
> Much of the material we will discuss is often called "List processing,"
> since a number of programming systems such as LISP have been designed
> to facilitate working with general kinds of structures called Lists.
> ...
> Although List processing systems are useful in a large number of
situations,
> they impose constraints on the programmer that are often
unnecessary; it is
> usually better to use the methods of this chapter directly in one's own
> programs, tailoring the data format and the processing algorithms to the
> particular application. Many people unfortunately still feel that List
> processing techniques are quite complicated (so that it is necessary to
> use someone else's carefully written interpretive system or a
prefabricated
> set of subroutines), and that List processing must be done only in a
certain
> fixed way.
> ...
>
>
> -D.E.Knuth, TACP vol 1, Fundamental Algorithms
> Chapter 2, Information Structures, 6th paragraph.
>
> What a memory, it really must have irked you. :-)
>
> Although Lisp is his chosen whipping boy, it is true a lot of programmers
> jump through hoops fitting data to a container they know how to use rather
> than finding and learning to use a more appropriate one, let alone
implementing
> it. Look at all the fixed-length buffer overruns that still occur in C/C++
> programs just because an array is 'easier'.
With the utmost respect and humility I submit that you and Knuth both have
it wrong.
There aren't that many different kinds of data structures. Probably a
dozen or so cover 99% of useful cases. Furthermore, the number of
abstract interfaces to those data structures is even smaller. An
"associative map" probably covers more than half of them. (Note that
"vector" is a special case of associative map where the keys are a dense
range of integers.)
Now, implementing those dozen data structures properly is not easy, but
there's no reason on earth why programmers should be doing it over and
over and over and over. It's a complete waste of time. There is likewise
no reason for programmers to be implementing parsers over and over and
over and over. That is likewise a complete waste of time.
The reason Lisp is cool is that it packages up all the data structures you
need for 99% of programming tasks, together with a parser for a universal
syntax that allows you to represent instances of all those data
structures, including code (which in Lisp is just another data
structure). So Lisp programmers rarely write parsers, and rarely write
data structures. C programmers hardly do anything else. This is why even
a mediocre programmer like me can appear to be very capable when using
Lisp, because I start from a baseline that C programmers only achieve
after significant effort. I can do things in Lisp that absolutely knocks
the socks off C programmers -- like redefine a class in a running
program. The ability to do this in C++ would be considered a major
breakthrough. What's more, I can do things like this in Lisp with
LITERALLY ZERO EFFORT! What's more, this is all fifteen year old
technology!
Let's look again at Knuth's claim:
"it is usually better to use the methods of this chapter directly in one's
own programs, tailoring the data format and the processing algorithms to
the particular application."
And the support for this claim is:
"Many people unfortunately still feel that List processing techniques are
quite complicated (so that it is necessary to use someone else's carefully
written interpretive system or a prefabricated set of subroutines), and
that List processing must be done only in a certain fixed way."
In other words, you should write your own data structures (and not use
Lisp) because writing your own data structures is not as hard as you
think.
But that's a completely vacuous argument. It doesn't matter if it's not
as hard as you think, it still has a non-zero cost. That's like saying
that if you want a radio you should wind your own inductors because it's
not as hard as you think. Maybe, maybe not. Doesn't matter. Even if
it's not as hard as I think to wind an inductor, it's still easier to just
go to Circuit City and buy a radio.
E.
--
The opinions expressed here are my own and do not necessarily
reflect the views of JPL or NASA.
Geoffrey Summerhayes wrote:
> What a memory, ...
yeah, wow.
> ...it really must have irked you. :-)
actually, his words came as salvation, which is why they stuck. I had
prototyped this cool app in MS (!) Logo but had reached its limits.
ExperLisp invariably crashed my Mac in about three minutes of use. There
may have been alternatives (Coral? Which became MCL? Not sure of my
history) but I did not know of them--not even sure if I was using
CompuServe then, and I don't think anyone was using the Web yet, so I
might well have missed a Lisp implementation (I was all Mac all the time
then)...
I knew I wanted to stick with the Lisp family because while prototyping
the app I did feel like i was an order of magnitude more productive. It
was astonishing how much I could do in how little time, with so little
code. So i was trapped. No fast Lisp, so no powerful development tool.
Enter Knuth with words of blessing on switching to C (or ASM for that
matter). "Yeah!", I thought. "I can maintain a list!" And off I went to
order Lightspeed C.
You know, it's funny this has come up, I am have been talking about
doing CeX, a Cell-powered TeX. Knuth took how long to do TeX?
:)
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
Kenny Tilton <·······@nyc.rr.com> writes:
> Kenny Tilton wrote:
> > Anybody got the Sorting volume of Knuth's Art of CP series?
>
> May have been the Fundamental Algorithms volume, I had both.
>
> > I recall from somewhere[*] very early (preface? forward? intro?) him
> > pooh-poohing Lisp (not sure if by name), saying "it's not /that/
> > hard to maintain a linked list".
>
I have the Russian translation. And I've found the saying you mentioned
in section 2.1 Introduction in chapter about informational structures.
But for an obvious reason I'm not going to put it here. :)
* Matthias Heiler wrote:
> No. Just replace "wrote" by "rewrote" in my original posting. If I
> googled correctly, Knuth replaced Pascal by C in the late 80s/early
> 90s. At this time we even had (not-yet-ansi) CL. And I still do
> not think Knuth is a "shortsighted, irrationally selfish idiot".
No, he didn't, TeX is still in web. The web is now typically
translated by web2c (instead of the original tangle) which generates C
from it rather than pascal. Knuth did not write web2c.
You're in danger of falling into the pit you are digging here. TeX
needs to be understood as a program Knuth wrote for his own use
(namely typesetting some books). It's written using a language /
system which was essentially developed for it, and is absolutely
riddled with weird limits and and artifacts of its time (all sorts of
things have strange hard limits, it can run out of memory in a
catastrophic way which can require recompilation to fix, and so on).
I don't think Knuth was shortsighted or selfish, but if he had been
writing TeX for general use he definitely would have been.
I don't necessarily disagree with the points you are trying to make,
but you have chosen almost the single worst example you could have
--tim
Matthias Heiler <······@nospam.de> writes:
> Tim Bradshaw wrote:
>
> > * Matthias Heiler wrote:
> >
> >> The other reason why Lisp is often not used in industry is that sometimes
> >> it
> >> is not rational to do so. Donald Knuth is _not_ a "shortsighted,
> >> irrationally selfish idiot", and he wrote TeX in C, not in Lisp. This
> >> was a good decision (esp. at the time when TeX started).
> >
> > Umm, no he didn't. He wrote it in Web, which was Pascal-based. Well,
> > it's based precisely on the dialect of Pascal that ran on SAIL at the
> > time. It's in one big source file because Pascal can't do separate
> > compilation. For a long time TeX couldn't really hack European
> > languages (that's not `international' that's `not American') because
> > it was really 7-bit not 8-bit, so didn't have room in its character
> > set for accented characters.
> >
> > I think you've just blown your whole leg off.
>
> No. Just replace "wrote" by "rewrote" in my original posting. If I googled
> correctly, Knuth replaced Pascal by C in the late 80s/early 90s. At this
> time we even had (not-yet-ansi) CL. And I still do not think Knuth is a
> "shortsighted, irrationally selfish idiot".
At least around 1993, TeX was still written in Web, but fed through a
web2c compiler, written in (probably) the most hard-to-read C I've had
the misfortune to look through. Haven't tried building TeX from source
since, so I can't comment on how it's distributed these days.
//Ingvar
--
When it doesn't work, it's because you did something wrong.
Try to do it the right way, instead.
On Wed, 26 Mar 2003 15:27:55 +0100, Matthias Heiler <······@nospam.de>
wrote:
> No. Just replace "wrote" by "rewrote" in my original posting. If I googled
> correctly, Knuth replaced Pascal by C in the late 80s/early 90s. At this
Can you provide your references? I seem to understand that Pascal to C
translators were developed in order to port TeX to C-based systems, but the
master sources is still the WEB one.
Paolo
--
Paolo Amoroso <·······@mclink.it>
On 2003-03-26, Paolo Amoroso <·······@mclink.it> wrote:
>> No. Just replace "wrote" by "rewrote" in my original posting. If
>> I googled correctly, Knuth replaced Pascal by C in the late
>> 80s/early 90s. At this
>
> Can you provide your references? I seem to understand that Pascal to C
> translators were developed in order to port TeX to C-based systems, but the
> master sources is still the WEB one.
I can't provide an exact reference, but I recently read the story of
Tex and it's development in one of the essays from the book Literate
Programming. The development of Tex was very well documented, as it
was a testbed for literate programming and documented development.
For what it's worth, I seem to remember that Knuth wrote Tex in Pascal
using WEB, with one of his students or some other contributor doing
the rewrite to C after initial development was (mostly) finished.
--
burton samograd
······@hotmail.com
http://kruhftwerk.dydns.org
* Burton Samograd wrote:
> For what it's worth, I seem to remember that Knuth wrote Tex in Pascal
> using WEB, with one of his students or some other contributor doing
> the rewrite to C after initial development was (mostly) finished.
Repeat after me: TeX has not been reimplemented in C. How many times
do people have to say this to you?
Perhaps this will convince you:
% This program is copyright (C) 1982 by D. E. Knuth; all rights are reserved.
% Copying of this file is authorized only if (1) you are D. E. Knuth, or if
% (2) you make absolutely no changes to your copy. (The WEB system provides
% for alterations via an auxiliary file; the master file should stay intact.)
% See Appendix H of the WEB manual for hints on how to install this program.
% And see Appendix A of the TRIP manual for details about how to validate it.
% TeX is a trademark of the American Mathematical Society.
% METAFONT is a trademark of Addison-Wesley Publishing Company.
% Version 0 was released in September 1982 after it passed a variety of tests.
% Version 1 was released in November 1983 after thorough testing.
% Version 1.1 fixed ``disappearing font identifiers'' et alia (July 1984).
% Version 1.2 allowed `0' in response to an error, et alia (October 1984).
% Version 1.3 made memory allocation more flexible and local (November 1984).
% Version 1.4 fixed accents right after line breaks, et alia (April 1985).
% Version 1.5 fixed \the\toks after other expansion in \edefs (August 1985).
% Version 2.0 (almost identical to 1.5) corresponds to "Volume B" (April 1986).
% Version 2.1 corrected anomalies in discretionary breaks (January 1987).
% Version 2.2 corrected "(Please type...)" with null \endlinechar (April 1987).
% Version 2.3 avoided incomplete page in premature termination (August 1987).
% Version 2.4 fixed \noaligned rules in indented displays (August 1987).
% Version 2.5 saved cur_order when expanding tokens (September 1987).
% Version 2.6 added 10sp slop when shipping leaders (November 1987).
% Version 2.7 improved rounding of negative-width characters (November 1987).
% Version 2.8 fixed weird bug if no \patterns are used (December 1987).
% Version 2.9 made \csname\endcsname's "relax" local (December 1987).
% Version 2.91 fixed \outer\def\a0{}\a\a bug (April 1988).
% Version 2.92 fixed \patterns, also file names with complex macros (May 1988).
% Version 2.93 fixed negative halving in allocator when mem_min<0 (June 1988).
% Version 2.94 kept open_log_file from calling fatal_error (November 1988).
% Version 2.95 solved that problem a better way (December 1988).
% Version 2.96 corrected bug in "Infinite shrinkage" recovery (January 1989).
% Version 2.97 corrected blunder in creating 2.95 (February 1989).
% Version 2.98 omitted save_for_after at outer level (March 1989).
% Version 2.99 caught $$\begingroup\halign..$$ (June 1989).
% Version 2.991 caught .5\ifdim.6... (June 1989).
% Version 2.992 introduced major changes for 8-bit extensions (September 1989).
% Version 2.993 fixed a save_stack synchronization bug et alia (December 1989).
% Version 3.0 fixed unusual displays; was more \output robust (March 1990).
% Version 3.1 fixed nullfont, disabled \write{\the\prevgraf} (September 1990).
% Version 3.14 fixed unprintable font names and corrected typos (March 1991).
% Version 3.141 more of same; reconstituted ligatures better (March 1992).
% Version 3.1415 preserved nonexplicit kerns, tidied up (February 1993).
% Version 3.14159 allowed fontmemsize to change; bulletproofing (March 1995).
% Minor corrections to the documentation (only) were made in July 2001.
% A reward of $327.68 will be paid to the first finder of any remaining bug.
% Although considerable effort has been expended to make the TeX program
% correct and reliable, no warranty is implied; the author disclaims any
% obligation or liability for damages, including but not limited to
% special, indirect, or consequential damages arising out of or in
% connection with the use or performance of this software. This work has
% been a ``labor of love'' and the author hopes that users enjoy it.
Alain Picard <·······················@optushome.com.au> writes:
> Nice try. However, Knuth wrote TeX in Pascal, not C.
> Perhaps he _should_ have used lisp, then he wouldn't have
> had to re-implement it?
Well, at that time lisp was less of an obvious choice than it is
today. This is something which is causing a lot of confusion: Lisp is
an old language, it is argued, so how come it hasn't succeeded yet?
But it's only very recently that it has become as usable for general
purpose programming on stock hardware as it is today! (MCL was ahead
of its time as being usable on general-purpose hardware with limited
resources, but it only covered the mac market, and in addition its
runtime licensing fees were probably problematic for some developers)
--
(espen)
[a little ramble]
> Lisp programmers aren't in the minority because the skills
> to use lisp well are a rarity -- lisp programmers are in the
> minority because the economy is dominated by (effectively,
> regardless of their intentions) shortsighted, irrationally
> selfish idiots.
The other reason why Lisp is often not used in industry is
that sometimes it is not rational to do so. Donald Knuth is
_not_ a "shortsighted, irrationally selfish idiot", and he
wrote TeX in C, not in Lisp. This was a good decision
(esp. at the time when TeX started).
I agree about Donald Knuth (others have "fixed you" about the history
and nature of TeX). In fact, I think you'd be hard pressed to find
any individual in the industry to whom such a simple-minded string of
name-calling really applies (hence, "effectively, regardless of their
intentions"). Rather, I think it's (mostly) an emergent property of
our collective behavior. If you want to know what strategic
technology choices a big software company is going to make over the
next five years (and those choices are almost never the work of any
one person -- it's "what the group does"), you can ask yourself "What
would a shortsighted, irrationally selfish idiot do if put in
control?" and you will achieve better-than-random success in your
predictions.
I attribute that to (a) the relatively poor quality of human knowledge
about programming at this point in history; (b) the segregation of
economic decision makers from practitioners of the craft of
programming. The decision makers have no "feel" for the field -- so
they follow gradients of short-term and short-sighted "success",
ultimately climbing out on thin-and-cracking limbs when all they
wanted is to snatch some fruit. They're bakers who have no intuition
for the relationship between the springiness of a wad of dough and the
state of the gluten molecules it contains. They're candy makers who
can't tell by inspection the state of a sugar syrup being reduced to
the hard-crack stage. They're mechanics to whom the healthy chevy
and the one needing a valve job in 3 months both sound like nothing
more than "loud engines". They're wrapped up snug in a discoursive
field that protects them from perceiving these shortcomings. (One way
to break down such fields is, of course, the "shock comedian" role --
the obnoxious schmuck who says the most offensive things but never
quite in a simple-minded way.)
In some other engineering industries, you can make up for similar
short-falls with, say, a peer-reviewed study of the size and nature of
oil reserves in Alaska -- but in programming, all we've got is
anecdotes from a minority population, unproven and unscientific
speculations about why we all think the same way, and a few isolated
examples of obviously winning programs. We _know_ we're right -- but
we're right about such esoteric and intangible phenomena that there
doesn't exist a suitable vocabulary and rhetoric for communicating
that to non-programmer people who don't already know the same things.
When I was a "pre-professional" programmer, still in the early stages
of learning, I remember that the school's labs were stratified. There
were those who cranked endless variations on the same old tired
function-plotter -- and there were those who went off to make complete
implementations of forth-based programming environments. Five years
later, the forth guys had systems that made them 100x more productive
and fluidly creative than the function-plotter wankers -- but at the
time, to the casual observer, it was the pretty-pictures-guys vs. the
guys getting excited that they got backspace to work in the line
editor. In the professional industry, the function-plotter wankers
(whose economic value I acknowledge) take the day (then get laid off
and then replaced by younger wankers), while the forth-guys get the
boot. Surely a "winner takes all" game isn't the right strategy here.
After Common Lisp was standardized (because of market
pressure, by the way), many bright people realized that while
CL probably was "the best Lisp for now" the language design
had issues [1] and sometime in the future there would be a
next Lisp with more modular design, better interfacing with
non-Lisp-Machine OS, etc.
[....]
[1] See Richard P. Gabriel's [...] "Good News Bad News How To
Win Big" (19??),
The web says "published in 1991". I _think_ I recall seeing a
privately circulated draft a couple of years earlier than that -- but
it was a long time ago.
And that's part of the point: it was a long time ago. We've all known
some good directions to go for more than a decade. I think that in
that period of time, had their been some modest but sustained
strategic investment in "new lisp", it would by now be paying off
handsomely. It's (impersonally) idiotically shortsighted and
irrationally selfish that that kind of investment can't be mounted.
You say "many bright people realized" and I agree with that. Very
few if any of those bright people have the capital or corporate power
to do anything about it. That scares me, a bit. It suggests that
economic power in the software industry is out of control. Give a
300lb gorrilla a high power rifle and he'll figure out that it's a
nice tool for poking at things -- but eventually somebody's going to
get hurt.
The intention of my original post was twofold: (1) To make
clear that it is not useful to bash at other language users.
(2) To point out that people who participated in CL
standardization at least at some point suggested there should
be a Lisp beyond CL.
Re (1): I think it's simple-minded and unkind to read people on this
list as bashing programmers who work in other languages. Yes, you
often see brutally frank assesments of their average skill level and
average depth-of-understanding -- but that's more about the training
process and rewarded career paths and low product quality expectations
than about the inherent capabilities of individuals.
Re (2): And there _still_ should. The lisp community as I've
witnessed it isn't at all innocent in all this. The spark in language
design that happened around the time of (not nearly entirely by) the
rabbit thesis ignited a huge conflagration in the late 80s and early
90s. Lispers saw lots of very sophisticated tricks that, in theory,
added up to amazingly powerful (almost magical) programming
environments but there wasn't nearly enough appreciation of "small is
beautiful" and similar deeply practical aesthetics. There have been
some exceptions -- my favorite is GNU Emacs. In spite of a reputation
for bloat, in retrospect, it's a stunningly tight design characterized
by putting on binders of very strict practical constraints -- then
doing as much as can be done within those constraints.
-t
On Wed, 26 Mar 2003 22:25:55 -0000, ····@emf.emf.net (Tom Lord) wrote:
> [1] See Richard P. Gabriel's [...] "Good News Bad News How To
> Win Big" (19??),
>
> The web says "published in 1991". I _think_ I recall seeing a
> privately circulated draft a couple of years earlier than that -- but
> it was a long time ago.
You may have seen the draft circulated by none else than JWZ.
Paolo
--
Paolo Amoroso <·······@mclink.it>
> [1] See Richard P. Gabriel's [...] "Good News Bad
> News How To Win Big" (19??),
>
> The web says "published in 1991". I _think_ I recall seeing
> a privately circulated draft a couple of years earlier than
> that -- but it was a long time ago.
You may have seen the draft circulated by none else than JWZ.
Thanks for the evidence that my memory isn't completely hosed.
JWZ was a grad student at the same university where I was an MTS on a
local research project. I didn't get it from JWZ -- I did get it from
a guy with close ties to the dept. What I thought I remembered, and
what your memory suggests I do remember, is a small crowd of us
gathered around the draft and being fairly excited about it.
I also remember that JWZ could throw a pretty hip party when he wanted
to -- which makes his current career path pretty unsurprising.
-t
In article <··············@corp.supernews.com>, ····@emf.emf.net (Tom
Lord) wrote:
> JWZ
Who is JWZ?
E.
--
The opinions expressed here are my own and do not necessarily
reflect the views of JPL or NASA.
In article <··············@bird.agharta.de>, ···@agharta.de wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > Who is JWZ?
>
> <http://www.google.com/search?q=jwz>
>
> Try the first match... :)
Heh. I actually tried the acronym glossary at Google labs and it didn't
come up with anything. That'll teach me to overlook the obvious. Duh!
E.
--
The opinions expressed here are my own and do not necessarily
reflect the views of JPL or NASA.
In article <··············@bird.agharta.de>, Edi Weitz <···@agharta.de>
wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > Who is JWZ?
>
> <http://www.google.com/search?q=jwz>
>
> Try the first match... :)
Or the second, or the third, or the fourth...
I find that when someone is well-known enough for their initials to be
thrown around without explanation that google will usually know about
them -- certainly works for JWZ and RMS and ESR though unfortunately not
for DEK...
-- Bruce
On Thu, 27 Mar 2003 18:00:36 -0000, ····@emf.emf.net (Tom Lord) wrote:
> > [1] See Richard P. Gabriel's [...] "Good News Bad
> > News How To Win Big" (19??),
[...]
> a guy with close ties to the dept. What I thought I remembered, and
> what your memory suggests I do remember, is a small crowd of us
> gathered around the draft and being fairly excited about it.
Gabriel's site provides some information and historical perspective on the
paper:
http://www.dreamsongs.com/WorseIsBetter.html
Paolo
--
Paolo Amoroso <·······@mclink.it>
····@emf.emf.net (Tom Lord) writes:
> > [1] See Richard P. Gabriel's [...] "Good News Bad
> > News How To Win Big" (19??),
> >
> > The web says "published in 1991". I _think_ I recall seeing
> > a privately circulated draft a couple of years earlier than
> > that -- but it was a long time ago.
>
> You may have seen the draft circulated by none else than JWZ.
>
>
> Thanks for the evidence that my memory isn't completely hosed.
>
> JWZ was a grad student at the same university where I was an MTS on a
> local research project. I didn't get it from JWZ -- I did get it from
> a guy with close ties to the dept. What I thought I remembered, and
> what your memory suggests I do remember, is a small crowd of us
> gathered around the draft and being fairly excited about it.
According to the widespread hype JWZ was hired straight out of
highschool. Did he actually pursue a higher education later?
--
Yarden Katz <····@underlevel.net> | Mind the gap
According to the widespread hype JWZ was hired straight out of
highschool. Did he actually pursue a higher education later?
I am informed that no, he did not.
It was an assumption on my part based on the heuristic "young looking;
smart; hangs out in CS and related places."
-t
Alain Picard <·······················@optushome.com.au> writes:
> Matthias Heiler <······@nospam.de> writes:
>
>> The other reason why Lisp is often not used in industry is that sometimes it
>> is not rational to do so. Donald Knuth is _not_ a "shortsighted,
>> irrationally selfish idiot", and he wrote TeX in C, not in Lisp. This was
>> a good decision (esp. at the time when TeX started).
>
> Nice try. However, Knuth wrote TeX in Pascal, not C.
> Perhaps he _should_ have used lisp, then he wouldn't have
> had to re-implement it?
Did Knuth ever comment on his language choice? It would seem only
natural for him to use Lisp for the job. Or at least reimplement TeX
in Lisp a few years later. It's a bit puzzling.
--
Yarden Katz <····@underlevel.net> | Mind the gap
From: Christopher C. Stacy
Subject: Re: Learning new things
Date:
Message-ID: <ud6kpakuq.fsf@dtpq.com>
>>>>> On Mon, 17 Mar 2003 07:52:56 -0800, Erann Gat ("Erann") writes:
Erann> In article <···············@shell01.TheWorld.com>, Kent M Pitman
Erann> <······@world.std.com> wrote:
>> Free software, in case you don't know, started with richard stallman
>> being sad that he wasn't going to be able to afford to be a programmer
>> any more because the complex weave of commercialism left him nowhere
>> to go that made him The plight of him and others like him plight used
>> to matter to me more until I found how little my plight mattered to
>> them. And in the end, the same problem exists.
Erann> I think something got inadvertantly snipped from that description, but it
Erann> doesn't seem entirely accurate. The definitive telling of the story can
Erann> be found at http://www.oreilly.com/openbook/freedom/
You might consider whether Richard Stallman would present his story a
little differently from the people who were there with him at the time.
In article <·············@dtpq.com>, ······@dtpq.com (Christopher C.
Stacy) wrote:
> >>>>> On Mon, 17 Mar 2003 07:52:56 -0800, Erann Gat ("Erann") writes:
>
> Erann> In article <···············@shell01.TheWorld.com>, Kent M Pitman
> Erann> <······@world.std.com> wrote:
>
> >> Free software, in case you don't know, started with richard stallman
> >> being sad that he wasn't going to be able to afford to be a programmer
> >> any more because the complex weave of commercialism left him nowhere
> >> to go that made him The plight of him and others like him plight used
> >> to matter to me more until I found how little my plight mattered to
> >> them. And in the end, the same problem exists.
>
> Erann> I think something got inadvertantly snipped from that
description, but it
> Erann> doesn't seem entirely accurate. The definitive telling of the
story can
> Erann> be found at http://www.oreilly.com/openbook/freedom/
>
> You might consider whether Richard Stallman would present his story a
> little differently from the people who were there with him at the time.
Of course. I have already retracted my characterization of this book as
"the definitive account." However, the pliability of memory applies
equally well to all observers, not just the principals, and the account in
the book contains historical details that could be independently verified
if one were inclined to do so.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <·············@dtpq.com>, ······@dtpq.com (Christopher C.
> Stacy) wrote:
>
> > >>>>> On Mon, 17 Mar 2003 07:52:56 -0800, Erann Gat ("Erann") writes:
> >
> > Erann> In article <···············@shell01.TheWorld.com>, Kent M Pitman
> > Erann> <······@world.std.com> wrote:
> >
> > >> Free software, in case you don't know, started with richard stallman
> > >> being sad that he wasn't going to be able to afford to be a programmer
> > >> any more because the complex weave of commercialism left him nowhere
> > >> to go that made him The plight of him and others like him plight used
> > >> to matter to me more until I found how little my plight mattered to
> > >> them. And in the end, the same problem exists.
> >
> > Erann> I think something got inadvertantly snipped from that
> description, but it
> > Erann> doesn't seem entirely accurate. The definitive telling of the
> story can
> > Erann> be found at http://www.oreilly.com/openbook/freedom/
> >
> > You might consider whether Richard Stallman would present his story a
> > little differently from the people who were there with him at the time.
>
> Of course. I have already retracted my characterization of this book as
> "the definitive account." However, the pliability of memory applies
> equally well to all observers, not just the principals, and the account in
> the book contains historical details that could be independently verified
> if one were inclined to do so.
You're assuming that mine can't.
My direct observations are idiosyncratic to me, but I believe that others
have had substantially similar interactions such that mine can be given
credence as well.
For example, I have had various in-person or telephone interchanges with
Stallman where we discussed his concerns about the fate of the programmer.
I am sure others have heard him give the same pitch.
Although they span decades (from the late 1970's), one of most memorable was
in 1994 when I was chairing the Lisp Users and Vendors Conference. He wanted
all expenses paid and we had a big discussion about this because he had won
the MacArthur award and he seemed to me to be better funded than the
conference. He complained to me (again--I'd heard it before, but not in this
dire or concrete a form, which is why this one is most memorable) that it was
getting harder and harder to ethically be a programmer. He said essentially
that patents, company confidentiality, and trade secrets were closing in from
all sides and that he was not sure he would ever be able to have gainful
employment again in his life, so this grant he got might be the only money
he ever saw for the rest of his life. The specifics of this
seemed exaggerated to me, but I took his general point and tried to get him
funding that would not disrupt his life nestegg.
This conversation was only with me and surely cannot be substantiated.
Nevertheless, he was not a "close friend", and it's unlikely that I was
uniquely positioned to hear this pitch. I have confidence that anyone
who has dealt with him in any conference-organizing capacity can confirm
the general substance of this posture on Stallman's part. Probably Stallman
himself would confirm it.
I have also had a later personal conversation with him where he called
me one day, unprompted, at my home to complain about the Common Lisp
HyperSpec not being free. I said certainly it was free and pointed to the
fact that it did not cost anyone to obtain it. He said that didn't count
as free. (For all he claims to be big on freedom, he apparently wants a
tight hold on others' terminology. Go figure.) We had a long conversation
in which he whined away that it wasn't useful to HIM. I said that it was
useful to other people and that I was happy about that, but my recollection
is (and I don't see any reason he would disagree) that this didn't impress him.
He wanted it on his terms or not at all, and seemed to want me to believe I'd
wasted my time on it if I hadn't enabled him in the way he wanted. I hadn't
made any campaign to make him want to use my document, mind you--this was
an unsolicited telephone call in which he was apparently trying to get me
to do things his way by making me feel bad about what I'd done. Not a
sales technique I found very persuasive. I told him he was welcome to go
make his own hyperspec, and he seemed to say he was going to go do that.
(I was, in fact, surprised later that he apparently didn't carry through.
I guess he's busy.) In the course of the conversation, Stallman seemed to
make it clear that he didn't care about "value to the world" but about his
own personal needs.
I don't think it would take much to document my claim that free software
advocates routinely tell me that the world sheds no tears at my plight as
a programmer who can't get paid for what he likes to do.
So there you have it. I've made the following claims, each of which seems
uncontroversial and I think could be independently verified:
- I think Stallman was sad that he wanted to program on certain terms
and felt he increasingly couldn't because of various reasons, largely
related to intellectual property closing in on him.
- I think Stallman expected people to care about his plight.
- I did care. That doesn't mean I bought into his agenda for how to
fix things lock, stock, and barrel. But I engaged discussion of
the problem.
- I have said I am sad that I want to program and that I feel increasingly
it's hard to be a programmer on certain terms, very similar to what
Stallman wanted, except that free software is the strong contributing
factor.
- I once naively expected that most people would care if I explained
the issue in the way that Stallman explained his concern.
- I found an alarming (to me) number of people who seemed to think
my concern was "just too bad" and not something anyone could care about.
Let me close with a quote from Stallman in his recent book,
Free Software, Free Society, pages 37-38:
rms| "Won't everyone stop programming without a monetary incentive?"
rms| Actually, many people will program with absolutely no monetary
rms| incentive. Programming has an irresistable fascination for some
rms| people, usually the people who are best at it. There is no shortage
rms| of professional musicians who keep at it even though they have no
rms| hope of making a living that way.
rms| ...
rms| What the facts show is that people will program for reasons other
rms| than riches;, but if given a chance to make a lot of money as well,
rms| they will come to expect and demand it. Low-paying organizations do
rms| poorly in competition with high-paying ones, but they do not have to
rms| do badly if the high-paying ones are banned.
I've gotta say, this is not my idea of Utopia. It seems to me a recipe,
pure and simple, for economically disempowering programmers and turning
them back into peasants. It amazes me that people rally to this kind of
rhetoric and say "yes, yes, that's the kind of world I want to live in".
(I also believe what he says is factually false. On average, people don't
"demand" high wages. High wages come to them when the market thinks it
will bear that. Sometimes someone gets lucky, or unlucky, but on the whole
the system will approach a fair price. Any notion that programmers are
getting away with something is a fantasy of his. His argument is very
analogous to saying "people have inherent desire for medical care, so you
might as well charge a lot for it." The tone suggests to me that the poor
defenseless companies everywhere are being held hostage to the mean,
powerful programmers, and that he is there to right the situation by
saving the powerful companies from this exploitation. But it seems to me
that he is openly advocating that companies exploit their workers by paying
them less and just hoping that human nature will result in programming
happening for free because employees can't help it. Now that, it seems to
me, is exploitation.)
Oh, right, I said I was closing. Ok. 'nuff said here.
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <·············@dtpq.com>, ······@dtpq.com (Christopher C.
> > Stacy) wrote:
> >
> > > >>>>> On Mon, 17 Mar 2003 07:52:56 -0800, Erann Gat ("Erann") writes:
> > >
> > > Erann> In article <···············@shell01.TheWorld.com>, Kent M Pitman
> > > Erann> <······@world.std.com> wrote:
> > >
> > > >> Free software, in case you don't know, started with richard stallman
> > > >> being sad that he wasn't going to be able to afford to be a programmer
> > > >> any more because the complex weave of commercialism left him nowhere
> > > >> to go that made him The plight of him and others like him plight used
> > > >> to matter to me more until I found how little my plight mattered to
> > > >> them. And in the end, the same problem exists.
> > >
> > > Erann> I think something got inadvertantly snipped from that
> > description, but it
> > > Erann> doesn't seem entirely accurate. The definitive telling of the
> > story can
> > > Erann> be found at http://www.oreilly.com/openbook/freedom/
> > >
> > > You might consider whether Richard Stallman would present his story a
> > > little differently from the people who were there with him at the time.
> >
> > Of course. I have already retracted my characterization of this book as
> > "the definitive account." However, the pliability of memory applies
> > equally well to all observers, not just the principals, and the account in
> > the book contains historical details that could be independently verified
> > if one were inclined to do so.
>
> You're assuming that mine can't.
No, merely observing that it didn't.
[much snippage]
> I don't think it would take much to document my claim that free software
> advocates routinely tell me that the world sheds no tears at my plight as
> a programmer who can't get paid for what he likes to do.
Most of the people in the world can't get paid for what they like to do.
Why should programmers be any different?
I like to ski. I would like to get paid for skiing. But so many people
are willing to ski for free (and even pay for the privilege! can you
imagine?) that I can't make a living skiing. Oh, the injustice!
Free software is not preventing you from making money any more than free
skiing (oh, wouldn't that be nice?) is preventing me from making money.
The only thing preventing either one of us from making money is our
unwillingness to go out and hustle, find customers, serve their needs, and
accept the risk of failure because, damn it, that's not nearly as much fun
as staying home and hacking Lisp (or skiing)!
E.
···@jpl.nasa.gov (Erann Gat) writes:
> > I don't think it would take much to document my claim that free software
> > advocates routinely tell me that the world sheds no tears at my plight as
> > a programmer who can't get paid for what he likes to do.
>
> Most of the people in the world can't get paid for what they like to do.
> Why should programmers be any different?
My arguments against free software don't hinge on this. I argue that
it is in the self-interest of the community not to undercut its own
economic force by voluntarily surrendering to the Stallman ideal that
programmers should be paid less because really good programmers are
compulsive and don't need to be paid to get them to do what they're
good at.
This particular discussion of history is an aside that does not
underlie my arguments against free software. It just makes me
irritated at many individual free software advocates who treat my
problems like they shouldn't matter, when the whole problem started
for reasons not dissimilar to mine. Nothing says they can't do it.
Nothing says I have to think them anything but selfish and unfeeling
for doing so.
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > > I don't think it would take much to document my claim that free software
> > > advocates routinely tell me that the world sheds no tears at my plight as
> > > a programmer who can't get paid for what he likes to do.
> >
> > Most of the people in the world can't get paid for what they like to do.
> > Why should programmers be any different?
>
> My arguments against free software don't hinge on this. I argue that
> it is in the self-interest of the community not to undercut its own
> economic force by voluntarily surrendering to the Stallman ideal that
> programmers should be paid less because really good programmers are
> compulsive and don't need to be paid to get them to do what they're
> good at.
Ah.
Do you know about the prisoner's dilemma?
E.
On 2003-03-18, Kent M Pitman <······@world.std.com> wrote:
> This particular discussion of history is an aside that does not
> underlie my arguments against free software. It just makes me
> irritated at many individual free software advocates who treat my
> problems like they shouldn't matter, when the whole problem started
> for reasons not dissimilar to mine. Nothing says they can't do it.
> Nothing says I have to think them anything but selfish and unfeeling
> for doing so.
I appreciate hearing your side of the story and take it as it is...you
side of the story. I don't consider it any less valid than what I
have read before on the issue (especially your characterisation of RMS
which fully matches what I've read before). I especially liked how
you mentioned he called you up and complained about the CL spec not
being free...it sounds very much like him :)
I want you to be sure that I am not a zealot, and I (personally) am
pushing your problems aside on the issue. I was unfamiliar with the
fact you are struggling with a small business (I'm new to this group
and who everyone is), so your side was unknown to me. But, you also
have to realize that I am someone that spent a number of years doing
commercial development having my skills waste away (I find commercial
developement mind numbinly boring due to the lack of challenge
companies are willing to take), so the only thing that I see that will
build *my* future is writing something that will improve my name
recognition/reputation.
I'm on usenet to do the same thing. Hopefully, after some time in
this group, with people like yourself I can make some connections or
at least build my reputation which will help me in the future. We all
don't have the need to downplay our involvement on being part of a
major language specification (that is meant in no way to be offensive)
so, for myselft, I see that opensource is a way of doing that.
I have no money. This is slightly by choice and slightly by market
whims. I want to learn to be a better programmer (hence my study of
lisp) and I think that lisp will allow me to compete with the big
boys, just like you do. But right now, I don't think I have that idea
that people will willing to pay for, and just because someone else
thinks that idea *is* something people will pay for, I don't think I
should stop myself from doing it just to be nice to them since that
will then reduce the value of what i'm getting paid in (reputation).
Your problems are valid, but they are your problems, just like mine
are mine. Hell, now I'm going to go out of my way to look and see
what you are developing and *not* write something that would be
competitive to your company. But that's due to the fact that you have
the reputation that I so sorely lack and that you might be able to
teach me a few things, or even help out someday by hiring me when you
get to be a magacorp. :)
--
burton samograd
······@hotmail.com
http://kruhftwerk.dydns.org
Kent M Pitman wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
>> > I don't think it would take much to document my claim that free
>> > software advocates routinely tell me that the world sheds no tears
>> > at my plight as a programmer who can't get paid for what he likes
>> > to do.
>>
>> Most of the people in the world can't get paid for what they like to
>> do. Why should programmers be any different?
>
> My arguments against free software don't hinge on this. I argue that
> it is in the self-interest of the community not to undercut its own
> economic force by voluntarily surrendering to the Stallman ideal that
> programmers should be paid less because really good programmers are
> compulsive and don't need to be paid to get them to do what they're
> good at.
No matter how much software is written for free, there'll always be
software a lot of people wouldn't want to write even if they're paid
for it. Also, I conjecture that the huge majority of commercially
written software is not in danger of being replaced by free software. I
have a hard time imagining anyone writing customer-specific software
for the fun of it.
Free/open source software proliferates in two areas: (1) Generic
applications that people start developing out of self-interest. (2)
Infrastructure (libraries, servers, programming languages, development
tools).
I don't know how things are internationally, but at least in Germany,
shrink-wrap software development makes for a minuscule part of overall
development.
The later hurts the business of commercial infrastructure vendors, but
in turn provides the shared benefit (modulo licensing
incompatibilities) of this infrastructure while also sharing the cost
of development.
So, I'd like to put forth that the community as a whole suffers at worst
a rather small cost, but at best gains considerable benefits.
> This particular discussion of history is an aside that does not
> underlie my arguments against free software. It just makes me
> irritated at many individual free software advocates who treat my
> problems like they shouldn't matter, when the whole problem started
> for reasons not dissimilar to mine. Nothing says they can't do it.
> Nothing says I have to think them anything but selfish and unfeeling
> for doing so.
Free software changes the landscape of what is economically viable. I'm
sorry, if it hurts your business, but at least you can be confident
that nobody is doing this to you willfully; compare and contrast
Microsoft vs Netscape.
IIRC(!), the case where competing free software hurt your business, is
not at all representative for "Stallmanite" free software development:
Another (comparatively larger) software vendor decided to make a
product freely available and thereby effectively killed the market for
your similar product. I take it, the other vendor wasn't pushed to this
step by being haunted by the ghost of Richard Stallman night after
night. They were driven by commercial interest. The effect on you is
just as bad, but it's no use blaming the wrong cause.
Michael
--
Michael Schuerig Airtight arguments have
···············@acm.org vacuous conclusions.
http://www.schuerig.de/michael/ --A.O. Rorty, "Explaining Emotions"
From: Christopher C. Stacy
Subject: Re: Learning new things
Date:
Message-ID: <uhea186hv.fsf@dtpq.com>
>>>>> On Mon, 17 Mar 2003 12:48:39 -0800, Erann Gat ("Erann") writes:
Erann> In article <·············@dtpq.com>, ······@dtpq.com (Christopher C.
Erann> Stacy) wrote:
>> >>>>> On Mon, 17 Mar 2003 07:52:56 -0800, Erann Gat ("Erann") writes:
>>
Erann> In article <···············@shell01.TheWorld.com>, Kent M Pitman
Erann> <······@world.std.com> wrote:
>>
>> >> Free software, in case you don't know, started with richard stallman
>> >> being sad that he wasn't going to be able to afford to be a programmer
>> >> any more because the complex weave of commercialism left him nowhere
>> >> to go that made him The plight of him and others like him plight used
>> >> to matter to me more until I found how little my plight mattered to
>> >> them. And in the end, the same problem exists.
>>
Erann> I think something got inadvertantly snipped from that
Erann> description, but it
Erann> doesn't seem entirely accurate. The definitive telling of the
Erann> story can
Erann> be found at http://www.oreilly.com/openbook/freedom/
>>
>> You might consider whether Richard Stallman would present his story a
>> little differently from the people who were there with him at the time.
Erann> Of course. I have already retracted my characterization of this book as
Erann> "the definitive account." However, the pliability of memory applies
Erann> equally well to all observers, not just the principals, and the account in
Erann> the book contains historical details that could be independently verified
Erann> if one were inclined to do so.
I posted my message before your retraction had been published on my news server.
(My recollection matches Kent's, by the way.)
Kent M Pitman <······@world.std.com> writes:
> Edi Weitz <···@agharta.de> writes:
>
> > However, I fail to see what you're aiming at, i.e. what the
> > consequences should be if people subscribed to your arguments. Do you
> > think it would improve the overall economical situation of the
> > software industry if "free software" was forbidden or somehow
> > regulated?
>
> As a first order of business, I think it would serve the overall software
> industry if free software were not regarded as a panacea. I'm leary of
> anything which is a mechanism that is regarded as "automatically good".
> I believe that it's outcome, not mechanism, that matters. I have the
> same problem with church dogma. Dogma is a focus on compiled-in mechanism
> and fights thought. Saying there is no clear answer and that one has to
> _think_ makes things more complicated, but is more satisfying to me.
>
> I don't know that thinking will always yield a correct answer, but I
> suspect that not thinking will not out-perform it.
Free software wouldn't exist if commercial vendors didn't tend towards
evil. I think you'll find very few people who think free software is
a panacea- but with its tradeoffs, it is often preferable to the often
buggy products of companies that treat their customers as pirates.
If software companies started treating their customers like car
companies treat theirs I think the software racket would be much
improved. When was the last time a car company tried to legally
prevent their customers from talking about their product's
performance? Yet Microsoft and Oracle routinely do this as part of
their terms of sale. With companies like that around can you wonder
that people will seek any alternative at all?
If you could come up with some kind of regulation that would keep the
commercial software monopolies under control, but which also affected
how free software was managed, I'd probably be in some agreement with
you- but I think doing the former will be impossible until they
fossilize and get their lunch eaten by the next generation of
software.
Gregm
Greg Menke <··········@toadmail.com> writes:
> Free software wouldn't exist if commercial vendors didn't tend towards
> evil.
You could have picked no easier mark to underscore my point about dogma.
The rhetoric on free software is kneedeep in the use of the terms
"good" and "evil".
These are the most easily spotted earmarks of dogma, IMO.
Once you know something is Evil, it is so easy to dismiss.
Once you know something is Good, it is so easy to accept.
The world is full of middle grounds, but the organizations that pronounce
judgments of good and evil as a routine practice seem to me more interested
in political power than in philosophical debate.
> I think you'll find very few people who think free software is
> a panacea
I think it is routinely taught that contributing free software is
automatically good, regardless of the arena into which you contribute
it and the effect on surrounding commercial markets. It is routinely
taught that if this drives someone out of business, that person deserved
it. That's my meaning of panacea. Do you dispute that these two 'truths'
are routinely offered?
People are not taught, I claim, that there might be better and worse
places to contribute free software depending on whether there are already
vendors in the market, or likely to be, and whether those people are
charging a fair price.
Microsoft is usually mentioned within two minutes of any discussion on
this, and offered as the prototype of all companies, when in fact it is
the exception. Microsoft has some issues, yes, but not all companies are
Microsoft and not all companies deserve to be treated like they had done
what Microsoft has.
> - but with its tradeoffs, it is often preferable to the often
> buggy products of companies that treat their customers as pirates.
In my personal experience, free software is more likely not to work usefully
off-the-shelf that commercial software. And in my experience, few companies
treat their customers as pirates.
And, by the way, piracy rates world-wide are huge, so there is even good
cause to treat customers as potential pirates more than a lot of companies
do. The fact that a few companies create draconian requirements does not
justify treating the others as the same.
> If software companies started treating their customers like car
> companies treat theirs I think the software racket would be much
> improved. When was the last time a car company tried to legally
> prevent their customers from talking about their product's
> performance? Yet Microsoft and Oracle routinely do this as part of
> their terms of sale. With companies like that around can you wonder
> that people will seek any alternative at all?
Aha. I was answering this post linearly. What a surprise to find
Microsoft mentioned as a prototype of the kind of company that all
companies are.
> If you could come up with some kind of regulation that would keep the
> commercial software monopolies under control, but which also affected
> how free software was managed, I'd probably be in some agreement with
> you- but I think doing the former will be impossible until they
> fossilize and get their lunch eaten by the next generation of
> software.
I daresay that if you brought down Microsoft, the world's largest
companies would always have a bit of an edge because they can buy
lobbyists and control governments in any likely political system.
I doubt you can ever handwave this away.
Trying to correct it by creating devices that bring down the little
guys in the process, too, seems dumb to me. Kind of an MADD for
software. Great.
Kent M Pitman <······@world.std.com> writes:
> Greg Menke <··········@toadmail.com> writes:
>
> > Free software wouldn't exist if commercial vendors didn't tend towards
> > evil.
>
> You could have picked no easier mark to underscore my point about dogma.
>
> The rhetoric on free software is kneedeep in the use of the terms
> "good" and "evil".
>
> These are the most easily spotted earmarks of dogma, IMO.
>
> Once you know something is Evil, it is so easy to dismiss.
>
> Once you know something is Good, it is so easy to accept.
Oh come on, I think you know what I'm talking about. By evil, I mean
the systematic destruction of competition and open standards, while at
the same time implementing software that invades the privacy of users-
yet not publishing the details of what is being collected and why.
Thats before getting into predatory licensing and strong-arm
mechanisms like the BSA. Also, I did not invoke good- nothing is
either dismissed or accepted.
>
> > I think you'll find very few people who think free software is
> > a panacea
>
> I think it is routinely taught that contributing free software is
> automatically good, regardless of the arena into which you contribute
> it and the effect on surrounding commercial markets. It is routinely
> taught that if this drives someone out of business, that person deserved
> it. That's my meaning of panacea. Do you dispute that these two 'truths'
> are routinely offered?
I think they points you mention are often asserted, but that doesn't
mean they are as often accepted. Honestly, I do tend to think that if
a free software project puts a commercial product out of business, the
business very likely did deserve it. It wouldn't bother you if a
competing vendor did it, why is it a problem if a free software
program does? What if the vendor did it by pricefixing the
competition until they gave up?
>
> People are not taught, I claim, that there might be better and worse
> places to contribute free software depending on whether there are already
> vendors in the market, or likely to be, and whether those people are
> charging a fair price.
Why do people have to be taught what to work on or not? Their time is
their business. I gather what you're really talking about is
preserving the price structure of a software market by some mechanism.
If there was some way to keep the monopolies under control, I might
well agree with you. However I think the larger pressures in the
software business have caused the rise of free software.
> Microsoft is usually mentioned within two minutes of any discussion on
> this, and offered as the prototype of all companies, when in fact it is
> the exception. Microsoft has some issues, yes, but not all companies are
> Microsoft and not all companies deserve to be treated like they had done
> what Microsoft has.
They are the biggest target, however I'm open to hearing about a large
commercial vendor that isn't showing intrusive if not abusive
tendencies towards its customers. I think if you want civilized
treatment from a software company, you have to get down to the smaller
end and even there its hardly universal.
> > - but with its tradeoffs, it is often preferable to the often
> > buggy products of companies that treat their customers as pirates.
>
> In my personal experience, free software is more likely not to work usefully
> off-the-shelf that commercial software. And in my experience, few companies
> treat their customers as pirates.
More and more do. Look at the resurgence of "licensing" and copy
protection measures in the last few years. I agree that free software
can often be more labor intensive than its commercial competitors- its
a strong argument for going for the commercial alternative. I'm not
against commercial vendors in any way- I buy all the commercial
software I use with my own money- I just don't want to be pushed
around by some vendor's arbitrary, internal agenda.
> And, by the way, piracy rates world-wide are huge, so there is even good
> cause to treat customers as potential pirates more than a lot of companies
> do. The fact that a few companies create draconian requirements does not
> justify treating the others as the same.
So I imagine you don't mind having to register your software (then
getting spam from the information they subsequently sell) and be
limited in how you reinstall & reconfigure your hardware before
getting your software "reblessed"?
What about in a few years or so, after the original company has been
bought and sold a few times and is now long gone and theres no way to
get your software reauthorized? Or perhaps your $3,000 copy of the
software is No Longer Supported & you're simply out of luck?
I'm not opposed to copy protection- not the stupid, invasive Microsoft
model- but one more like the dongle approach. You can freely install
& copy the software any way you like, but it simply won't run without
the little dongle gizmo- and thats what it costs you to buy. Its
unappealing in a couple ways, but it is entirely uninvasive and it
goes a long way towards mitigating the piracy issue for many classes
of software.
> > If you could come up with some kind of regulation that would keep the
> > commercial software monopolies under control, but which also affected
> > how free software was managed, I'd probably be in some agreement with
> > you- but I think doing the former will be impossible until they
> > fossilize and get their lunch eaten by the next generation of
> > software.
>
> I daresay that if you brought down Microsoft, the world's largest
> companies would always have a bit of an edge because they can buy
> lobbyists and control governments in any likely political system.
> I doubt you can ever handwave this away.
>
> Trying to correct it by creating devices that bring down the little
> guys in the process, too, seems dumb to me. Kind of an MADD for
> software. Great.
I'm open to an alternative, achievable suggestion. I'm not about
trying to bring down Microsoft- they're doing a good job of it all by
themselves. I'm in a 98% Microsoft free job now- and I'm pretty sure
I would quit and be a bartender if I had to go back to using their
products- so I'm quite in favor of free software.
Gregm
On 2003-03-17, Kent M Pitman <······@world.std.com> wrote:
> I think it is routinely taught that contributing free software is
> automatically good, regardless of the arena into which you contribute
> it and the effect on surrounding commercial markets. It is routinely
> taught that if this drives someone out of business, that person deserved
> it. That's my meaning of panacea. Do you dispute that these two 'truths'
> are routinely offered?
I don't know if people are being "taught" that contributing free
software is good, but I do think that programming is moving more
towards the "I say I do this" to "look at what I have done". Someone
else pointed out that the guys that developed apache can charge more
(or at least get some work) because they can point out "look, I wrote
apache, so if you don't trust what I say about my experience, have a
look for yourself".
This is similar to almost every other "artistic" field, where people
build and present portfolios of thier work. One of the biggest
complaints about the job market today is that the HR people have no
idea what they are looking for and find it impossible to cut through
the crap resume's that are flooding them. Creating an opensource
project that happens to be sucessful is a quick way to cut through
that crap, or at least get your name closer to being one that people
come to rather than you going out to them with all the others.
Free software is not better than non-free software depending upon the
purpose, but it does form some sort of public intership where you can
show that you're proud enough of what you do that you will put out
your work for all to see. It also can show how you work in a team
environment, because as i'm sure we all know, working with other
developers can be quite trying at times.
But I think that if someone develops something for fun, in some sort
of pseudo independant intership that does happen to outperform a
commercial product, then yes, those people that just got put out of
business did deserve it. Skills and technology move on, so if somone
with less experience that is just trying to prove themselves can
develop a better product...
> People are not taught, I claim, that there might be better and worse
> places to contribute free software depending on whether there are already
> vendors in the market, or likely to be, and whether those people are
> charging a fair price.
As I said, I think contributing to free software is completely
selfish, especially in the market right now where everybody is trying
to get ahead. When trying to improve yourself you don't worry about
who you might put out of business, especially when you are out of work
and broke.
> Microsoft is usually mentioned within two minutes of any discussion on
> this, and offered as the prototype of all companies, when in fact it is
> the exception. Microsoft has some issues, yes, but not all companies are
> Microsoft and not all companies deserve to be treated like they had done
> what Microsoft has.
But that is the nature of competition. If these companies feel like
they are being put out of business by some out of work programmers
with too much time on thier hands that happen to be developing a
better and free version of thier product, they should be hiring those
people to help them make a better product.
> In my personal experience, free software is more likely not to work usefully
> off-the-shelf that commercial software. And in my experience, few companies
> treat their customers as pirates.
Hmmm...I beg to differ on that. Any actual useful product that
doesn't treat thier customers like pirates (with dongles, license
files that cause the software to run if you have a drive crash and
didn't have a backup, etc) don't have free alternatives, mostly
because they are difficult programs to write that fill a niche market.
--
burton samograd
······@hotmail.com
http://kruhftwerk.dydns.org
Burton Samograd <······@hotmail.com> writes:
> This is similar to almost every other "artistic" field, where people
> build and present portfolios of thier work. One of the biggest
> complaints about the job market today is that the HR people have no
> idea what they are looking for and find it impossible to cut through
> the crap resume's that are flooding them. Creating an opensource
> project that happens to be sucessful is a quick way to cut through
> that crap, or at least get your name closer to being one that people
> come to rather than you going out to them with all the others.
Software is not an artistic effort. The issues that people program about
matter in ways that go far beyond what people do. Certainly some people
can't show their work, but then if you're a chemist for coca-cola you
don't go exposing your formula for coke in order to get a job at pepsi
(or even in some neutral third industry).
Certainly exposing a portfolio simplifies some hiring matters. But
industries should not be exposing things simply to make hiring better.
Indeed, any given company adopting a strategy that would allow its
employees to be more easily hired by someone else is operating in a
very strange way.
Incidentally, I find the "look at what I have done" thing to be not the
simple good thing you say, either, since in an engineering discipline
(unlike an art), you're often collaborating. And now you have the new
difficulty of understanding whose contribution was what. People around
here sometimes get confused into thinking I did more in designing CL than
I did just because my name is on the cover. I prefer to correct them
when I see it rather than remove my name from the cover, since I like that
I get some advertising power from the visibility. But I spend most of my
job interviews with people telling them what I can't do rather than what
I can because it is too easy for them to see association between me and
the visible things I've been involved with an infer overcompetence.
Someone who was either not as confident or not as ethical as I hope that
I am might not try to disabuse people of apparent false impressions they
get from association with a winning project...
I've seen this a lot in companies. Someone will say "I took over this
company and turned it around" but when you look into it you'll find that
maybe it was some other person internally who was over lower rank but in the
right place at the right time that made the real difference and was never
credited.
Just pointing to "this is what I did" may sound good and simple
but is deceptive, I think. Whether intentionally deceptive or accidentally,
it doesn't change the fact.
> > People are not taught, I claim, that there might be better and worse
> > places to contribute free software depending on whether there are already
> > vendors in the market, or likely to be, and whether those people are
> > charging a fair price.
>
> As I said, I think contributing to free software is completely
> selfish, especially in the market right now where everybody is trying
> to get ahead. When trying to improve yourself you don't worry about
> who you might put out of business, especially when you are out of work
> and broke.
I don't mind selfish. I mind damaging.
I hypothetical scenario I've put out is this:
A town contains a shoe store and a shoe repair shop. There is a line
often a line outside the shoe repair shop because not everyone can
afford new shoes, but both the shoe repair shop and new shoe shop
break even, and no one is without shoes. A kindly patron comes to
town and buys everyone new shoes. Who benefits? Well, everyone has
nicer shoes, so you could say the town does. But in the process the
shoe repair person goes out of business because there is no one to
serve. Meanwhile, people still can't afford shoes so eventually their
shoes will need repair or replacement, and they can't replace them. Now
there is just no one to sell them repairs. I don't really call this a
benefit.
Charity belongs in markets not served by anyone, not in markets where
there is already an active, functional commercial solution.
Free software that is contributed in the face of a commercial solution
kills the commercial solution, and I think with it competition. Free
software does not like competition. It is easily cloned, but cloning
divides effort and people don't like wasting their "free time".
Businesses divide effort, but there is a net competitive effect for so
doing, and the market actively improves due to the non-cooperation.
The entire system also becomes stronger due to competition and redundant
work in the sense of being more resilient against virus-like effects.
Free software works against this.
> > Microsoft is usually mentioned within two minutes of any discussion on
> > this, and offered as the prototype of all companies, when in fact it is
> > the exception. Microsoft has some issues, yes, but not all companies are
> > Microsoft and not all companies deserve to be treated like they had done
> > what Microsoft has.
>
> But that is the nature of competition. If these companies feel like
> they are being put out of business by some out of work programmers
> with too much time on thier hands that happen to be developing a
> better and free version of thier product, they should be hiring those
> people to help them make a better product.
It's only small busineses that are killed this way. Big businesses might
do as you say but were not in danger in the first place. Small businesses
can't "just hire". They have limited funds. I don't know if you know what
it's like to start a business, but in spite of the words "Incorporated",
the banks make you put your personal house and your persoanl life savings
on the line. You co-sign individually for things in such a way that you
may be protected from lawsuit but you are not protected from debt.
When you make a mistake, they take everything you own. There
is no room for mistakes when you are a little business. Some people
start by just starting a big company with lots of venture capital and let
the VC people lose the money if it goes wrong. I guess that works. I can't
bring myself to gamble that kind of money. I prefer to gamble my own. But
that leaves me precious little safety margin.
>
> > In my personal experience, free software is more likely not to work usefully
> > off-the-shelf that commercial software. And in my experience, few companies
> > treat their customers as pirates.
>
> Hmmm...I beg to differ on that.
I CAREFULLY said "in my personal experience".
Please do not differ. You are not an authority on my experience.
> Any actual useful product that
> doesn't treat thier customers like pirates (with dongles, license
> files that cause the software to run if you have a drive crash and
> didn't have a backup, etc) don't have free alternatives, mostly
> because they are difficult programs to write that fill a niche market.
Kent Pitman wrote:
> A town contains a shoe store and a shoe repair shop. There is a line
> often a line outside the shoe repair shop because not everyone can
> afford new shoes, but both the shoe repair shop and new shoe shop
> break even, and no one is without shoes. A kindly patron comes to
> town and buys everyone new shoes. Who benefits? Well, everyone has
> nicer shoes, so you could say the town does. But in the process the
> shoe repair person goes out of business because there is no one to
> serve. Meanwhile, people still can't afford shoes so eventually their
> shoes will need repair or replacement, and they can't replace them. Now
> there is just no one to sell them repairs. I don't really call this a
> benefit.
Suppose the kindly patron goes on buying people new shoes
when the old ones wear out. Is it a benefit then?
--
Gareth McCaughan ················@pobox.com
.sig under construc
Gareth McCaughan <················@pobox.com> writes:
> Kent Pitman wrote:
>
> > A town contains a shoe store and a shoe repair shop. There is a line
> > often a line outside the shoe repair shop because not everyone can
> > afford new shoes, but both the shoe repair shop and new shoe shop
> > break even, and no one is without shoes. A kindly patron comes to
> > town and buys everyone new shoes. Who benefits? Well, everyone has
> > nicer shoes, so you could say the town does. But in the process the
> > shoe repair person goes out of business because there is no one to
> > serve. Meanwhile, people still can't afford shoes so eventually their
> > shoes will need repair or replacement, and they can't replace them. Now
> > there is just no one to sell them repairs. I don't really call this a
> > benefit.
>
> Suppose the kindly patron goes on buying people new shoes
> when the old ones wear out. Is it a benefit then?
I'd rather see that patron solve a problem that NEEDS solving.
Kent M Pitman <······@world.std.com> writes:
> Gareth McCaughan <················@pobox.com> writes:
> > Suppose the kindly patron goes on buying people new shoes
> > when the old ones wear out. Is it a benefit then?
>
> I'd rather see that patron solve a problem that NEEDS solving.
Kent, have you considered publishing your views on free software in a
more formal form? An essay, perhaps? I think you have some very
interesting things to say about free software (a great deal more
interesting then the more typical "L1nux rul3z d00dz!!! M$ is fer
lus3rz!" free software opinion), but I think USENET is a pretty lousy
medium for introducing unfamiliar and original thoughts: instead of a
tight, cohesive argument we just get to see a bunch of short fragments
that inevitably get nit-picked to death.
I think that your involvement with the culture that shaped Stallman
and your experiences with HyperMeta and AllegroServe have probably
given you some interesting insights, and I'd love to hear them put
forward more clearly then this medium allows.
As for this thread, now's the point where someone's gonna say
something about all the poor people in the world without shoes, and
then someone else is gonna say something about Hitler's shoe-buying
practices.... :)
Gabe Garza
On 2003-03-17, Kent M Pitman <······@world.std.com> wrote:
>> This is similar to almost every other "artistic" field, where people
>> build and present portfolios of thier work. One of the biggest
>> complaints about the job market today is that the HR people have no
>> idea what they are looking for and find it impossible to cut through
>> the crap resume's that are flooding them. Creating an opensource
>> project that happens to be sucessful is a quick way to cut through
>> that crap, or at least get your name closer to being one that people
>> come to rather than you going out to them with all the others.
>
> Software is not an artistic effort. The issues that people program about
> matter in ways that go far beyond what people do. Certainly some people
> can't show their work, but then if you're a chemist for coca-cola you
> don't go exposing your formula for coke in order to get a job at pepsi
> (or even in some neutral third industry).
Well, I didn't mean to say that it was artistic! :) What I meant was
that I think that programming is moving in a direction which is closer
to such artistic fields, and hence the need for a portfolio of work
when presenting yourself to new clients/employers, if only so that you
can prove what you have done or to have it sitting out there on the
web the they might find and have them contact you (much like some
artists, painters and graphic designers do with their web pages to get
business)
Some people cannot expose their work due to various intellectual
property constraints and NDA's, but free software *for me* isn't about
that. I could care less about "intellectual property" and find that
free software is more about showing how I can compelete a project and
actually have people look at it if they chose.
This is probably different from you being someone with his name on a
major language specification with a number more years experience than
I (and many, many others) do. Free software for me allows a chance at
being distinctive and noticable and skillful when it comes to
programming. If I was going to write something and release it the
last thing on my mind would be that it would put someone out of
business...it would simply be a projet that I found interesting and
happened to implement. But then, that moves me back to my original
argument, that if what I wrote was better than something that was
developed by a professional company (which I doubt), shouldn't that
say something about the company that is being put out of business?
> Certainly exposing a portfolio simplifies some hiring matters. But
> industries should not be exposing things simply to make hiring better.
> Indeed, any given company adopting a strategy that would allow its
> employees to be more easily hired by someone else is operating in a
> very strange way.
From a company standpoint, that is very true. But I am talking more
about the many unemployed and *compitent* programmers that are out of
work right now, that need some way to get hired more easily.
> Incidentally, I find the "look at what I have done" thing to be not the
> simple good thing you say, either, since in an engineering discipline
> (unlike an art), you're often collaborating. And now you have the new
> difficulty of understanding whose contribution was what. People around
> here sometimes get confused into thinking I did more in designing CL than
> I did just because my name is on the cover. I prefer to correct them
> when I see it rather than remove my name from the cover, since I like that
> I get some advertising power from the visibility. But I spend most of my
> job interviews with people telling them what I can't do rather than what
> I can because it is too easy for them to see association between me and
> the visible things I've been involved with an infer overcompetence.
> Someone who was either not as confident or not as ethical as I hope that
> I am might not try to disabuse people of apparent false impressions they
> get from association with a winning project...
I also see your point there. I mostly write software on my own
because I have a hard time working with other people on projects,
although I think it's a problem with group software development more
than me (of course :). Credit should be taken where credit is due,
but a number of people just take without contributing.
Of course my view is skewed because I like to do everything myself,
which either will make me a superstar (djb of qmail fame is such a
person) or doom me to the failure of never completing things because
of lack of resources. Either way, I'll have something to show,
learned my lessons and, when the job market turns around be in a
better position because of these things.
> I've seen this a lot in companies. Someone will say "I took over this
> company and turned it around" but when you look into it you'll find that
> maybe it was some other person internally who was over lower rank but in the
> right place at the right time that made the real difference and was never
> credited.
Seen it many times as well, but it's Just The Way The World Works(TM)
sometimes.
> Just pointing to "this is what I did" may sound good and simple
> but is deceptive, I think. Whether intentionally deceptive or accidentally,
> it doesn't change the fact.
Like I said, I think my strategy is that simple :) I don't plan on
taking credit for others work and (like you do) enjoy talking more
about what I can't do than what I can...if only just to find out why.
Personally, I hope it works for me, as it is quite a simple strategy,
but in the end i'll have learned something (wow, I took this thread
all the way back on topic!)
> I don't mind selfish. I mind damaging.
<snip scenario>
> Charity belongs in markets not served by anyone, not in markets where
> there is already an active, functional commercial solution.
That's where it belongs, but there's nothing keeping it there.
> Free software that is contributed in the face of a commercial solution
> kills the commercial solution, and I think with it competition. Free
> software does not like competition. It is easily cloned, but cloning
> divides effort and people don't like wasting their "free time".
> Businesses divide effort, but there is a net competitive effect for so
> doing, and the market actively improves due to the non-cooperation.
I don't get what you mean, that free software doesn't like
competition. Maybe RMS doesn't want any competition on his crusade,
but I see tonnes of competition in the free software world, from the
number of linux distributions to how many different workable web
servers there are.
I think that open software generates too much competition and
therefore overloading the market and collapsing it (like web
servers). But that's because those projects are not hard to develop
and *can* be done by a one or two person team in their spare time, and
were probably just done as a learning experience and something to put
on their resume.
If a business cannot compete with that...i'm just back at where I was
before.
> The entire system also becomes stronger due to competition and redundant
> work in the sense of being more resilient against virus-like effects.
> Free software works against this.
I can't get this point, due to the amount of competition I pointed out
above.
> It's only small busineses that are killed this way. Big businesses might
> do as you say but were not in danger in the first place. Small businesses
> can't "just hire". They have limited funds. I don't know if you know what
> it's like to start a business, but in spite of the words "Incorporated",
> the banks make you put your personal house and your persoanl life savings
> on the line. You co-sign individually for things in such a way that you
> may be protected from lawsuit but you are not protected from debt.
> When you make a mistake, they take everything you own. There
> is no room for mistakes when you are a little business. Some people
> start by just starting a big company with lots of venture capital and let
> the VC people lose the money if it goes wrong. I guess that works. I can't
> bring myself to gamble that kind of money. I prefer to gamble my own. But
> that leaves me precious little safety margin.
I see where our views differed when I wrote the message you replied to
here. I wasn't thinking of small business, but being a business owner
yourself it is the forefront in your mind, which i fully understand.
I also like to gamble on myself and have tried to start a business and
I found that it's not for me, or at least not right now in my life. I
think the reasons for me not wanting to run a business is exactly what
we are discussing here...the types of projects one could do for a
business in the past have now been taken over by free software and the
world is run by the big guys. I couldn't think of any solution for
that no matter how hard i tried, so I moved more towards academia
again because at least I'm learning things and when things settle down
my skills will be better and i'll have a better chance at coming up
with that idea that a megacorp will not even have on its radar.
> I CAREFULLY said "in my personal experience".
> Please do not differ. You are not an authority on my experience.
Sorry, I didn't mean to insult with that remark. I just meant that my
experience has been different with respect to that topic.
--
burton samograd
······@hotmail.com
http://kruhftwerk.dydns.org
* Burton Samograd wrote:
> Well, I didn't mean to say that it was artistic! :) What I meant was
> that I think that programming is moving in a direction which is closer
> to such artistic fields, and hence the need for a portfolio of work
> when presenting yourself to new clients/employers, if only so that you
> can prove what you have done or to have it sitting out there on the
> web the they might find and have them contact you (much like some
> artists, painters and graphic designers do with their web pages to get
> business)
All I can say about this is from my own experience: stuff you didn't
get do in a commercial context (whether it's OSS or not: the issue is
you got verifiably paid for it) counts for nothing. It may even count
negatively if there is too much of it (because it makes you look like
you can't get paid).
This is my experience in applying for work, and it's also what I'd
consider if hiring someone. In fact we recently have been doing just
that, in a very small way, and I *definitely* did not consider stuff
that was not hard commercial got-paid-for-it experience.
So watch out, is all I can say: free SW does not look good on your CV
in many areas.
--tim
Tim wrote:
> All I can say about this is from my own experience: stuff you didn't
> get do in a commercial context ... counts for nothing. It may even count
> negatively if there is too much of it (because it makes you look like
> you can't get paid).
I completely agree. However, it is the *getting paid* for it I think
is is key...
> This is my experience in applying for work, and it's also what I'd
> consider if hiring someone. In fact we recently have been doing just
> that, in a very small way, and I *definitely* did not consider stuff
> that was not hard commercial got-paid-for-it experience.
I have been paid to install free software -- as I have done (e.g.
postgresql, apache, samba, jboss) and non-free software (e.g. oracle,
iplanet, pc netlink, bea weblogic). When I talk to people about
working they seem interested in both.
However, maybe this is because I have been paid to do both and can say
`I did very little but <questa roba>' for n weeks. Or maybe they like
my haircut.
> So watch out, is all I can say: free SW does not look good on your CV
> in many areas.
Yup. `I spend my time administering the wang.yayas.org site -- its a
really cool site dedicated to lingerie for the man with the fuller
figure' is probably not going to cut much ice. However, necessary it
might be in this modern world.
However, I can think of other projects -- such as those above or other
stuff (like gnome, OpenLDAP, Openssh) -- which are really rather
useful, and being listed as a member of the development team *would*
be good.
Hmmm.
:)w
* Will Deakin wrote:
> I have been paid to install free software -- as I have done
> (e.g. postgresql, apache, samba, jboss) and non-free software
> (e.g. oracle, iplanet, pc netlink, bea weblogic). When I talk to
> people about working they seem interested in both.
But that's OK - it's the getting paid for it that counts. I think I
tried (and maybe failed) to say that: it doesn't matter about the
open-sourceness or free-beerness of the SW (I've worked for people who
were doing embedded Linux), what matters is the commercial context.
> However, I can think of other projects -- such as those above or other
> stuff (like gnome, OpenLDAP, Openssh) -- which are really rather
> useful, and being listed as a member of the development team *would*
> be good.
Not unless you got paid, in my book. What does `member of the xyz'
core development team' actually mean to someone unless they know what
it takes to be in the xyz core development team. And I don't know
*any* of those rules, which is more than 99% of people know.
--tim
Tim wrote:
> But that's OK - it's the getting paid for it that counts. I think I
> tried (and maybe failed) to say that: it doesn't matter about the
> open-sourceness or free-beerness of the SW ... what matters is the
> commercial context.
On re-reading I think it is my inability to read that is a fault...
>>However, I can think of other projects -- such as those above or other
>>stuff (like gnome, OpenLDAP, Openssh) -- which are really rather
>>useful, and being listed as a member of the development team *would*
>>be good.
> Not unless you got paid, in my book. What does `member of the xyz'
> core development team' actually mean to someone unless they know what
> it takes to be in the xyz core development team. And I don't know
> *any* of those rules, which is more than 99% of people know.
Well, I'd still probably talk to them to find this stuff out. They
might be good. Although no paid experience would be a big no. I'd have
to draw the line at academics though ;)
(About five years ago -- pre-webfrob-site building tools -- I saw a
situation where a web-app was being developed with one person writing
the do stuff code, one person writing the callbacks and a third
drawing the buttons. All three (sort of) claimed to be web-app
developers. I know which one I'd want to work with.)
:)w
* Rajappa Iyer wrote:
> For a somewhat different perspective, see:
> http://www.theopenenterprise.com/story/TOE20021202S0001
I can't see where he disagrees with me. He doesn't quite say it but
it looks strongly as if he's looking for `got paid for it' experience.
Maybe I was confusing: I'm *not* suggesting that experience with OSS
systems is a negative indicator, I *am* suggesting that not getting
paid for it is a negative indicator. Loads of people are looking for
Linux/gcc/CVS/whatever, but they tend to want you to have (say)
actually *got paid* for running a CVS-based SCM.
--tim
Kent M Pitman wrote:
> I hypothetical scenario I've put out is this:
>
> A town contains a shoe store and a shoe repair shop. There is a line
> often a line outside the shoe repair shop because not everyone can
> afford new shoes, but both the shoe repair shop and new shoe shop
> break even, and no one is without shoes. A kindly patron comes to
> town and buys everyone new shoes. Who benefits? Well, everyone has
> nicer shoes, so you could say the town does. But in the process the
> shoe repair person goes out of business because there is no one to
> serve. Meanwhile, people still can't afford shoes so eventually their
> shoes will need repair or replacement, and they can't replace them. Now
> there is just no one to sell them repairs. I don't really call this a
> benefit.
In relation to free software I think this is a false analogy (I am
not a big fan of free software). Buying people shoes just for the
hell of it is like giving gifts. But giving away software in the hopes
that the people you are giving it to will come to you for help and
support is just an alternative marketing ploy. If someone who sells
their software cannot keep up with this it just means that their
marketing model is inferior and they have the wrong approach. Customers
will choose the product that is better for them. There is a correlation
between minimizing profits and maximizing the market.
It is not anyones responsibility to keep you in business by not
releasing their own software at far better prices. Yes, maybe they
create less monetary gain overall, but so what really? It is a free
market, anyone who can offer a service is allowed to do so. There
is still plenty of software that needs to be written which is
unviable as free software (too big, special expertise, very narrow
customer base etc). That these people do not care about money does
not damage your ability to make money (except in certain fields).
It is the same when you look at it the other way, you damage their
ability to do something they clearly enjoy by saying that free
software should be limited. Simply put, if you are interested in making
money and someone else is interested in offering software for free
and these interests conflict, that means that one of you is going
to suffer. And who are you (or I) to judge which side is right and
wrong?
--
Thomas.
* Thomas Stegen wrote:
> In relation to free software I think this is a false analogy (I am
> not a big fan of free software). Buying people shoes just for the
> hell of it is like giving gifts. But giving away software in the hopes
> that the people you are giving it to will come to you for help and
> support is just an alternative marketing ploy. If someone who sells
> their software cannot keep up with this it just means that their
> marketing model is inferior and they have the wrong approach. Customers
> will choose the product that is better for them. There is a correlation
> between minimizing profits and maximizing the market.
No, it's not. Giving software away and selling time is just that:
selling time. You can only sell your time once. But you can sell
software several times. Which translates into: you don't get rich
selling your time.
I agree with the bit I deleted - I think it really is up to the market
to decide: maybe free software *will* win. Personally, I think it
hasn't a chance, because I think that the current glut of free
software is an artifact of the enormous money which was thrown at
technology companies over the last 20 years making it look to them as
if they could just give things away because their main problem was
spending the money fast enough that they didn't suffocate under huge
pile of dollar bills. Now that bubble has well and truly burst
companies are going to have to be a whole bunch more fussy about
paying their employees' wages so they can give stuff away. Of course
there will be a correction period during which all the people laid off
from the bubble companies continue to churn stuff out for free, but as
they all gradually starve and get melted down for pills & soap this
will go away.
--tim
>>>>> "Burton" == Burton Samograd <······@hotmail.com> writes:
Burton> build and present portfolios of thier work. One of the biggest
Burton> complaints about the job market today is that the HR people have no
Burton> idea what they are looking for and find it impossible to cut through
Burton> the crap resume's that are flooding them. Creating an opensource
Burton> project that happens to be sucessful is a quick way to cut through
Burton> that crap, or at least get your name closer to being one that people
Burton> come to rather than you going out to them with all the others.
If HR can't cut through the crap resumes today, what makes you think
they can tell the difference between a successful opensource project
from any other project? They probably don't even know of any
opensource projects.
I think the HR people I've worked with just pass any resume that was
submitted for that particular job on to me. Which is the way it
should be.
Ray
On 2003-03-17, Raymond Toy <···@rtp.ericsson.se> wrote:
> If HR can't cut through the crap resumes today, what makes you think
> they can tell the difference between a successful opensource project
> from any other project? They probably don't even know of any
> opensource projects.
I'm thinking more along the lines of those small businesses that lack
the standard HR department. Think of someplace small that needs to
recruit people for a type of project but are tight on funds or just
don't trust headhunters. Doing a search for a certain type of project
and then contacting the developers/maintainers seems like a good
initial way to get a list of contacts, plus you they the chance to
look at the quality of the work at the same time.
A dream maybe, but it makes sense to me.
> I think the HR people I've worked with just pass any resume that was
> submitted for that particular job on to me. Which is the way it
> should be.
It should be, but it didn't seem to work that way at some of the
places I've been. I think the important thing is how they picked that
group resumes out of the prospective pile, and I have a hard time
believing that they will pick the "best" candidates for your
consideration.
--
burton samograd
······@hotmail.com
http://kruhftwerk.dydns.org
In article <·············@kruhft.dyndns.org>, Burton Samograd wrote:
> On 2003-03-17, Raymond Toy <···@rtp.ericsson.se> wrote:
>> If HR can't cut through the crap resumes today, what makes you think
>> they can tell the difference between a successful opensource project
>> from any other project? They probably don't even know of any
>> opensource projects.
>
> I'm thinking more along the lines of those small businesses that lack
> the standard HR department. Think of someplace small that needs to
> recruit people for a type of project but are tight on funds or just
> don't trust headhunters. Doing a search for a certain type of project
> and then contacting the developers/maintainers seems like a good
> initial way to get a list of contacts, plus you they the chance to
> look at the quality of the work at the same time.
Just a note on the assumption underlying this thread that authoring
open-source software can _only_ improve one's standing with a
prospective employer. I maintain that it can instead raise the bar
in unanticipated ;-) ways.
I once interviewed a candidate who had written a well-done and not
unknown publically available Lisp package that I had heard of and in
fact I had browsed prior to the interview. Since we were familiar
with the candidate's work, I was able to skip some of the standard
vague interview fodder ("if you were a Lisp special-operator, which
one would you be?") and cut right to the chase.
In short order, I asked the candidate to discuss the algorithmic
complexity of one of the major tasks within the application. The
answer revealed unfamiliarity not only with algorithmic analysis of
the code (perhaps understandable since this was something done on the
side; but now it's time to come up with _something_ off the cuff) but
almost total unfamiliarity with the concept of algorithmic complexity
(yikes!). Open mouth, insert foot.
In the absence of the package in question, I might never have quizzed
the candidate about complexity.
I recommended against hiring this candidate.
Andrew
Andrew Philpot <·······@isi.edu> writes:
> Just a note on the assumption underlying this thread that authoring
> open-source software can _only_ improve one's standing with a
> prospective employer. I maintain that it can instead raise the bar
> in unanticipated ;-) ways.
>
> I once interviewed a candidate who had written a well-done and not
> unknown publically available Lisp package that I had heard of and in
> fact I had browsed prior to the interview. Since we were familiar
> with the candidate's work, I was able to skip some of the standard
> vague interview fodder ("if you were a Lisp special-operator, which
> one would you be?") and cut right to the chase.
>
> In short order, I asked the candidate to discuss the algorithmic
> complexity of one of the major tasks within the application. The
> answer revealed unfamiliarity not only with algorithmic analysis of
> the code (perhaps understandable since this was something done on the
> side; but now it's time to come up with _something_ off the cuff) but
> almost total unfamiliarity with the concept of algorithmic complexity
> (yikes!). Open mouth, insert foot.
>
> In the absence of the package in question, I might never have quizzed
> the candidate about complexity.
>
> I recommended against hiring this candidate.
Similar issues have been reported about people posting to usenet
newsgroups another kind of 'open' architecture. Heh. Information
is double-edged.
Another potential negative is that it raises the issue of whether you
will destabilize the interpersonal ecology of a company. I'd bet most
free software companies can tolerate people who are not die-hard free
software advocates, and most proprietary houses can tolerate people
who aren't die-hard fans of proprietary software. What matters isn't
your personal political leanings but whether you can do your job. The
problem is that some people are blinded by their politics to not be
able to do the job they've signed up for, and the hiring process wants
to detect this early to avoid problems. Ultimately, an employer will
expect you to follow the plan that the company chooses, and if it
senses that you might not do that, don't expect that to make you a
better job candidate [regardless of which way you lean].
Most companies maintain an internal power structure. Fight that
structure, or make them fear you might, and you might either win big
or lose big, but you're not likely to find a warm and fuzzy middle
ground. On an annual review at one company I worked at, I was told by
the president of the company "You have a lot of ideas, but we like you
anyway." Hmmm. You can just imagine how comforting I found that.
On 18 Mar 2003 01:58:06 GMT, Andrew Philpot <·······@isi.edu> wrote:
> Just a note on the assumption underlying this thread that authoring
> open-source software can _only_ improve one's standing with a
> prospective employer. I maintain that it can instead raise the bar
> in unanticipated ;-) ways.
>
> I once interviewed a candidate who had written a well-done and not
> unknown publically available Lisp package that I had heard of and in
[...]
> In short order, I asked the candidate to discuss the algorithmic
> complexity of one of the major tasks within the application. The
> answer revealed unfamiliarity not only with algorithmic analysis of
> the code (perhaps understandable since this was something done on the
> side; but now it's time to come up with _something_ off the cuff) but
> almost total unfamiliarity with the concept of algorithmic complexity
> (yikes!). Open mouth, insert foot.
[...]
> I recommended against hiring this candidate.
Suppose a candidate doesn't mention in his resume his contribution to an
open-source project. How would this affect--if at all--your way of
interviewing him, and your recommendation on on whether to hire him or not?
Paolo
--
Paolo Amoroso <·······@mclink.it>
>>>>> "Burton" == Burton Samograd <······@hotmail.com> writes:
Burton> On 2003-03-17, Raymond Toy <···@rtp.ericsson.se> wrote:
>> If HR can't cut through the crap resumes today, what makes you think
>> they can tell the difference between a successful opensource project
>> from any other project? They probably don't even know of any
>> opensource projects.
Burton> I'm thinking more along the lines of those small businesses that lack
Burton> the standard HR department. Think of someplace small that needs to
Burton> recruit people for a type of project but are tight on funds or just
Burton> don't trust headhunters. Doing a search for a certain type of project
Burton> and then contacting the developers/maintainers seems like a good
Burton> initial way to get a list of contacts, plus you they the chance to
Burton> look at the quality of the work at the same time.
Burton> A dream maybe, but it makes sense to me.
Well, small companies probably don't really have an HR department.
Developers/maintainers probably get to see every resume.
>> I think the HR people I've worked with just pass any resume that was
>> submitted for that particular job on to me. Which is the way it
>> should be.
Burton> It should be, but it didn't seem to work that way at some of the
Burton> places I've been. I think the important thing is how they picked that
Burton> group resumes out of the prospective pile, and I have a hard time
Burton> believing that they will pick the "best" candidates for your
Burton> consideration.
For me, I think anything that had the appropriate "keywords" or
experience with any related processor would get passed on to me. I
doubt the HR would have a clue what any of those things really meant
other than I was interested in people with those keywords.
And considering that I probably couldn't pick the "best" candidate out
of a pile without at least a phone interview[1], I can hardly expect HR
to do that either. :-)
Which, again, is the way it should be.
Ray
Footnotes:
[1] People do lie on resumes, and phone interviews help weed those
out, but I doubt if I could pick out the habitual, well-practiced
liar.
Burton Samograd wrote:
> I don't know if people are being "taught" that contributing free
> software is good, but I do think that programming is moving more
> towards the "I say I do this" to "look at what I have done". Someone
> else pointed out that the guys that developed apache can charge more
> (or at least get some work) because they can point out "look, I wrote
> apache, so if you don't trust what I say about my experience, have a
> look for yourself".
>
> This is similar to almost every other "artistic" field, where people
> build and present portfolios of thier work. One of the biggest
> complaints about the job market today is that the HR people have no
> idea what they are looking for and find it impossible to cut through
> the crap resume's that are flooding them. Creating an opensource
> project that happens to be sucessful is a quick way to cut through
> that crap, or at least get your name closer to being one that people
> come to rather than you going out to them with all the others.
The HR people (and almost everyone else involved in the hiring process)
can't tell good software from bad, and companies often don't even
/count/ spare-time (open source, or whatever) software development as
useful experience. Not one company has ever asked to see a sample
of my work. And read my .sig if you're under any illusions that
hiring the best people for the job is commonplace. It was written
in 1986 and things have got worse since then.
Also, while we both know that programming is an art (or a craft), it's
regarded in industry (wrongly, IMO) as engineering.
> Free software is not better than non-free software depending upon the
> purpose, but it does form some sort of public intership where you can
> show that you're proud enough of what you do that you will put out
> your work for all to see. It also can show how you work in a team
> environment, because as i'm sure we all know, working with other
> developers can be quite trying at times.
>
> But I think that if someone develops something for fun, in some sort
> of pseudo independant intership that does happen to outperform a
> commercial product, then yes, those people that just got put out of
> business did deserve it. Skills and technology move on, so if somone
> with less experience that is just trying to prove themselves can
> develop a better product...
Outperforming a commercial product won't necessarily get you market
share. Also, most companies don't /like/ open source, which they
perceive (however wrongly) as insecure, and largely unsupported.
They'd rather buy from a company they've heard of than get the same
thing, free, from someone they haven't.
> > People are not taught, I claim, that there might be better and worse
> > places to contribute free software depending on whether there are already
> > vendors in the market, or likely to be, and whether those people are
> > charging a fair price.
>
> As I said, I think contributing to free software is completely
> selfish, especially in the market right now where everybody is trying
> to get ahead. When trying to improve yourself you don't worry about
> who you might put out of business, especially when you are out of work
> and broke.
The problem is that it doesn't pay the bills, while allowing commercial
organizations to use your software without paying you for it. An out
of work and broke programmer might understandibly not wish to do that.
There is an alternative, which has all the benefits of open source
but few of the drawbacks -- release your software, including source,
on a viral licence which prohibits commercial use. That way, you
can also charge for commercial use if any companies are ever
interested, which is not an option if the software is open-sourced.
If you tried it, you'd very quickly be undercut by someone else
giving away /your/ software.
I'm not saying there's no place for open-source. It's fine
for software which has no important innovative features, or
no commercial value, or as a free add-on to something not
open source. But companies should not take free software for
granted. The open-source model is sharing -- taking, yes, but
giving back too.
> But that is the nature of competition. If these companies feel like
> they are being put out of business by some out of work programmers
> with too much time on thier hands that happen to be developing a
> better and free version of thier product, they should be hiring those
> people to help them make a better product.
Again, a better product won't necessarily mean more sales.
It might just mean that you are appealing to the small minority of
people who have good taste.
> > In my personal experience, free software is more likely not to work usefully
> > off-the-shelf that commercial software. And in my experience, few companies
> > treat their customers as pirates.
>
> Hmmm...I beg to differ on that. Any actual useful product that
> doesn't treat thier customers like pirates (with dongles, license
> files that cause the software to run if you have a drive crash and
> didn't have a backup, etc) don't have free alternatives, mostly
> because they are difficult programs to write that fill a niche market.
This I'm inclined to agree with you on, and disagree with Kent,
though I've only a limited perspective. I've only seen closed
source software in the companies I've worked for, and it's been of
almost uniformly poorer quality than the software I've seen for
which the source was supplied. And with a little reflection it's
not hard to see why. Companies produce software to deadlines,
which if unrealistic cause stress, which is a major source of bugs.
It's reviewed against arbitrary "coding standards" which often
mean checking minor issues of style, rather than checking for
bugs, performance bottlenecks and elegance. It's written by
people who are doing it for money rather than because they like
doing it. It's designed and built top-down, and tested just
before shipping, rather than bottom up and tested early on.
And, worst of all, once it appears to work, it's left as it
is, rather than tidied up. Then the company flaunts its
ISO-9000 certification.
> burton samograd
Le Hibou
--
In any large organization, mediocrity is almost by definition
an overwhelming phenomenon; the systematic disqualification
of competence, however, is the managers' own invention, for
the sad consequences of which they should bear the full blame.
-- Edsger W. Dijkstra, 1986.
From: Christopher C. Stacy
Subject: Re: Learning new things
Date:
Message-ID: <u8yvdakng.fsf@dtpq.com>
>>>>> On 17 Mar 2003 12:58:48 -0500, Greg Menke ("Greg") writes:
Greg> Free software wouldn't exist if commercial vendors didn't tend towards evil.
[...]
Greg> Yet Microsoft and Oracle routinely do this
If you think that all commercial vendors are Microsoft and Oracle,
and you don't like the way that they behave, why would you argue
that there shouldn't be other commercial software vendors to compete
with them? Perhaps they would behave differently.
Would you behave differently than Microsoft and Oracle?
* Greg Menke wrote:
> If software companies started treating their customers like car
> companies treat theirs I think the software racket would be much
> improved. When was the last time a car company tried to legally
> prevent their customers from talking about their product's
> performance?
Well, I suspect the whole SUV issue might be quite interesting to look
at from that perspective, actually.
--tim
Kent M Pitman wrote:
> And this is a general risk of free software, in my opinion.
> It completely undercuts a legitimate sales market. It annexes side
> markets that can be used to recover the market, but in so doing it
> does not allow normal capitalistic survival of the fittest to operate
> because what you are now testing is whether "their browser + their
> support" is better than "my
> browser + my support". You aren't factoring things out so that you
> find out if my browser might have been better (perhaps with their
> support).
"And this is a general risk of the horseless carriage, in my opinion. It
completely undercuts a legitimate transportation market."
Free software involves risks, but who's suffering them? Ordinarily, I'd
expect the "risk of free software" to be one that endangers free
software itself, a risk *to* free software. But that's not what you're
arguing. Free software seems to be endangering some greater good -- "a
legitimate sales market". Now, while this market is surely legitimate,
those who enter it don't have an inalienable right to make a profit.
They don't have a right to be protected against obsolescence of their
market.
The playing field of commercial software isn't level to start with. But
it's skewed in a way that the players are accustomed to. Free software
has extended the game to the audience. Apparently to the dismay of the
pros who thought their's was the only (legitimate?) game in town.
Several times I've read positions essentially arguing that it was not
fair that free software was sometimes subsidized by research money. In
my view, this conveniently ignores how much commercial software is
indebted to research spending. What with all those spin-offs from
academic institution?
Michael
--
Michael Schuerig All good people read good books
···············@acm.org Now your conscience is clear
http://www.schuerig.de/michael/ --Tanita Tikaram, "Twist In My Sobriety"
Kent M Pitman <······@world.std.com> writes:
[snip about Allegro bundling a web-server]
>
> And this is a general risk of free software, in my opinion.
> It completely undercuts a legitimate sales market. It annexes side markets
> that can be used to recover the market, but in so doing it does not allow
> normal capitalistic survival of the fittest to operate because what you are
> now testing is whether "their browser + their support" is better than "my
> browser + my support". You aren't factoring things out so that you find
> out if my browser might have been better (perhaps with their support).
>
> And the people at Franz are my friends!
[snip-snip]
This (apart from the last line) reminds me of complaints I have seen
about Microsoft and Apple. Stuff (multimedia, browsers, utilities ...)
gets bundled in the OS, and suddenly a bunch of small vendors are out
in the cold. The PC and Mac markets have *LOTS* of vendors of
cheap/shareware utilities that fall victim to this all the time.
Analysis I have seen term this as "short sighted developer relations"
and this has been cited as one of the reasons for Apple coming to the
brink of bankruptcy every few years, viz: Small developers are driven
out of business and/or sour to the platform -> The liveliness of the
Mac disappears -> users fall out of love with the platform.
I think you could have handled the competition from CL-HTTP, it was
Allegro-serve that pulled the rug from under you.
--
H�kon Alstadheim, hjemmepappa.
······@online.no (H�kon Alstadheim) writes:
> Kent M Pitman <······@world.std.com> writes:
> > And this is a general risk of free software, in my opinion.
> > It completely undercuts a legitimate sales market. It annexes side markets
> > that can be used to recover the market, but in so doing it does not allow
> > normal capitalistic survival of the fittest to operate because what you are
> > now testing is whether "their browser + their support" is better than "my
> > browser + my support". You aren't factoring things out so that you find
> > out if my browser might have been better (perhaps with their support).
>
> This (apart from the last line) reminds me of complaints I have seen
> about Microsoft and Apple. Stuff (multimedia, browsers, utilities ...)
> gets bundled in the OS, and suddenly a bunch of small vendors are out
> in the cold. The PC and Mac markets have *LOTS* of vendors of
> cheap/shareware utilities that fall victim to this all the time.
> Analysis I have seen term this as "short sighted developer relations"
> and this has been cited as one of the reasons for Apple coming to the
> brink of bankruptcy every few years, viz: Small developers are driven
> out of business and/or sour to the platform -> The liveliness of the
> Mac disappears -> users fall out of love with the platform.
Yes, I have said of the Microsoft thing that much of the competition problem
is control over a vertical market by someone who has a for-whatever-reason
monopoly on some layer. (That is, some monopolies are illegal and some
ar considered 'natural'. Even if you allow for argument's sake that the
Microsoft OS platform monopoly is a 'natural monopoly', it's still a
stranglehold on the next layer.) When there are products to be built atop
that layer, the players at the next layer are crippled by their lack of
knowledge of the internals.
Microsoft asserts that it is necessary to build the support for a browser
down into the operating system. I'd say "ok, let them" but you must
publish any underlying specs that are that support and then you must not
enter the market yourself with your own rendition until a reasonable time
(say, "6 months") has been allowed for your competition to absorb these
specs. That might even mean you enter at a time AFTER your competition,
but that's the price of having gotten to design the underlying interface.
Having done this, you would have [close to] fair, de-coupled competition
of the layered product and the layered product could win or lose on its
own merit under capitalistic/darwinian effects. If you bundle things, then
capitalism is selecting "best bundle" not "best browser". Of course, if
you didn't like these rules, then you could stop building stuff into the
operating system to specially favor your product. Then you could enter
the layered market at the same time as everyone else. But then you would
be entering without special knowledge that your opponent did not have.
This discussion of Microsoft is a bit off topic, but is relevant as a
way of illustrating my underlying point, which is that I believe in
capitalism's ability to sort out only those things it is directly
pointed at.
H�kon Alstadheim wrote:
> Kent M Pitman <······@world.std.com> writes:
> [snip about Allegro bundling a web-server]
>
[snip-snip-snip]
>>And the people at Franz are my friends!
>
> [snip-snip]
>
> This (apart from the last line) reminds me of complaints I have seen
> about Microsoft and Apple. Stuff (multimedia, browsers, utilities ...)
> gets bundled in the OS, and suddenly a bunch of small vendors are out
> in the cold.
1. A big app with a big, general audience (say, a PowerPoint knock-off)
requires a kazillion features and VC to fund a big, long marketing
effort. And it may attract the Free crowd. So little developers should
avoid these.
2. A commodity item like a web-server? Fuggedaboutit. Hell, someone
might give one away as a loss leader. :(
3. Read my lips: vertical markets. I knew a guy did well with a custom
auto dealer system, I have seen health-club-specific systems, etc etc.
Go out a lot, join the Moose Lodge, meet a businessman who hates their
system, make a deal to write a better one on spec (fixed price, due on
delivery), you keep the rights to sell to others. The neat thing is that
adding simple features specific to the niche is easy but adds a lot of
perceived value.
The FSF does not want to do Visual Mortician, nor will Franz or Bill.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
Kenny Tilton <·······@nyc.rr.com> writes:
>
> The FSF does not want to do Visual Mortician, nor will Franz or Bill.
You never know, with all the good press that 6 feet under is getting
marc
>
> --
>
> kenny tilton
> clinisys, inc
> http://www.tilton-technology.com/
> ---------------------------------------------------------------
> "Cells let us walk, talk, think, make love and realize
> the bath water is cold." -- Lorraine Lee Cudmore
Ray Ozzie (of Lotus Notes and Groove) claims that the platform owner
will inevitably conflict with its "ecosystem" of 3rd party apps and
services. If not, the platform is managed badly.
http://www.ozzie.net/blog/stories/2002/09/03/toJoelOnPlatforms.html
As to Kent's point about there needs to be open specs about things
like building web browsers into an OS, I vaguely recall that Netscape
was claiming that the web browser would /be/ the OS, reducing Windows
to "a poorly debugged set of device drivers." So at what point was
Netscape a competitor to Windows, instead of just another app?
Obviously, there's a more general and valid point here, just this
specific example was not clear to me.
Tj
······@online.no (H�kon Alstadheim) wrote in message news:<··············@alstadhome.dyndns.org>...
> This (apart from the last line) reminds me of complaints I have seen
> about Microsoft and Apple. Stuff (multimedia, browsers, utilities ...)
> gets bundled in the OS, and suddenly a bunch of small vendors are out
> in the cold. The PC and Mac markets have *LOTS* of vendors of
> cheap/shareware utilities that fall victim to this all the time.
> Analysis I have seen term this as "short sighted developer relations"
> and this has been cited as one of the reasons for Apple coming to the
> brink of bankruptcy every few years, viz: Small developers are driven
> out of business and/or sour to the platform -> The liveliness of the
> Mac disappears -> users fall out of love with the platform.
··········@yahoo.com (Tj) writes:
> As to Kent's point about there needs to be open specs about things
> like building web browsers into an OS, I vaguely recall that Netscape
> was claiming that the web browser would /be/ the OS, reducing Windows
> to "a poorly debugged set of device drivers." So at what point was
> Netscape a competitor to Windows, instead of just another app?
Well, it looks to me like you're getting faked out by names in
asking this question. The relevant issues stand even if there are gensyms
in place.
Microsoft builds product #:G0001 on which Netscape's #:G0010 and
Microsoft's product #:G0011 depends.
Layer #:L0002 #:G0010, #:G0011
--------------------------------------
Layer #:L0001 #:G0001
Netscape claims that the name "Operating System" can eventually be
removed from Layer #:L0001 and moved to Layer #:L0002, leaving
Layer #:L0001 labeled "Device Drivers" (and, allegedly/coincidentally,
buggy).
It looks to me like Netscape is a competitor to Microsoft, but #:G0010
is not a competitor to #:G0001. Rather, #:G0010 is a competitor to #:G0011.
Or, at least, that's how I'd do the analysis.
I think the court did a great many interesting and reasonable things before
having its opinion blown away on appeal, but one thing I think it did wrong
was to worry about what an operating system was and wasn't. That wasn't
the issue at all. What really is the issue is having any vendor involved
at two levels of a vertical tower.
Kent M Pitman <······@world.std.com> wrote in message news:<···············@shell01.TheWorld.com>...
> It looks to me like Netscape is a competitor to Microsoft, but #:G0010
> is not a competitor to #:G0001. Rather, #:G0010 is a competitor to #:G0011.
>
> Or, at least, that's how I'd do the analysis.
Well, I see a competitor as someone who reduces the value of your
brand, competing against whatever brand it's damaging. Had Netscape
taken the role of consistent interface + program launcher from
Windows, Microsoft would be forced to price Windows less. Further,
Windows would be increasingly commoditized as Java applications
replaced Windows apps.
Litmus test: Before MS' browser existed, was Netscape still perceived
as a competitor?
Of course, I think at some point, experienced people at Microsoft were
thinking, "Gee, this seems nuts." After all, did Netscape and Sun
know how to manage a consumer platform? But I think the paranoia was
justified; to some extent, the web has helped commoditize Windows. I
do use webapps, just not Java applets.
I agree that MSFT often does vicious, perhaps illegal things, but the
Netscape issue is not crystal-clear to me.
Tj
On 2003-03-17, Adam Warner <······@consulting.net.nz> wrote:
> Hi Burton Samograd,
> You completely missed the point being made in the thread :-) It's not a
> bad language to implement the task in. You just won't make any money doing
> it. A lot of software is now a commodity. Web browsers, servers, whole
> operating systems, languages, compilers and editors. If one is looking to
> make money selling proprietary software the idea should be innovative
> enough to provide a window where one will not be directly competing with
> preexisting free/open source/inexpensive commodity software.
I was away for the weekend so I guess I didn't miss the point, just
lost track the thread in my head. I just have to say that I'm curious
about the limitations of lisp (if there are any) with regards to
things that are pertinent to the issues that are important to
implementation (string parsing, etc) and thought you might be able to
point out some examples. I'm sure I'll come up with some more
concrete questions after I do some more reading and testing.
--
burton samograd
······@hotmail.com
http://kruhftwerk.dydns.org
* Michael Travers wrote:
> I'm sure there are others that I don't know about. The question is,
> why aren't there more? If Lisp really makes small teams so much more
> productive, it should be the ideal vehicle for startup software
> companies. Maybe you are right and it's the combative nature and
> un-economic instincts of Lisp programmers in general that stand in the
> way.
I think there's a terrible lesson here: software productivity doesn't
matter very much.
*Why* it doesn't matter is an interesting question. There are several
reasons. One is that almost all software is junk, and producing junk
faster doesn't help you very much. If all the do.coms could have
produced their websites four times as fast, would it have helped them
actually work any better? Probably not: you have to write non-junk
code to do that, not junk code faster. Of the software that isn't
junk, the vast majority never makes any money for reasons unrelated to
the quality of the software: for instance there just is no money to be
made. Again, if dot.coms had produced working websites faster, would
this have altered the fact that, actually, there was no money to be
made? Not really. Software lends itself to natural monopolies of
interface, as well as code: unless you get to set the standards, you
will just end up spending your life chasing the standards set by other
people. And the time in which you get to set the standards is really
short: implementing a good lisp-based web server in 1994 would have
been really compelling, by 1996 it was much less so, and doing it
after 1999 was, basically, a waste of time. Finally, complexity
issues kill linear productivity gains - once the number of programmers
you need goes above a very small number (I propose four, but probably
it's ten), the complexity of the system starts hurting you really
badly, and you need bureaucracies like anything Rational sell just to
keep up. Even if you can avoid the large-team problems, you rapidly
find that areas develop into bureaucracies which you can't ever hope
to keep up with: does anyone *really* understand all the standards and
quasistandards around XML? Has anyone even *read* them all? I
suspect XML has collapsed under its own weight by now, but last time I
looked I was fairly convinced that I could not read the standards as
fast as they were being pushed out.
It's about six months. You need to find a good, new, idea and jump on
it and - if you are lucky - you have about six months before someone
else gets there. In that window you can write the system you want to
in the language you want to, without any encrustations of complexity
or preexisting standards, and set the standards that other people will
follow. If you can do this, then you will absolutely win with Lisp
because you will get there in four months instead of six, and once
you've got there then everyone else will be following your
standards. If you can't, you might as well use Cobol.
This is what Paul Graham did: spot the good idea, implement the
system, and sell it, a few months ahead of everyone else.
Of course, finding the good ideas and the clear water is the hard bit.
If I told you what they are then I'd have to deploy the usenet
neuralizer, again, and I really can't afford the power bills that
involves. But anyone can tell you some things they aren't: another
lisp system; libraries for lisp; another C compiler; an operating
system; anything to do with the web.
--tim
I think there's a terrible lesson here: software productivity
doesn't matter very much.
No, you're being circular. To use loaded language: capital doesn't
know how to take advantage of software productivityk, and capital
can't be educated, therefore software productivity doesn't matter
much.
But if capital were smarter:
*Why* it doesn't matter is an interesting question. There are
several reasons. One is that almost all software is junk, and
producing junk faster doesn't help you very much. If all the
do.coms could have produced their websites four times as fast,
would it have helped them actually work any better? Probably
not: you have to write non-junk code to do that, not junk code
faster.
You could easily be very, very wrong.
Your argument is based on the premise that *.com companies speced a
site, then built it, then failed. And then you say that, well, it
wouldn't have made any difference if they built it for twice as much
money but 2/3 the time.
Ok ... but that's the wrong way to look at it.
Collectively, the *.com companies ran 1,000 experiments. Of those, 2%
paid off big (e.g. ebay).
What if it were all done by lisp hackers?
Making up some numbers but not without reason: The first 200 hundred
experiments in lisp would have cost as much as the first 400
experiments in other systems. The next 4,800 in lisp would cost as
much as the next 600 in other systems because the lisp hackers spent
their initial investment on a better foundation. There'd be 5x as
many *.com survivors if they'd used lisp. 5x as many profitable
businesses based on the same initial investment.
(Of course, I'm saying "used lisp" in deference to this list -- it's
really more general than that -- something like "used high-quality
engineering", which on this list we presume lisp hackers typify, and
know that lisp is a good tool for.)
Just a reminder that design matters....
"till it reaches the `hard crack' stage..."
-t
* Tom Lord wrote:
> No, you're being circular. To use loaded language: capital doesn't
> know how to take advantage of software productivityk, and capital
> can't be educated, therefore software productivity doesn't matter
> much.
No, I disagree. Most people who write, or organise the writing of,
software either produce stuff that is just rubbish, or produce stuff
that is good but could never make money. Don't blame some nebulous
`capital', blame us, because it's our fault.
> Making up some numbers but not without reason: The first 200 hundred
> experiments in lisp would have cost as much as the first 400
> experiments in other systems. The next 4,800 in lisp would cost as
> much as the next 600 in other systems because the lisp hackers spent
> their initial investment on a better foundation. There'd be 5x as
> many *.com survivors if they'd used lisp. 5x as many profitable
> businesses based on the same initial investment.
This is likely true. However it's only true if Lisp (or whatever)
could have got into the six month window and set the standards. Once
you've missed that, then it's just playing catch-up. Of course it
wouldn't have made much difference to the underlying problem: it was a
bubble (or the last stages of a long high-tech bubble), and there
actually wasn't any significant money to be made.
--tim
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 2003-03-14, Tim Bradshaw <···@cley.com> wrote:
> No, I disagree. Most people who write, or organise the writing of,
> software either produce stuff that is just rubbish, or produce stuff
> that is good but could never make money. Don't blame some nebulous
> `capital', blame us, because it's our fault.
After reading this thread for a while I feel like putting in my
pennies. After doing game and application development for almost 10
years I would have to agree with the above "all software is rubbish"
attitude. Like every programmer, I feel that my software is "great",
while the work (most) others complete crap, they don't know how to
design, they don't know available tools, they don't etc.
But on the flip side, I've had the chance to work on medium size
projects (a gameboy game, engine and tools and an anti-spam SMTP
server) pretty much completely by myself coding wise. Under this
environment I took the time to "do things right" and the code, IMHO,
was very good and the resulting design and implementation were close
to the best that I could do with my skills at the time.
But the products were still crap, because when I work as a
"programmer", I don't (can't?) designing the application requirements
because my head is fully wrapped around the programming problem and I
*demand* that the requirements are given to me so that I can implement
them. I think that people can do more than one job; programmers can
be good designers and vice versa BUT NOT ON THE SAME PROJECT.
Unfortunately, it has been my experience that when you hand off the
responsibility of design requirements to non-programmers they are
either:
a) so lofty and filled with grand sweeping changes at random parts of
the project you cannot do system design due to time constraints
b) the initial requirements are "brainstorms" which give a quick flush
out of the main ideas but nobody ever goes back to finalize them thus
leaving a half complete program infrastructure that never gets filled
in
Most of the professional work I've done has been in C or Assembly, and
I think that I have come close to reaching my limits for those types
of languages. It is impossible to do design and implementation as a
single person (whether you want to or not). But, each person wants to
be the designer and programmer on their part of the project, which
leads to a boatload of differing code styles (not just bracketing
styles, but major things like memory usage, data structures, leaky
memory, etc) as everybody does their part "the best way".
I'm going on to (or back to) lisp/scheme because it seems to lift
these limits and let you do desing and implementation *at the same
time*. Whether you call it prototyping or rapid development or
Extreme Hacking With Portable Interpreted Continuation Passing or what
have you, lisp, even at it's lowest level seems to help me organize my
thoughts such that implementation comes out of design. This is not
the way it works with C, or at least not for me, and I really do think
that I'm a Damn Good C Programmer (TM) (And for doubters you can look
at my open source SMTP server and form your own opinions).
I've been spending my years in and out of work honing my programming
skills, design skills and learning all the book keeping tricks for
procedural programming while still trying to write efficient, clean,
extendable and maintainble programs...and I can't, or at least to what
I want to be able to. There is something wrong with that and I think
it's time to look (or relearn) other options.
I want to start making software that isn't rubbish. I think that can
come from using lisp/scheme with an easy to use and well documented
FFI that allows me to write the structure in lisp and the low
level/heavy lifting in C. Programs should not be written in C,
libraries should. Adapting to constantly changing requirements is
virtually impossible in those languages, but seem to be "just another
feature" of functional languages.
Ok, that was a bit longer than I thought it would be, but I hope I get
my opinions across. I hope some day to write software that makes
money, but I think my dream is just to be able to write something that
isn't garbage because "other people" can't do their jobs (programming
or design wise).
- --
burton samograd
······@hotmail.com
http://kruhftwerk.dydns.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+chT8Lq/0KC7fYbURAia5AKCHuc+7aJL5jF2F8SP6V/Hh/QLizgCePyrN
MvgtNX3xGIhh+k0jpvMy69U=
=2unU
-----END PGP SIGNATURE-----
Burton Samograd <······@hotmail.com> writes:
> On 2003-03-14, Tim Bradshaw <···@cley.com> wrote:
> > No, I disagree. Most people who write, or organise the writing of,
> > software either produce stuff that is just rubbish, or produce stuff
> > that is good but could never make money. Don't blame some nebulous
> > `capital', blame us, because it's our fault.
>
> After reading this thread for a while I feel like putting in my
> pennies. After doing game and application development for almost 10
> years I would have to agree with the above "all software is rubbish"
> attitude. Like every programmer, I feel that my software is "great",
> while the work (most) others complete crap, they don't know how to
> design, they don't know available tools, they don't etc.
Thinking of oneself as beeing great is calling for havoc. And in fact
it us unfair to everyone trying to do his/her best. I always assume
that programmers want to do their best, and hell I have seen code
which is beautiful and I have seen code that's ugly. I myself have
written a bunch of s.... and on the other hand very nice
programs. I want to write nice and "high quality" code, the usual
cycle is that I get something running and after that I see how ugly my
solution really is than I re-write that solution to come closer to
what I think it "high quality" after the next cycle I see again where
I could have done better. Does this make my first code dispensble. No
without it I do not had any clue. No the point is to come back to
ones code later and be willing to rework it. Probably this is the
point one comes back to seldom.
Regards
Friedrich
On 2003-03-17, Friedrich Dominicus <·····@q-software-solutions.com> wrote:
> Thinking of oneself as beeing great is calling for havoc. And in fact
> it us unfair to everyone trying to do his/her best. I always assume
> that programmers want to do their best, and hell I have seen code
> which is beautiful and I have seen code that's ugly. I myself have
> written a bunch of s.... and on the other hand very nice
> programs. I want to write nice and "high quality" code, the usual
> cycle is that I get something running and after that I see how ugly my
> solution really is than I re-write that solution to come closer to
> what I think it "high quality" after the next cycle I see again where
> I could have done better. Does this make my first code dispensble. No
> without it I do not had any clue. No the point is to come back to
> ones code later and be willing to rework it. Probably this is the
> point one comes back to seldom.
Well, I did put great in quotes, which was to mean that I think my own
work is the best I can do, but I still think there is much room for
improvement...but...I rarely see code that is as "good" as mine
(notice the quotes) so it leads one to think that, although my code is
not the best it seems much better than the "crap" that I see normally,
so I must be great....
Isn't logic fun? :)
I am totally in agreement with you about the iterative programming
argument, which is why I am moving more towards rapid development
(shell scripts, lisp, scheme) to get my ideas flowing and something
working well, since those are the most important things (to me). I
almost never save any of the code I write as it seems that once I've
written it, it will take me about 1/10th the time to rewrite it if I
need to, plus I'll have the added experience of doing whatever I did
in between the writings so it will have to be better...right?
But for actual reuse most of the major applications I've written
always start with library design and implementation and then the
actual code for the program. Usually the libraries are well designed
and clean (what I would consider at least "good" code) and then
there's the abomination which would be the application code, which
I "blame" on shifting requirements, feature creep and those things
that you just can't predict but always seem to happen in "real world
programming".
But in the end, I hate going back to old code and making it work again
because of the difference in mindsets and experience between the
inital writing and when you have to reuse it. Generally, for me, it
takes less time to take those lessons and reimplement as compared to
figuring out the old code again and then dealing with the bugs that
crop up since you are using it in a different way than it was
originally intended, due to lack of time for complete testing of the
original library.
--
burton samograd
······@hotmail.com
http://kruhftwerk.dydns.org
····@emf.emf.net (Tom Lord) writes:
> Your argument is based on the premise that *.com companies speced a
> site, then built it, then failed. And then you say that, well, it
> wouldn't have made any difference if they built it for twice as much
> money but 2/3 the time.
Most .com startups tanked because what they offered was banal, useless, and
time-wasting, plain and simple.
How you implement your idea is irrelevant if it is complete crap.
The internet, at least at the moment, is fundamentally useful for only a few
kinds of things, mostly centered around people talking to each other, dealing
with information, etc.
I will not ever shop for clothes on line, for example. I need to be in a store
and try things on.
On the other hand I have bought my car on line, sort of. I got introduced to
the appropriate dealer via the net, but from then on further negotiations
proceeded in the usual way.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@telus.net The Rhythm has my soul.
Tim Bradshaw <···@cley.com> writes:
> * Michael Travers wrote:
>
> > I'm sure there are others that I don't know about. The question is,
> > why aren't there more? If Lisp really makes small teams so much more
> > productive, it should be the ideal vehicle for startup software
> > companies. Maybe you are right and it's the combative nature and
> > un-economic instincts of Lisp programmers in general that stand in the
> > way.
>
> I think there's a terrible lesson here: software productivity doesn't
> matter very much.
Well that would suggest why people are not willing to buy software...
>
> *Why* it doesn't matter is an interesting question. There are several
> reasons. One is that almost all software is junk, and producing junk
> faster doesn't help you very much.
This is ridicolous and you know that.
> It's about six months. You need to find a good, new, idea and jump on
> it and - if you are lucky - you have about six months before someone
> else gets there.
Well the are countless counterexamples. It's often not best to be the
first but the second with a product. Anyone remembers Multiplan?
> In that window you can write the system you want to
> in the language you want to, without any encrustations of complexity
> or preexisting standards, and set the standards that other people will
> follow. If you can do this, then you will absolutely win with Lisp
> because you will get there in four months instead of six, and once
> you've got there then everyone else will be following your
> standards.
You will there as fast with other languages and many more libraries.
> But anyone can tell you some things they aren't: another
> lisp system; libraries for lisp; another C compiler; an operating
> system; anything to do with the web.
I disagree about anything to do with the web, the point about the
libraries for Lisp is what I critizesed elsewhere. And by chance we do
offer "just another C-Compiler" and it has helped you quite much to
have it.
Regards
Friedrich
* Friedrich Dominicus wrote:
> Tim Bradshaw <···@cley.com> writes:
>> *Why* it doesn't matter is an interesting question. There are several
>> reasons. One is that almost all software is junk, and producing junk
>> faster doesn't help you very much.
> This is ridicolous and you know that.
No, I don't. Almost all the SW I've looked at has been junk, and I've
looked at really a lot. Do you have a different experience?
> You will there as fast with other languages and many more libraries.
You haven't understood. You don't *need* the billion libraries unless
you are keeping up with a bureaucracy. In 1992 you could write a
state-of-the-art web server using sockets and file IO and exec. You
can write a web server like this in CL in a *day* (once you get over
the whining about the few lines of implementation dependent code you
need). I've written such a server. But in 2003 if you want to write
a state-of-the-art web server how many standards do you need to
interface to? A hundred? A thousand?
> And by chance we do offer "just another C-Compiler" and it has
> helped you quite much to have it.
Again, you've missed the point. There was a time when writing another
C compiler was a good thing to do. That time is not now.
Never mind, I didn't expect people to understand.
--tim
Tim Bradshaw <···@cley.com> writes:
> * Friedrich Dominicus wrote:
> > Tim Bradshaw <···@cley.com> writes:
> >> *Why* it doesn't matter is an interesting question. There are several
> >> reasons. One is that almost all software is junk, and producing junk
> >> faster doesn't help you very much.
> > This is ridicolous and you know that.
>
> No, I don't. Almost all the SW I've looked at has been junk, and I've
> looked at really a lot. Do you have a different experience?
I work with that "junk" all the day. I'm using Debian/Linux, and run
vmware on it with Windows XP in it. My all-day-editor is (X)Emacs and
I use numerous tools every day starting from cd over ls to such
"obscure" things like Common Lisp. All this software is the
counterexample for me. And you could not do anything if all software
would be junk.
>
> > You will there as fast with other languages and many more libraries.
>
> You haven't understood. You don't *need* the billion libraries unless
> you are keeping up with a bureaucracy. In 1992 you could write a
> state-of-the-art web server using sockets and file IO and exec. You
> can write a web server like this in CL in a *day* (once you get over
> the whining about the few lines of implementation dependent code you
> need). I've written such a server. But in 2003 if you want to write
> a state-of-the-art web server how many standards do you need to
> interface to? A hundred? A thousand?
Well I would assume you do not have understand. I do need a bunch of
libraries to get my work done, I find this libraries easily in other
languages but Lisp and they usually work. Now I asked for libraries
for Common Lisp which I can use, and for which I'm willing to pay!
>
> > And by chance we do offer "just another C-Compiler" and it has
> > helped you quite much to have it.
>
> Again, you've missed the point. There was a time when writing another
> C compiler was a good thing to do. That time is not now.
Well what do you think which time is now?
>
> Never mind, I didn't expect people to understand.
Sorry you don't try very hard and did not answer the questions asked,
so how should one understand?
Regards
Friedrich
* Friedrich Dominicus wrote:
> I work with that "junk" all the day. I'm using Debian/Linux, and run
> vmware on it with Windows XP in it. My all-day-editor is (X)Emacs and
> I use numerous tools every day starting from cd over ls to such
> "obscure" things like Common Lisp. All this software is the
> counterexample for me. And you could not do anything if all software
> would be junk.
So, like me, you've selected some of the small proportion of non-junk
SW. Note well that I did not say *all* software is junk.
> Well I would assume you do not have understand. I do need a bunch of
> libraries to get my work done, I find this libraries easily in other
> languages but Lisp and they usually work. Now I asked for libraries
> for Common Lisp which I can use, and for which I'm willing to pay!
OK, so you're keeping up with a bureaucracy: that's fine, that's what
most of us do most of the time unfortunately. If you're doing that in
Lisp then you are going to have problems finding prepackaged libraries
at low price, because it's just not worth anyone's time to write them
unless they can sell huge numbers of copies, because interfacing to
bureaucracies is expensive.
Of course, even when dealing with a bureaucracy you need less
libraries than you might think: to go back to the SMTP library (SMTP
is really pre-bureaucratic of course), how long would it take to just
write some slightly implementation-specific code to talk the bit of
SMTP you need? I don't know, but I do know that I have a system that
browses news groups via NNTP, and the NNTP code there must have taken
me under 10 minutes (probably well under: there's only about 9 lines
of it). Of course that is not sellable-library-quality code, but it
doesn't need to be. But at 10 minutes to implement, it would have
taken me longer than that to *search* for a library.
> Well what do you think which time is now?
As I said, if I told you that I'd have to deploy the usenet neuralizer
again, and I'm averse to that. It's fun, I admit, but the place
smells of ozone for *days* afterwards. Anyway it's currently
contracted out to keep the news on the recent war on Iraq[1] from
getting out.
--tim
Footnotes:
[1] Is mentioning Iraq the equivalent of mentioning Hitler? Does
mentioning Hitler in a footnote count?
Tim Bradshaw <···@cley.com> writes:
> Of course, even when dealing with a bureaucracy you need less
> libraries than you might think: to go back to the SMTP library (SMTP
> is really pre-bureaucratic of course), how long would it take to just
> write some slightly implementation-specific code to talk the bit of
> SMTP you need? I don't know, but I do know that I have a system that
> browses news groups via NNTP, and the NNTP code there must have taken
> me under 10 minutes (probably well under: there's only about 9 lines
> of it). Of course that is not sellable-library-quality code, but it
> doesn't need to be. But at 10 minutes to implement, it would have
> taken me longer than that to *search* for a library.
The issue with having standardized interfaces isn't just to save
*your* time. By implementing the SMTP protocol yourself, you've
raised the bar for someone who has to maintain your code. If the
maintainer is competent enough to read the requisite RFC's and
understands sockets, it'll still be a hassle--if the maintainer isn't,
guess what'll get blamed?
A lot of the little convenience functions included with Common Lisp
(esp. the list manipulating ones) could easily be written from
scratch; instead, the language designers included them. By doing so
they made it that much easier for you to understand someone elses
program because you don't have to figure out what he calls PUSH or
SUBLIS.
In the environment that I work in, maintenance *is* a big deal[1].
And maintenance is something where Lisp really sucks, both because
there aren't many Lisp programmers relative to other languages and
because you have to write *SO* much from scratch.
Gabe Garza
[1] Verified by actually discussing the issue with managers. I ended
up volunteering to offer up a list of prospective consultants if
I ever leave.
* Gabe Garza wrote:
> The issue with having standardized interfaces isn't just to save
> *your* time. By implementing the SMTP protocol yourself, you've
> raised the bar for someone who has to maintain your code. If the
> maintainer is competent enough to read the requisite RFC's and
> understands sockets, it'll still be a hassle--if the maintainer isn't,
> guess what'll get blamed?
Well, if the maintainer can't understand the 9 lines of code I'm
talking about then I confess I really don't care that much. Really,
there are cases where using a library just is not worth it, and there
are more of those cases than people think. Where it is worth it there
is still a huge difference between implementing a documented,
supportable module which can be used in one application and
implementing a completely reusable library. Doing the latter can
easily cost 10x the former.
--tim
Gabe Garza <·······@ix.netcom.com> wrote:
+---------------
| And maintenance is something where Lisp really sucks, both because
| there aren't many Lisp programmers relative to other languages and
| because you have to write *SO* much from scratch.
+---------------
Geez, you think you have to write a lot from scratch in CL?
This is one of the main reasons I moved *to* CL from Scheme!! ;-}
-Rob
-----
Rob Warnock, PP-ASEL-IA <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
* Rob Warnock wrote:
> Geez, you think you have to write a lot from scratch in CL?
> This is one of the main reasons I moved *to* CL from Scheme!! ;-}
pah, wimps. In my day not only did we have to walk uphill, both ways,
in the snow, we had to implement the snow and the hills from scratch
each time.
--tim
On 13 Mar 2003 10:33:45 -0800, ··@alum.mit.edu (Michael Travers) wrote:
> why aren't there more? If Lisp really makes small teams so much more
> productive, it should be the ideal vehicle for startup software
> companies. Maybe you are right and it's the combative nature and
Maybe the techies among the startup founders would like to use Lisp. But it
may not be easy for them to get approval from those who fund the startup,
who probably prefer mainstream tools and technologies.
Paolo
--
Paolo Amoroso <·······@mclink.it>
Paolo Amoroso <·······@mclink.it> writes:
> On 13 Mar 2003 10:33:45 -0800, ··@alum.mit.edu (Michael Travers) wrote:
>
> > why aren't there more? If Lisp really makes small teams so much more
> > productive, it should be the ideal vehicle for startup software
> > companies. Maybe you are right and it's the combative nature and
>
> Maybe the techies among the startup founders would like to use Lisp. But it
> may not be easy for them to get approval from those who fund the startup,
> who probably prefer mainstream tools and technologies.
It would be easier for these people to fund the startup THEMSELVES if they
didn't always give away software and sometimes charged for it.
On Wed, 12 Mar 2003 12:15:02 -0800, ···@jpl.nasa.gov (Erann Gat) wrote:
> I don't even know what CeBit is.
Comdex roughly corresponds to CeBit in Germany, Sicob(sp?) in France, and
SMAU in Italy.
Paolo
--
Paolo Amoroso <·······@mclink.it>
Paolo Amoroso <·······@mclink.it> writes:
> On Wed, 12 Mar 2003 12:15:02 -0800, ···@jpl.nasa.gov (Erann Gat) wrote:
>
> > I don't even know what CeBit is.
>
> Comdex roughly corresponds to CeBit in Germany, Sicob(sp?) in
> France, and SMAU in Italy.
CeBit claims to be the biggest computer fair in the world. But
probably the other three say the same about their shows... :)
<http://www.cebit.de/>
Edi.
Nils Goesche <······@cartan.de> writes:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <···············@shell01.TheWorld.com>, Kent M Pitman
> > <······@world.std.com> wrote:
>
> > > I personally don't care if someone is learning or not. I care if
> > > they are doing something they can make money at. I want them to
> > > make money.
>
> > If getting people to make money was all you cared about then you'd
> > be advising them to learn C++, Java, and Perl. Or to get an MBA.
> > Or a law degree. If your goal is to make money, then Lisp is about
> > the last thing you want to learn.
> ...
> > So what you really want is not for people to make money (people do
> > that all the time), but rather for people to make money *using
> > Lisp*. But why? It's not because Lisp is a particularly effective
> > means of making money. One might argue that it ought to be, but the
> > simple fact of the matter supported by decades of history is that
> > it's not.
>
> Is that so? When I look at the pile of Linux CDs on my table and
> think about the immense amount of man-hours that went into writing all
> that software in C and C++ for nothing I am not so sure about that
> anymore.
> Sure, there are much fewer small companies that try to make
> money using Lisp than, say, Java or C++, but I would indeed be
> surprised if the former were any less successful than the latter.
Well I have simple things, where can I buy Lisp libraries? Why can I
buy thousands of controls for Delphi? Or VB ...
I do not know any place to look for Lisp libraries. I was totally fed
up today with things I had to work with, and had a really long phone
call with Jochen Schmidt. Now here's what I have (not exact but
direction)
a) finding working libraries which do not enforce me to fall back to
source code while not understanding how to use it? Examples
UncommonSQL, ASDF, CL-XML and what else I have get running here with just
trial and error
b) where can I buy libraries for my System (LispWorks) for reasonable
prices, things for sending and receiving e-mails, for ftp downloads,
even as simple as regular expressions (yes I know one can find them)
but have you used them and tried to apply them with the provided
documentation?
Well you can say, hey that stuff is for free, yes you're right it's so
free that I have to spend several hours to just get it installed and
getting a clue about how to use them with the provided
documentation. I simply ask you why are people not capable of writing
document strings?
c) Just another example EDI Weitz has run into question on how to
access the Registry in LispWorks, he has figured that out by
trial-and-error?
d) See the LispWorks mailing list about COM usage and tell me why is
it so hard to understand what's so terrible difficult about it to use
with Common Lisp and why it's easy elsewhere?
I can go on and on, and I'm by no way a Common Lisp hater, in fact I
love that language, but to get things done which matter for me at the
moment is just running against walls.
Where is a market where one can find people asking and willing to pay
for libraries. No the way is there may fly a crude software out there
which one can download for free, people will do that an fight with it
for days.
I would like to offer some sort of that stuff, but is it likeley that
people will buy it?
>
> Yes, and when more people make lots of money with it, more people will
> want to know about it.
Tell me one place where I can order Lisp Software, and no not allowed
ar the vendors of Common Lisp implementations.
>
> > > There are so many things computers could be doing for people.
> >
> > Like what? If you really have an answer to this question, and your
> > answer is one that people are willing to pay money to have computers
> > do for them, then you're half way to being rich. The thing is that
> > this is a much, much harder question to answer than most technical
> > people appreciate.
>
> That's right: First you need a product, and...
Well first you need an idea on what people are willing to pay for and
how much, than you can probably build something. That is not how
programmers think and behave (I know damn well, I'm one of those
idiots)
>
> Maybe so -- but mainly because they waste too much of their time
> writing the third implementation of procmail, the 300th window manager
> and the 30000th little pet language with an interpreter. These are
> /not/ products. Nobody is going to give you one cent for them. And
> the little bit of knowledge you aquire along the way is not likely to
> be a useful basis for a successful product.
It's not even likely that people are willing to pay for Lisp
libraries...
>
> > I think you seriously underestimate how much harder it is to develop
> > a product than it is to solve a problem.
>
> Well, that depends on the product, I'd say :-) Sure, if you try to
> make money by writing Windows Desktop applications using Visual C++ or
> whatever, finding a product anybody would want to buy is indeed
> extremely hard. But in that case you should get your head checked,
> anyway. If you want to make money, you'll have to look around and
> find out who is selling products not for $100 apiece but for $30000
> apiece. Or $500000.
Why does it have to be expensive software and what does it buy me to
look for someone who can sell his software for that price. What does
it buy you? Will you build a copy of it? Great and how much will it
take?
> Most likely, you'll have to write in C and C++ during that time. But
> when you finally jump and start your own shop, if you have an
> advantage over your competitors that lets you solve problems quicker
> and easier, you are very likely to make a shitload of money.
If it would be that easy all programmers would bath in money.
Regards
Friedrich
* Friedrich Dominicus wrote:
> Where is a market where one can find people asking and willing to pay
> for libraries. No the way is there may fly a crude software out there
> which one can download for free, people will do that an fight with it
> for days.
Well, it looks to me like you've spotted an opportunity. Although I'm
not in the market for stuff right now, there are several times in the
last year where I would have paid money for supported, documented,
comprehensible libraries to do (say) XML processing from Lisp.
--tim
Tim Bradshaw <···@cley.com> writes:
> * Friedrich Dominicus wrote:
> > Where is a market where one can find people asking and willing to pay
> > for libraries. No the way is there may fly a crude software out there
> > which one can download for free, people will do that an fight with it
> > for days.
>
> Well, it looks to me like you've spotted an opportunity. Although I'm
> not in the market for stuff right now, there are several times in the
> last year where I would have paid money for supported, documented,
> comprehensible libraries to do (say) XML processing from Lisp.
Well have you read the reply from Nils?
I would think that says more than anything else. You can find
everything and making it work is not all too hard, ah yes and I should
not be so pessimistic...
Regards
Friedrich
Friedrich Dominicus <·····@q-software-solutions.com> writes:
> Nils Goesche <······@cartan.de> writes:
> > Sure, there are much fewer small companies that try to make money
> > using Lisp than, say, Java or C++, but I would indeed be surprised
> > if the former were any less successful than the latter.
> Well I have simple things, where can I buy Lisp libraries? Why can I
> buy thousands of controls for Delphi? Or VB ...
> I do not know any place to look for Lisp libraries.
Google? :-)
> I was totally fed up today with things I had to work with, and had a
> really long phone call with Jochen Schmidt. Now here's what I have
> (not exact but direction)
> a) finding working libraries which do not enforce me to fall back to
> source code while not understanding how to use it? Examples
> UncommonSQL, ASDF, CL-XML and what else I have get running here with
> just trial and error
If we are talking about big, significant systems people are supposed
to pay lots of money for, the time needed for reading some sources to
find out how to use a library seems to be rather unimportant.
> b) where can I buy libraries for my System (LispWorks) for
> reasonable prices, things for sending and receiving e-mails, for ftp
> downloads, even as simple as regular expressions (yes I know one can
> find them) but have you used them and tried to apply them with the
> provided documentation?
Errm, yes. I have used quite a lot of the freely available Lisp
libraries and don't remember any serious problems. And if you want to
buy some... I am sure you'll easily find somebody who'll write them
for you, for instance by posting here.
> Well you can say, hey that stuff is for free, yes you're right it's
> so free that I have to spend several hours to just get it installed
> and getting a clue about how to use them with the provided
> documentation. I simply ask you why are people not capable of
> writing document strings?
I am quite happy with reading sources. I usually find very quickly
what I am looking for. This is an ability you can train. I learned
it by watching my best coworkers reading sources -- at first it was a
mistery to me how anybody could understand arcane C code by quickly
glancing over it page by page. I tried to do it myself and improved
very much over time. I don't think something like an email or FTP
library needs much documentation if you have the sources available.
> c) Just another example EDI Weitz has run into question on how to
> access the Registry in LispWorks, he has figured that out by
> trial-and-error?
Heh. Well, he /did/ figure it out eventually, didn't he? :-) And he
was even kind enough to tell other people how it works...
> d) See the LispWorks mailing list about COM usage and tell me why is
> it so hard to understand what's so terrible difficult about it to
> use with Common Lisp and why it's easy elsewhere?
Is it? I never used COM and don't plan to, don't know. I think LW is
working on improving their documentation... Sure it sucks sometimes
that you have to find out so much on your own, but the people who do
obviously think it's still worth it. I certainly do. The inspector,
the object browser and DISASSEMBLE help a lot, too :-)
> I can go on and on, and I'm by no way a Common Lisp hater, in fact I
> love that language, but to get things done which matter for me at the
> moment is just running against walls.
Strange, that is not my experience at all. Well, everybody has his
particular set of needs for this library and that -- once you have
yours up and running this phase should be over and you can start
working.
> Where is a market where one can find people asking and willing to
> pay for libraries. No the way is there may fly a crude software out
> there which one can download for free, people will do that an fight
> with it for days.
>
> I would like to offer some sort of that stuff, but is it likeley
> that people will buy it?
That depends -- do they /need/ such a library and is it significant
enough that they don't simply write it themselves instead? There is
probably not a very big market for Lisp libraries, I wouldn't even
think about trying to make money there. Maybe it is because of my
environment -- I have never been in a shop that does something like,
say, consulting jobs like setting up a little intranet server with a
database connection or something like that. In all the shops I have
worked for, people typically didn't use a /single/ third party library
but wrote everything themselves. The systems all consist of lots of
megabytes of self-written code. If you need an SMTP library there --
you write it yourself because the little time it takes doesn't matter
at all compared to the time it takes to write the rest...
Remember we were talking about /difficult/ problems. Writing an SMTP
library is not difficult at all. Sure, coming up with the most
elegant design for an SMTP library might be a significant task, but
who cares? If all I want to do is send a fucking email from Lisp I'll
quickly hack something together that works and move on. Something
like this, for instance:
(with-open-stream (*standard-output*
(sys:open-pipe "mail nils" :direction :output))
(format t "Hi Nils!"))
:-)
So, most of the libraries I use that didn't come with LispWorks I
wrote myself. Sometimes even when free ones were available and I
didn't like them and thought mine would be better, or I wanted to try
out a new technique that might prove useful for bigger projects. And
I wrote FFIs for several C libraries. I don't publish them and I
don't think about selling them either because they are then part of my
personal code base, part of my capital in fact.
> > Yes, and when more people make lots of money with it, more people
> > will want to know about it.
> Tell me one place where I can order Lisp Software, and no not
> allowed ar the vendors of Common Lisp implementations.
I am not talking about selling Lisp code. I am talking about selling
significant programs (or ``solutions��, how this is often called
nowadays). Significant programs are typically not found on any
``desktop��. And an SMTP library is not a significant program,
either.
> > That's right: First you need a product, and...
> Well first you need an idea on what people are willing to pay for
> and how much, than you can probably build something. That is not how
> programmers think and behave (I know damn well, I'm one of those
> idiots)
If I am not totally mistaken, you are still very young. Sure, some
programmers stay totally ignorant about business matters all their
life, but I also know many who have learned over time.
> > Maybe so -- but mainly because they waste too much of their time
> > writing the third implementation of procmail, the 300th window
> > manager and the 30000th little pet language with an interpreter.
> > These are /not/ products. Nobody is going to give you one cent
> > for them. And the little bit of knowledge you aquire along the
> > way is not likely to be a useful basis for a successful product.
> It's not even likely that people are willing to pay for Lisp
> libraries...
No. Why is that such a problem? Are you trying to sell one? :-)
> > If you want to make money, you'll have to look around and find out
> > who is selling products not for $100 apiece but for $30000 apiece.
> > Or $500000.
> Why does it have to be expensive software
It has to be expensive software because it is very hard to make money
with cheap software, or anything else that is cheap for that matter.
Or if it is possible to make serious money with cheap software, I
don't know how. Yes, there is Microsoft -- good luck trying to
outperform them... In my experience, when something gets cheap that
means that there is lots of competition and the winner is the one with
the fewest maintenance programmers who can keep the system running.
The market is already destroyed for newcomers and the rest of demand
is covered by companies who had a running system years ago when it was
still so expensive that the development time was justified.
> and what does it buy me to look for someone who can sell his
> software for that price. What does it buy you? Will you build a copy
> of it?
Building a copy is probably not enough because customers are not
likely to switch then (you could try to offer it for less money, but
the former company will not find that funny at all and drop prices,
too. Which is easier for them because /their/ system is already done
and working. Their programmers are already working on the next Big
Thing) So build something better.
Or if you don't want to copy anything, visit the CeBit to find out
what the next Big Thing is going to be which is not as hard as it
sounds if you have some experience in your field and have some
informers here and there. If you know what the people who made a
shitload of money with the last Big Thing are working on right now,
you can start hacking and try to be ready before they are. If you
succeed they will be angry at you, too, but this time it is going to
be you who will be collecting all the money upfront before the market
is destroyed again :-)
> Great and how much will it take?
Depends -- typically one to three years in my field.
> > Most likely, you'll have to write in C and C++ during that time.
> > But when you finally jump and start your own shop, if you have an
> > advantage over your competitors that lets you solve problems
> > quicker and easier, you are very likely to make a shitload of
> > money.
> If it would be that easy all programmers would bath in money.
Well, who said it's going to be easy. I said you'd have to spend many
years to learn the industry. I am talking about becoming an evil
capitalist :-) Not everybody can or want to do that. The ones who
don't will spend the rest of their days whining how the world isn't as
they would like it to be. It's entirely up to you. You sound so
pessimistic -- try to drop that. Pessimists never achieve anything.
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
Nils Goesche <······@cartan.de> writes:
>
> > I was totally fed up today with things I had to work with, and had a
> > really long phone call with Jochen Schmidt. Now here's what I have
> > (not exact but direction)
>
> > a) finding working libraries which do not enforce me to fall back to
> > source code while not understanding how to use it? Examples
> > UncommonSQL, ASDF, CL-XML and what else I have get running here with
> > just trial and error
>
> If we are talking about big, significant systems people are supposed
> to pay lots of money for, the time needed for reading some sources to
> find out how to use a library seems to be rather unimportant.
Ah see, that is you approach. People should work hard to understand
how libraries work and they should do that buy looking at the source,
the should not expect decent documentation and examples. This is
exactly what has driven me nuts yesterday.
>
> > b) where can I buy libraries for my System (LispWorks) for
> > reasonable prices, things for sending and receiving e-mails, for ftp
> > downloads, even as simple as regular expressions (yes I know one can
> > find them) but have you used them and tried to apply them with the
> > provided documentation?
>
> Errm, yes. I have used quite a lot of the freely available Lisp
> libraries and don't remember any serious problems. And if you want to
> buy some... I am sure you'll easily find somebody who'll write them
> for you, for instance by posting here.
Ah yes a custom tailored package for just x thousands of dollars. Why
can I buy windows controls in other languages for around 100-500
Dollars?
>
> > Well you can say, hey that stuff is for free, yes you're right it's
> > so free that I have to spend several hours to just get it installed
> > and getting a clue about how to use them with the provided
> > documentation. I simply ask you why are people not capable of
> > writing document strings?
>
> I am quite happy with reading sources. I usually find very quickly
> what I am looking for. This is an ability you can train. I learned
> it by watching my best coworkers reading sources -- at first it was a
> mistery to me how anybody could understand arcane C code by quickly
> glancing over it page by page. I tried to do it myself and improved
> very much over time. I don't think something like an email or FTP
> library needs much documentation if you have the sources available.
This is exactly what I hate. And this is the big difference, I'm not
always interested in reading the sources. You can train that? Yes but
it's a difference between can and *have to* I'm not interested in
having to read all the sources from packages I want to use.
>
> > c) Just another example EDI Weitz has run into question on how to
> > access the Registry in LispWorks, he has figured that out by
> > trial-and-error?
>
> Heh. Well, he /did/ figure it out eventually, didn't he? :-) And he
> was even kind enough to tell other people how it works...
Exactly it was his work, but hell it's part of a Product which gets
sold for quite some money.
>
> > d) See the LispWorks mailing list about COM usage and tell me why is
> > it so hard to understand what's so terrible difficult about it to
> > use with Common Lisp and why it's easy elsewhere?
>
> Is it? I never used COM and don't plan to, don't know. I think LW is
> working on improving their documentation... Sure it sucks sometimes
> that you have to find out so much on your own, but the people who do
> obviously think it's still worth it. I certainly do. The inspector,
> the object browser and DISASSEMBLE help a lot, too :-)
Great you have to find out while browsing source, not by reading some
decent examples and documentation. What a time saver.
>
> > Where is a market where one can find people asking and willing to
> > pay for libraries. No the way is there may fly a crude software out
> > there which one can download for free, people will do that an fight
> > with it for days.
> >
> > I would like to offer some sort of that stuff, but is it likeley
> > that people will buy it?
>
> That depends -- do they /need/ such a library and is it significant
> enough that they don't simply write it themselves instead?
This is exactly the problem I tried to point out. Thre is market for
such tools elsewhere but not for Lisp. And than one is talking about
re-inventing Lisp. Well we Lispers are much smarter we do not
re-invent the whell but write all our code from scratch.
> If you need an SMTP library there --
> you write it yourself because the little time it takes doesn't matter
> at all compared to the time it takes to write the rest...
How long would you need for a really good library? And if you think
you can why don't you do it now and offer it for sale? You will than
see that it's a difference on hacking together something that works
and a reusable product. And well you do exactly what the Schemer do,
they write their own Scheme...
>
> Remember we were talking about /difficult/ problems. Writing an SMTP
> library is not difficult at all.
> Sure, coming up with the most
> elegant design for an SMTP library might be a significant task, but
> who cares? If all I want to do is send a fucking email from Lisp I'll
> quickly hack something together that works and move on. Something
> like this, for instance:
Exactly you hack it together and I too, some other dozens of
programmers too very intelligent.
>
> > > Yes, and when more people make lots of money with it, more people
> > > will want to know about it.
>
> > Tell me one place where I can order Lisp Software, and no not
> > allowed ar the vendors of Common Lisp implementations.
>
> I am not talking about selling Lisp code. I am talking about selling
> significant programs (or ``solutions��, how this is often called
> nowadays). Significant programs are typically not found on any
> ``desktop��. And an SMTP library is not a significant program,
> either.
A lot of "insignificant" libraries make a wonderful base for writing a
significant program.
> If I am not totally mistaken, you are still very young.
What do you understand on very young
>
> > > Maybe so -- but mainly because they waste too much of their time
> > > writing the third implementation of procmail, the 300th window
> > > manager and the 30000th little pet language with an interpreter.
> > > These are /not/ products. Nobody is going to give you one cent
> > > for them. And the little bit of knowledge you aquire along the
> > > way is not likely to be a useful basis for a successful product.
>
> > It's not even likely that people are willing to pay for Lisp
> > libraries...
>
> No. Why is that such a problem? Are you trying to sell one? :-)
Yes it would at least be helpful for Lisp but I doubt it would be
helpful for me...
>
> > Why does it have to be expensive software
>
> It has to be expensive software because it is very hard to make money
> with cheap software, or anything else that is cheap for that matter.
> Or if it is possible to make serious money with cheap software, I
> don't know how.
Strange, how can you explain the success of Borland in the past
than?
>
> Building a copy is probably not enough because customers are not
> likely to switch then (you could try to offer it for less money, but
> the former company will not find that funny at all and drop prices,
> too. Which is easier for them because /their/ system is already done
> and working. Their programmers are already working on the next Big
> Thing) So build something better.
And you think that will lead to switch? If that would be the case
people would switch to Common Lisp immedeatly.
>
> > Great and how much will it take?
>
> Depends -- typically one to three years in my field.
Ok than I suggest you do that, and do it with a Common Lisp project,
I'm willing to participate. I checked you homepage why isn't there a
bummer product available? You know how things work, so why don't you
do what you write about?
>
> Well, who said it's going to be easy. I said you'd have to spend many
> years to learn the industry. I am talking about becoming an evil
> capitalist :-) Not everybody can or want to do that. The ones who
> don't will spend the rest of their days whining how the world isn't as
> they would like it to be. It's entirely up to you. You sound so
> pessimistic -- try to drop that. Pessimists never achieve anything.
You have misundertand my mail, I'm not pessimistic I'm angry. That's a
difference.
Friedrich
Friedrich Dominicus <·····@q-software-solutions.com> writes:
> Nils Goesche <······@cartan.de> writes:
> > If we are talking about big, significant systems people are
> > supposed to pay lots of money for, the time needed for reading
> > some sources to find out how to use a library seems to be rather
> > unimportant.
> Ah see, that is you approach. People should work hard to understand
> how libraries work and they should do that buy looking at the
> source, the should not expect decent documentation and
> examples. This is exactly what has driven me nuts yesterday.
Heh. Well, sure, having decent documentation is a good thing. I am
only saying that I don't think it's so terribly important, and that I
don't consider reading sources to find out how to use a library hard
work. For one thing, it's certainly less work than having to write
the library yourself (when it isn't, I'd indeed write it myself).
Software packages (even commercial ones) that come with good
documentation are a rare exception in my experience, no matter in what
language. ``You'll find the documentation in the files ending in .c��
is a running gag I've heard very often. When there is any
documentation at all, it is often so crappy, outdated and incomplete
that checking the sources is actually much faster than reading what's
there. Yes, this is annoying sometimes. But I can live with that.
Especially if I didn't pay for the code I use :-)
> > Errm, yes. I have used quite a lot of the freely available Lisp
> > libraries and don't remember any serious problems. And if you
> > want to buy some... I am sure you'll easily find somebody who'll
> > write them for you, for instance by posting here.
> Ah yes a custom tailored package for just x thousands of
> dollars. Why can I buy windows controls in other languages for
> around 100-500 Dollars?
Higher demand? Do you know how expensive advanced mathematics books
are? There are only very few people who want to read them, so they're
expensive. Making them cheaper simply isn't possible with so few
customers.
> > I don't think something like an email or FTP library needs much
> > documentation if you have the sources available.
> This is exactly what I hate. And this is the big difference, I'm not
> always interested in reading the sources. You can train that? Yes
> but it's a difference between can and *have to* I'm not interested
> in having to read all the sources from packages I want to use.
Creating an ideal world is left as an exercise to the reader ;-)
> > Heh. Well, he /did/ figure it out eventually, didn't he? :-) And
> > he was even kind enough to tell other people how it works...
> Exactly it was his work, but hell it's part of a Product which gets
> sold for quite some money.
And yet people use it. Well, they got the message, and I was happy to
hear them saying they're working on improving the documentation for
the next release. I am looking forward to that, too. But it's not so
important for me that I have problems with using their Lisp right now,
either. When I have a problem, which is not very often, their support
usually helps me out quickly. I think that despite the documentation
problems, I am still very productive; and that's why I pay for their
product.
> > > I would like to offer some sort of that stuff, but is it likeley
> > > that people will buy it?
> > That depends -- do they /need/ such a library and is it
> > significant enough that they don't simply write it themselves
> > instead?
> This is exactly the problem I tried to point out. Thre is market for
> such tools elsewhere but not for Lisp. And than one is talking about
> re-inventing Lisp. Well we Lispers are much smarter we do not
> re-invent the whell but write all our code from scratch.
If I wanted to write everything from scratch I wouldn't have bought a
commercial Lisp. I'll buy what I need for a reasonable price where
``reasonable price�� means ``less than my time's worth for writing it
myself��. That's also how it's been done in every company I've worked
for.
> > If you need an SMTP library there -- you write it yourself because
> > the little time it takes doesn't matter at all compared to the
> > time it takes to write the rest...
> How long would you need for a really good library?
First, I am not sure why I would need such a library at all, as I
already can send mails by opening a pipe to Unix' `mail� program, as
I've shown. I've implemented some similar protocols, though.
> And if you think you can why don't you do it now and offer it for
> sale? You will than see that it's a difference on hacking together
> something that works and a reusable product.
If I go and implement a protocol myself I'll write a complete library
with a decent interface. I've learned that you'll pay for it if you
try to get along with an incomplete crap implementation. The reason I
don't offer them for sale is that I don't think the little money I
might potentially make with them is worth the time of packaging them
up, writing documentation, and then doing marketing, distribution and
support myself. This is the big difference -- even if the software is
perfect, you are still a long way from having a product you can sell.
Moreover, I am planning to /use/ these libraries in a /real/ product
that is supposed to earn me more money than the few thousand dollars I
might make by selling some little libraries. In my field your own
software, your own code is an extremely important capital. Many shops
would immediately go out of business if others got hold of their code.
Releasing it would be nuts.
> > And an SMTP library is not a significant program, either.
> A lot of "insignificant" libraries make a wonderful base for writing
> a significant program.
Yes, and significant libraries even more :-)
> > > Why does it have to be expensive software
> > It has to be expensive software because it is very hard to make
> > money with cheap software, or anything else that is cheap for that
> > matter. Or if it is possible to make serious money with cheap
> > software, I don't know how.
> Strange, how can you explain the success of Borland in the past
> than?
They know how to do it, are a famous company, and have relevant
distribution channels. They also got lots of money. I wouldn't have
the slightest chance if I tried to compete with them. Hardly anybody
would, I think. Sure, I might be wrong... but I am not going to find
out myself.
> > > Great and how much will it take?
> > Depends -- typically one to three years in my field.
> Ok than I suggest you do that, and do it with a Common Lisp project,
> I'm willing to participate.
Once I start hiring other people I might remember that :-) But there's
still a long way to go...
> I checked you homepage why isn't there a bummer product available?
> You know how things work, so why don't you do what you write about?
I am not selling anything yet. And when I do, I'll certainly not try
to do marketing and distribution myself. And I wouldn't try to sell
anything but pornography over the internet ;-)
> You have misundertand my mail, I'm not pessimistic I'm angry. That's
> a difference.
Fair enough.
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
Nils Goesche wrote:
>Creating an ideal world is left as an exercise to the reader ;-)
>
>
I recognise that as a quote from a programming book but I can't for the
life of me remember which. Someone put me out of my misery, please!
Barry Watson <············@uab.ericsson.se> writes:
> Nils Goesche wrote:
>
> >Creating an ideal world is left as an exercise to the reader ;-)
> I recognise that as a quote from a programming book but I can't for
> the life of me remember which. Someone put me out of my misery, please!
On Lisp, p.109:
# Instead of seven ways of using macros, it might be better to say
# that there are six and a half. In an ideal world, all Common Lisp
# compilers would obey inline declarations, and saving function calls
# would be a task for inline functions, not macros. An ideal world is
# left as an exercise to the reader.
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
On 13 Mar 2003 14:14:05 +0100, Nils Goesche <······@cartan.de> wrote:
> might make by selling some little libraries. In my field your own
> software, your own code is an extremely important capital. Many shops
May I ask which field you work in? Just curious.
Paolo
--
Paolo Amoroso <·······@mclink.it>
Paolo Amoroso <·······@mclink.it> writes:
> On 13 Mar 2003 14:14:05 +0100, Nils Goesche <······@cartan.de> wrote:
>
> > might make by selling some little libraries. In my field your own
> > software, your own code is an extremely important capital. Many
> > shops
>
> May I ask which field you work in? Just curious.
Telecommunications.
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
* Friedrich Dominicus wrote:
> A lot of "insignificant" libraries make a wonderful base for writing a
> significant program.
Well, sometimes. Sometimes instead they mean you spend an awful long
time trying to understand the documentation and/or work around the
misdesign in the library, in which time you could have just
reimplemented the subset you need from scratch. Of course, while
doing this you get a nice feeling because you're doing `software
reuse' and that's good, right? You're not just avoiding actually
solving the problem by integrating endless broken libraries, oh no,
not at *all*.
--tim
Tim Bradshaw <···@cley.com> writes:
> * Friedrich Dominicus wrote:
> > A lot of "insignificant" libraries make a wonderful base for writing a
> > significant program.
>
> Well, sometimes. Sometimes instead they mean you spend an awful long
> time trying to understand the documentation and/or work around the
> misdesign in the library, in which time you could have just
> reimplemented the subset you need from scratch. Of course, while
> doing this you get a nice feeling because you're doing `software
> reuse' and that's good, right? You're not just avoiding actually
> solving the problem by integrating endless broken libraries, oh no,
> not at *all*.
Exactly what I think, but I'm not talking about crappy software, but
software which does its work, and if I could buy Lisp packages than I
expect them to work of course.
Friedrich
Friedrich Dominicus <·····@q-software-solutions.com> writes:
>> very much over time. I don't think something like an email or FTP
>> library needs much documentation if you have the sources available.
> This is exactly what I hate. And this is the big difference, I'm not
> always interested in reading the sources. You can train that? Yes but
> it's a difference between can and *have to* I'm not interested in
> having to read all the sources from packages I want to use.
One day last week I implemented order and customer address printing to
PDF for a web-based project I sometimes work on. Using Marc
Battyani's free CL-PDF library, this took about a day's work, including
downloading it, building it, and figuring out how to use it from the
source and examples.
Early this morning I flipped the switch on their live web site so they
can now use this, and fairly quickly I get a phone call to tell me
that it doesn't work using their particular version of Internet
Explorer. Seems that some varieties of IE cannot view PDFs over an
HTTPS connection, because internally it's implemented by saving the
PDF to a temporary file then running Acrobat on that, and IE (at least
in the incarnation they have) won't save content that had been
delivered over HTTPS. There's a checkbox in the Options dialog that's
supposed to control this behaviour, but it makes no difference in
either setting. There's also a unrelated problem where if the server
sends "Pragma: no-cache" or similar this will stop the file from being
saved, but investigation with openssl reveals that this is not the
case here. And all the Last-Modified and blah headers are correct,
and there's a Content-Length - it's a well-formed HTTP response. I
Googled, I looked through the MS knowledge base, I asked people who
were likely to know. Still it won't save that PDF. (The error
message is particuarly helpful: it says the problem is that "The
requested site is either unavailable or cannot be found.")
So I'm about to tell the customer in question that the most effective
workaround will be for them to install a different web browser. By
the time they've done that and observed that the new feature does
actually work, it will probably have taken nearly as long to debug
their client-side problem as it did for me to write the original code
that they're having trouble accessing.
OK, it would be nice if CL-PDF came with more documentation. It'd be
nice if asdf came with more documentation, perhaps (although sometimes
I doubt that anyone even reads the README file anyway, so it's not a
priority for me to change that). In the grand scheme of things,
though, lack of documentation is /really/ not what wastes most of my time.
And thanks to Marc, if he's reading this ...
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
According to Friedrich Dominicus <·····@q-software-solutions.com>:
> Tell me one place where I can order Lisp Software, and no not allowed
> ar the vendors of Common Lisp implementations.
http://www.markwatson.com/commercial/
Free advertisement for Mark Watson. ;-)
I don't know him and have not used his stuff.
--
Ng Pheng Siong <····@netmemetic.com>
http://firewall.rulemaker.net -+- Manage Your Firewall Rulebase Changes
http://www.post1.com/home/ngps -+- Open Source Python Crypto & SSL
····@netmemetic.com (Ng Pheng Siong) writes:
> According to Friedrich Dominicus <·····@q-software-solutions.com>:
> > Tell me one place where I can order Lisp Software, and no not allowed
> > ar the vendors of Common Lisp implementations.
>
> http://www.markwatson.com/commercial/
>
> Free advertisement for Mark Watson. ;-)
Ok one example in a very specific area, you got me, I did not even
have an idea that something like that existed. Now you probably know
better to google than me, please let me find someone where I can get
the libraries for Internet accesses.
Regards
Friedrich
On 13 Mar 2003 08:26:29 +0100, Friedrich Dominicus
<·····@q-software-solutions.com> wrote:
> have an idea that something like that existed. Now you probably know
> better to google than me, please let me find someone where I can get
> the libraries for Internet accesses.
You may contact Kent Pitman's HyperMeta:
http://www.hypermeta.com
See also:
http://alu.cliki.net/Industry%20Application
Paolo
--
Paolo Amoroso <·······@mclink.it>
Friedrich Dominicus <·····@q-software-solutions.com> wrote in message news:<··············@fbigm.here>...
> Nils Goesche <······@cartan.de> writes:
> ...
> Well I have simple things, where can I buy Lisp libraries? Why can I
> buy thousands of controls for Delphi? Or VB ...
>
> I do not know any place to look for Lisp libraries. I was totally fed
> up today with things I had to work with, and had a really long phone
> call with Jochen Schmidt. Now here's what I have (not exact but
> direction)
>
> ...
A hobby project I am considering to increase my knowledge of CLOS and so on
was to write an emulation of Java's Servlet API. I would basically mindlessly
transcribe alot of Java code into CLOS; effectively learning by repetition
much of the basic Lisp constructs. I expect this would cover some of the
metaobject protocol to emulate the java.lang.reflect code that occurs in
the Servlet implementation and generally be a good tour of CLOS.
At the end of the day though, would exist a Lisp library that emulated
a popular enterprise API. I can imagine the disgust some Lisp hackers may
have in contriving CLOS to fit a Java API but despite the plain inelegance
it could serve a practical purpose.
Java API's are well documented and widely used, if there were Lisp libraries
that looked just like them then they would piggyback ontop of all the mountain
of resources that exist for Java.
Thoughts? Would it be legal?
regards,
Gary Moselen
·····@peace.com (Gary Moselen) writes:
> A hobby project I am considering to increase my knowledge of CLOS
> and so on was to write an emulation of Java's Servlet API.
This is a good way to learn Lisp in the same way that translating "The
Brothers Karamazov" from Russian into English-Words-with-Russian-
Grammar would be a good way to learn English.
If you really want to learn something, learn how CLOS is different
then Java and how each naturally leads to very different way of
programming.
> Thoughts? Would it be legal?
IANAL[1], so FWIW: You can legally protect an implementation, but you
can't protect an interface. As long as your implementation doesn't
closely match Sun's (which it likely won't, unless you've read Sun's
source code), it would indeed be legal.
Gabe Garza
[1] Not only am I not a Lawyer, I live in the US. I have no idea what
laws in other countries or even international law has to say on the
matter.
Gabe Garza <·······@ix.netcom.com> wrote in message news:<··············@ix.netcom.com>...
> ·····@peace.com (Gary Moselen) writes:
>
> > A hobby project I am considering to increase my knowledge of CLOS
> > and so on was to write an emulation of Java's Servlet API.
>
> This is a good way to learn Lisp in the same way that translating "The
> Brothers Karamazov" from Russian into English-Words-with-Russian-
> Grammar would be a good way to learn English.
You are suggesting Russian is a subset of English?
> If you really want to learn something, learn how CLOS is different
> then Java and how each naturally leads to very different way of
> programming.
I understand that ideal CLOS implementations would look alot different
than the Java APIs; but I also understand that those ideal CLOS implementations
don't exist. I'm prepared to settle for satisfactory API's that act like
Java's until those ideal CLOS libraries come along, I also know that
CLOS is a superset of Java's object system so building the API's wont be hard.
It would also help settle arguments with Java programmers when they
express ill-informed opinions about what Lisp is good for.
regards,
Gary Moselen
Tim Bradshaw <···@cley.com> wrote in message news:<···············@cley.com>...
> * Gary Moselen wrote:
>
> > You are suggesting Russian is a subset of English?
>
> You are suggesting Java is a subset of CL?
>
In the sense that given a Java solution to a problem, it is possible
to solve the problem in the same way using CLOS, but that the
reverse isn't true. For example an interface would be an empty defclass
(defclass comparable())
and all classes that implemented comparable would be obliged to
to implement a method compare-to if it extended comparable
(defclass huzzah(comparable)
...)
(defmethod compare-to((this some-class)(o object))
...)
A static method that operates over comparable
(defmethod ((this some-dummy-package-object)
(comparable1 comparable)
(comparable2 comparable))
...)
Granted this requirement (interface implementation)
is not explicitly declared or enforced, but it satisfies me
atleast that CLOS can express Java solutions using similar
concepts (interface polymorphism, message passing).
regards,
Gary Moselen
·····@peace.com (Gary Moselen) writes:
> Tim Bradshaw <···@cley.com> wrote in message
> news:<···············@cley.com>...
> > * Gary Moselen wrote:
> >
> > > You are suggesting Russian is a subset of English?
> >
> > You are suggesting Java is a subset of CL?
> >
>
> In the sense that given a Java solution to a problem, it is possible
> to solve the problem in the same way using CLOS, but that the
> reverse isn't true.
None of this really matters in regard to your original request for
thoughts regarding implementing a Lisp interface to a Java library as
an excersise to learn about CLOS.
Yes, you can transcribe the interfaces and use Lisp constructs that
superficially seem to mimic the Java ones. But you aren't going to
learn a thing of value about CLOS.
Yes, you'll learn the names of the operators and how to use them to
(sort of) emulate Java, but so what? You'd just be learning syntax
transformation, which, though it may give you a sense of
accomplishment, isn't at all useful. The crucial aspects of a
language are the idioms that the users of the language apply the
syntax to. CLOS is *NOT* used to write programs that are designed
like Java programs.
If you want to learn about CLOS, study CLOS interfaces.
>
> [snip examples]
>
> (defmethod compare-to((this some-class)(o object))
> ...)
Note that there is absolutely no equivalent for this in Java.
Learning why this is so would be a far more enriching experience then
performing syntax transformation on a Java API.
Gabe Garza
Gabe Garza <·······@ix.netcom.com> wrote in message
> ...
> Yes, you can transcribe the interfaces and use Lisp constructs that
> superficially seem to mimic the Java ones. But you aren't going to
> learn a thing of value about CLOS.
Actually I find it kind of an interesting task, and also enlightening.
For example java's single-dispatch depends on it's runtime type, while
it's overloading is all figured at compile time. CLOS can't really
overload, and where as you can use multi-dispatch to get a kind of
overloading it doesn't work when the parameter lists are different lengths.
I'm telling you I discovered this while doing this comparison.
> Yes, you'll learn the names of the operators and how to use them to
> (sort of) emulate Java, but so what? You'd just be learning syntax
> transformation, which, though it may give you a sense of
> accomplishment, isn't at all useful. The crucial aspects of a
> language are the idioms that the users of the language apply the
> syntax to. CLOS is *NOT* used to write programs that are designed
> like Java programs.
Coding idioms, meaning patterns etc. Things I was hoping Lisp would
express for me, without the repetition. No I'm not interested in idioms,
I'm interested in writing the macros that eliminate the idioms.
> If you want to learn about CLOS, study CLOS interfaces.
Which CLOS interfaces do you reccomend I look at?
> >
> > [snip examples]
> >
> > (defmethod compare-to((this some-class)(o object))
> > ...)
>
> Note that there is absolutely no equivalent for this in Java.
> Learning why this is so would be a far more enriching experience then
> performing syntax transformation on a Java API.
It's similar to the compareTo java method in someClass that takes an
object as it's only argument is it not? In the naive case you can
get java's single-dispatch overloading with multi-dispatch CLOS methods.
But even if you do not accept that, you could always write a static
java method with external polymorphism by switching on the types of
both parameters. It would be pretty lame, but it would be similar to
a point.
regards,
Gary Moselen
···@jpl.nasa.gov (Erann Gat) wrote in message news:<····················@dialin-067.jpl.nasa.gov>...
> why? It's not because Lisp is a particularly effective means of making
> money. One might argue that it ought to be, but the simple fact of the
> matter supported by decades of history is that it's not.
During most of those decades, Lisp sucked. It was ahead of its time.
It would have been laughable to try to make much money from it. Lisp
in 4K core memory is a joke. But it's a joke of the past, regardless
of how many decades of history "support" it.
From: Tim Bradshaw
Subject: Re: Help understanding closures
Date:
Message-ID: <ey3fzptu0i9.fsf@cley.com>
* Kent M Pitman wrote:
> Part of the reason, too, not to read the source is that learning _a_
> way to do it is not learning _the_ way to do it, and I fear that a
> lot of the time it doesn't lead so much to a realization about new
> ways to do something as to a limitation of the way of doing
> something that excludes other ways. If there are 6 different ways
> to do something, does someone have to read or implement all 6 to
> understand them? If not, why can they understand one way only by
> implementing and the other 5 just from theory or a spec?
I think one useful thing to do (at least I found it useful) is to
implement various obviously-hopeless-but-correct versions of things,
because a concrete implementation, especially a *trivial* concrete
implementation, of something provides me with an insight as to how it
needs to work conceptually. It's a model, if you like: because it
exists and because it's trivial it's usually easy to go in and make it
print things or break in various ways and generally get a feel for
what is going on.
The dangers of such an approach are several: it might lead you to
think that no efficient implementation is possible - `because my toy
implementation of generic function dispatch is obviously hopeless,
it's clear that CLOS is doomed to be inefficient'; you might spend a
lot of time optimizing it uselessly; you might get carried away
implementing yet another full-scale system. Finally, trivial
implementations might not be usefully possible (FORMAT, LOOP).
Despite this, I kind of like these things, and I have made several of
them over the years. The trick is keeping them small (in time and
lines), and avoiding the traps above. For me the worst of these is
the `oh, this nearly works right, if I just spend a little while
longer I'll have the whole correct behaviour here' trap - some things
just don't have trivial implementations you can usefully play with.
I think this kind of experimentation is useful if you are the sort of
person who finds it useful (hmmm...), but maybe not everyone does.
--tim
Kent,
I appreciate entirely many of the points you make. Something in them
struck a chord with me, though. I am not a speedy Lisp learner. It may
be years before I master the language. I want to master it but every
time I go back through one of many good books, or browse through the
hyperspec, or read the day's postings in c.l.l., I learn something new
or am reminded of something I feel I should've remembered. Even with
repetition I do not achieve the levels I desire. (How nice it would be
to have a master handy to aim my nose.)
Some of the best learning experiences I have had have been a result of
seeing code implementing a Lisp behavior. It doesn't matter if it is
the best implementation, a speedy implementation, or an efficient one.
When I understand one way to implement it, I know how to use it.
Different people have different learning styles and, whatever ones I may
have, seeing an implementation of a feature helps me understand how to
use the feature. Seeing code which extends an environment speaks
volumes to me.
I do not know how to balance what I have said with what you have said
but I think there is a balance to be found. I think that, for me, an
understand of Lisp implementation issues at the level I have described
will be a help to me as I work on what you mention in your last two
paragraphs.
Jeff
Kent M Pitman wrote:
...
>
> Lisp was designed to solve the world's hardest problems. I'd rather see
> our programmers and potential programmers pointed at those problems,
> largely still unsolved, than pat them on the back for picking a solved
> one and saying "trying to learn something" is automatically not a waste
> of time.
>
> In the information age, there are many things one can learn. Too
> many. We are past the day where any of those things is an automatic
> virtue to confront. The new game in town is to avoid the blind
> alleys, because they are legion.
Jeff Caldwell <·····@yahoo.com> writes:
> I appreciate entirely many of the points you make. [...]
>
> Different people have different learning styles [...]
>
> I do not know how to balance what I have said with what you have said
> but I think there is a balance to be found. I think that, for me, an
> understand of Lisp implementation issues at the level I have described
> will be a help to me as I work on what you mention in your last two
> paragraphs.
I don't run things. (You all knew I didn't, but I thought I'd confirm
I knew it, too.) People will make whatever choices they make. My
concern was and is only to get my feelings clearly onto the record,
not to enforce a particular way of doing things. If I don't speak up,
I'm sometimes left feeling I'm giving silent consent to some unspoken
assumptions going by that I disagree with. So my goal was to add some
ballast to the other side, perhaps drawing things more toward an
unchampioned center. As long as the community is operating out of
careful and dynamically adjusted thought, and not out of autopilot
toward some statically compiled notion of "Good", things will probably
work out.
There was a time when a lot of us learned by thinking about
interpreters; so it may sound hypocritical for me to suggest you
shouldn't. But what I'm really trying to say is that times change,
and that what was a good use of time then needs at minimum to be
re-examined in a critical light today to be sure it's still a good use
of time now.
Sometimes too, I think there's a little too much substituting of open
source for coherent documentation/teaching. It's all well and good to
get under the hood when someone's explanation or documentation falls
flat, but to some extent I think this is an implicit criticism of that
insufficient explanation or documentation.
What you do recommend as a learning path? You mention something not to
do and I wonder if that means there are things one should do, things
that should prove particularly effective. How can a person studying
Lisp independently acquire the proper foundation and feel confident in
that? What are the stopping-points along the path to proper skills?
There are books often mentioned here which I've found excellent. I read
and then code for awhile, then I go back through the books and, when I
do, I pick up more each time or I quit going back to that book.
Sometimes it's time to read and sometimes it's time to code, getting
what I've read under my fingers. (I look at what I just wrote, laugh,
and think "That's my plan?!!?".)
Thanks,
Jeff
Kent M Pitman wrote:
>...times change,
> and that what was a good use of time then needs at minimum to be
> re-examined in a critical light today to be sure it's still a good use
> of time now.
>
> Sometimes too, I think there's a little too much substituting of open
> source for coherent documentation/teaching. It's all well and good to
> get under the hood when someone's explanation or documentation falls
> flat, but to some extent I think this is an implicit criticism of that
> insufficient explanation or documentation.
On Mon, Mar 10, 2003 at 09:50:47PM -0800, Justin Dubs wrote:
> The problem is when I change the code to:
>
> (let ((x 1))
> (defun get-x () x)
> (setf x 2))
>
> Now, I have the closure already created, with it's entry pointing to
> the Number 1. When I get the (setf x 2) I modify the lexical
> environment's symbol table be creating a new Number, Number 2, and
> updating the hash to point to this new number.
>
> This doesn't work out well because the closure is still pointing to
> the Number 1. So the x that get-x knows about hasn't changed.
>
> So, I thought about instead having the closure just contain a
> reference to lexical environment it was created in. This way, any
> changes to it, such as (setf x 2), would also affect the closure.
> However, now I change the code again:
Right, don't copy.
Consider:
(let ((x 1))
(defun f () (incf x))
(defun g () x))
F and G can both access the binding named by X, it is the same binding--
not a copy.
> (let ((x 1))
> (defun get-x () x)
> (setf y 2))
This example is simply invalid. What is Y? You cannot use SETF on an
undefined variable.
> Now I have the problem that y is introduced into the symbol table for
> the lexical environment, and hence also into the closure. This is
> likely not the desired behavior, as y was not bound until after the
> closure was created.
>
> So, as the two easiest ways both have problems, I was wondering how
> closures are implemented "in the real world." There are a few
> obvious ways to fix my problem, but I wondering what the established,
> main-stream approach was, as it may very well be better than what I
> have come up with.
An easy way to do it is to use a list which acts like a stack. As you
nest deeper levels of scope, you push more bindings on the top. Each
closure points somewhere into the stack, this way you can share
structure between all the nested scopes. You must remember, however, to
load in the appropriate environment when you call a function.
A neat way to implement the interpreter is via continuation-passing
style. Your INTERP function takes 3 arguments: a form to evaluate, an
environment to evaluate it in, and a continuation function. The
continuation function is of a single parameter, to which you pass the
result of the computation.
Example:
(defconstant +empty-env+ nil)
(defun look-up-variable (v env)
(cdr (assoc v env)))
(defun add-binding (var val env)
(cons (cons var val) env))
(defun interp (form env cont)
(cond ((symbolp form)
(funcall cont (look-up-variable form env)))
((atom form)
(funcall cont form))
((eq '+ (first form))
(interp (second form)
env
#'(lambda (v1)
;; v1 is the result of evaluating the first argument
(interp (third form)
env
#'(lambda (v2)
;; v2 is the result of evaluating the
;; second argument to +
(funcall cont (+ v1 v2)))))))
((eq 'let1 (first form))
;; (LET1 (A 1) A) <==> (LET ((A 1)) A)
;; one binding only, one expression in body only
(interp (third form)
(add-binding (first (second form))
(second (second form))
env)
cont))))
[5]> (interp '(+ 1 1) +empty-env+ #'identity)
2
[6]> (interp '(let1 (a 1) a) +empty-env+ #'identity)
1
[7]> (interp '(let1 (a 1) (+ 2 a)) +empty-env+ #'identity)
3
To implement functions you need to store the value of that env
parameter, and then use it at the appropriate time. Implementing SETQ
would require a way to modify the values contained in the environment
data structure. You can also play fun tricks with the continuation
functions, capturing them and allowing the user to manipulate them.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
······@eos.ncsu.edu (Justin Dubs) writes:
> [..] This doesn't work out well because the closure is still
> pointing to the Number 1. So the x that get-x knows about hasn't
> changed.
This is a clear sign you have misunderstood something fundamental
about bindings and variables. There is only one location (a variable)
in the lexical scope of the let that is named x. You don't change the
symbol table with setf, you only change the value of the variable
named x. Only binding operators like let can change the "symbol
table".
> (let ((x 1))
> (defun get-x () x)
> (setf y 2))
>
> Now I have the problem that y is introduced into the symbol table
> for the lexical environment, and hence also into the closure. This
> is likely not the desired behavior, as y was not bound until after
> the closure was created.
Again, setf can't change the "symbol table". The symbol y isn't bound
in this case, and so trying to write to a variable named y is an
error. This whole business about doing (setf x 2) after the defun is
really very uninteresting if you just grasp the basic concepts first.
> So, as the two easiest ways both have problems, I was wondering how
> closures are implemented "in the real world." There are a few
> obvious ways to fix my problem, but I wondering what the
> established, main-stream approach was, as it may very well be better
> than what I have come up with.
You haven't even approached the most general aspects of closures
yet. This is a more interesting example:
(defun make-counter (&optional (initial-value 0))
(let ((x initial-value))
(values (lambda (&optional (delta 1)) (incf x delta))
(lambda (&optional (delta 1)) (decf x delta)))))
> I'm sorry if I am not describing this problem horribly well. Thank
> you all for your time, and any additional assistance that you can
> give me.
Your approach seems a little bit like a kid starting school and
refusing to learn about "+" and "-" because he only wants to learn to
be a rocket scientist. Learn how to use lisp first, then pick up a
book that explains these things.
--
Frode Vatvedt Fjeld
Frode Vatvedt Fjeld <······@cs.uit.no> wrote in message news:<··············@vserver.cs.uit.no>...
> ······@eos.ncsu.edu (Justin Dubs) writes:
>
> > [..] This doesn't work out well because the closure is still
> > pointing to the Number 1. So the x that get-x knows about hasn't
> > changed.
>
> This is a clear sign you have misunderstood something fundamental
> about bindings and variables. There is only one location (a variable)
> in the lexical scope of the let that is named x. You don't change the
> symbol table with setf, you only change the value of the variable
> named x. Only binding operators like let can change the "symbol
> table".
Yes, I understand what you mean. I am aware that this is how things
work, from the high-level viewpoint of Lisp. The problem is that on a
very low level, not all values can "fit" into the same location. I
solved this problem last night by introducing another level of
indirection into the "symbol table" system.
>
> > (let ((x 1))
> > (defun get-x () x)
> > (setf y 2))
> >
> > Now I have the problem that y is introduced into the symbol table
> > for the lexical environment, and hence also into the closure. This
> > is likely not the desired behavior, as y was not bound until after
> > the closure was created.
>
> Again, setf can't change the "symbol table". The symbol y isn't bound
> in this case, and so trying to write to a variable named y is an
> error. This whole business about doing (setf x 2) after the defun is
> really very uninteresting if you just grasp the basic concepts first.
Ahhh.... now I understand. y DOES get bound. Just not in the local
environment. Setf is used to reassign values, but as y wasn't bound,
it couldn't update it in the local environment. So, first it had to
create a binding for it, in the global environment. y is introduced
as a global rather than a local variable. I understand that now.
Thank you.
Interestingly, in a sad kind of way, this is already how I had it
implemented it. For some reason I just refused to realize that.
> You haven't even approached the most general aspects of closures
> yet. This is a more interesting example:
>
> (defun make-counter (&optional (initial-value 0))
> (let ((x initial-value))
> (values (lambda (&optional (delta 1)) (incf x delta))
> (lambda (&optional (delta 1)) (decf x delta)))))
Actually this exactly isn't really that much more interesting from an
implementation stand-point. Once I have functional closures, this
example will be just as easy as any other example.
You are using a lambda-form instead of a function declaration. You
are returning the resulting anonymous functions. And you are
destructively modifying x rather than just returning it. These
differences are all rather moot from an implementation stand-point.
> Your approach seems a little bit like a kid starting school and
> refusing to learn about "+" and "-" because he only wants to learn to
> be a rocket scientist. Learn how to use lisp first, then pick up a
> book that explains these things.
I do understand how lisp works relatively well for a beginner. I've
been studying it's theory and reading books about it for a year now.
The difference is that all of these implementation "details" are
simple to you, as you aren't actually implementing them. You can look
at this from the point-of-view of how things "work" in "lisp," with
the luxury of already having "lisp." I'm writing it. There are many
more concerns with memory locations and such when you are actually
implementing symbol tables and garbage collection.
Regardless, the only actual "mistake" I seem to have made thus far was
a misconception or two about how new bindings are introduced. But,
I've resolved them pretty quickly. I'm not clear, I guess, on exactly
what "+" and "-" you think I am missing. If there are truly things
that are that fundamental which I do not seem to grasp, I would
appreciate you pointing them out so that I can correct my
understanding of them.
Either way, thanks to everyone for the responses. You've managed to
clear up a misconception or two. I appreciate your time.
Justin Dubs
From: Tim Bradshaw
Subject: Re: Help understanding closures
Date:
Message-ID: <ey3bs0hu0c6.fsf@cley.com>
* Justin Dubs wrote:
> Ahhh.... now I understand. y DOES get bound. Just not in the local
> environment. Setf is used to reassign values, but as y wasn't bound,
> it couldn't update it in the local environment. So, first it had to
> create a binding for it, in the global environment. y is introduced
> as a global rather than a local variable. I understand that now.
> Thank you.
No. This is *an error*, like he said. An implementation could do
*anything*.
--tim
······@eos.ncsu.edu (Justin Dubs) writes:
> Yes, I understand what you mean. I am aware that this is how things
> work, from the high-level viewpoint of Lisp. The problem is that on
> a very low level, not all values can "fit" into the same location.
> I solved this problem last night by introducing another level of
> indirection into the "symbol table" system.
No, this is not a problem, and it doesn't need solving.
> Ahhh.... now I understand. y DOES get bound. Just not in the local
> environment.
The consequences of writing to a variable-name that isn't bound (and
thus isn't associated with a variable) is undefined. So you can do
whatever you wish. Many implementations chose to automatically add a
dynamic binding for that name in the top environment and proceed as if
the binding was already there. This, like the previous issue, has
nothing whatsoever to do with lexcial bindings and/or closures.
>> You haven't even approached the most general aspects of closures
>> yet. This is a more interesting example:
>>
>> (defun make-counter (&optional (initial-value 0))
>> (let ((x initial-value))
>> (values (lambda (&optional (delta 1)) (incf x delta))
>> (lambda (&optional (delta 1)) (decf x delta)))))
>
> Actually this exactly isn't really that much more interesting from
> an implementation stand-point. Once I have functional closures,
> this example will be just as easy as any other example.
I think you would be well advised not to explain to others things that
you clearly and admittedly don't understand. My example is more
general because in this case the storage for holding the x variable
must be dynamically allocated each time make-counter is called. In
your case the x variable is only referenced from one function, which
means that the storage for x can be statically allocated.
> I do understand how lisp works relatively well for a beginner. I've
> been studying it's theory and reading books about it for a year now.
Let me suggest that you pick up the Hyperspec and study chapter 3 in
particular. And do look up the definitions of "binding" and
"variable".
> The difference is that all of these implementation "details" are
> simple to you, as you aren't actually implementing them. You can
> look at this from the point-of-view of how things "work" in "lisp,"
> with the luxury of already having "lisp." I'm writing it. There
> are many more concerns with memory locations and such when you are
> actually implementing symbol tables and garbage collection.
If you plan to implement lisp, you should know it _better_ than
someone who doesn't, not worse. The fact of the matter is that I am in
fact implementing Common Lisp. And not just in the form of a mere
evaluator. I have understood, resolved and implemented all the issues
here that confuse you so.
--
Frode Vatvedt Fjeld
Frode Vatvedt Fjeld <······@cs.uit.no> wrote in message news:<··············@vserver.cs.uit.no>...
> [...]
> ······@eos.ncsu.edu (Justin Dubs) writes:
> > Ahhh.... now I understand. y DOES get bound. Just not in the local
> > environment.
>
> The consequences of writing to a variable-name that isn't bound (and
> thus isn't associated with a variable) is undefined. So you can do
> whatever you wish. Many implementations chose to automatically add a
> dynamic binding for that name in the top environment and proceed as if
> the binding was already there. This, like the previous issue, has
> nothing whatsoever to do with lexcial bindings and/or closures.
Yes, I have learned this after many people pointing it out. This
makes sense now. Thank you for the response.
> >> You haven't even approached the most general aspects of closures
> >> yet. This is a more interesting example:
> >>
> >> (defun make-counter (&optional (initial-value 0))
> >> (let ((x initial-value))
> >> (values (lambda (&optional (delta 1)) (incf x delta))
> >> (lambda (&optional (delta 1)) (decf x delta)))))
> >
> > Actually this exactly isn't really that much more interesting from
> > an implementation stand-point. Once I have functional closures,
> > this example will be just as easy as any other example.
>
> I think you would be well advised not to explain to others things that
> you clearly and admittedly don't understand. My example is more
> general because in this case the storage for holding the x variable
> must be dynamically allocated each time make-counter is called. In
> your case the x variable is only referenced from one function, which
> means that the storage for x can be statically allocated.
I do understand how the above code works. I realized that it was
different with respect to the allocation of x. However, given the
specific way in which my interpreter works, I believe that the
difference is moot. Of this you will have to take my word until I
have a working product which you may very well test for yourself.
Again, I am not certain of this. But I am "pretty sure" that if my
interpreter will handle the simple case, it will handle yours.
> > I do understand how lisp works relatively well for a beginner. I've
> > been studying it's theory and reading books about it for a year now.
>
> Let me suggest that you pick up the Hyperspec and study chapter 3 in
> particular. And do look up the definitions of "binding" and
> "variable".
I have done this. Thank you.
> > The difference is that all of these implementation "details" are
> > simple to you, as you aren't actually implementing them. You can
> > look at this from the point-of-view of how things "work" in "lisp,"
> > with the luxury of already having "lisp." I'm writing it. There
> > are many more concerns with memory locations and such when you are
> > actually implementing symbol tables and garbage collection.
>
> If you plan to implement lisp, you should know it _better_ than
> someone who doesn't, not worse. The fact of the matter is that I am in
> fact implementing Common Lisp. And not just in the form of a mere
> evaluator. I have understood, resolved and implemented all the issues
> here that confuse you so.
I assume that there was a point in your life during which they
confused you as well. I am at this point now. I am resolving these
issues slowly, with the help of books, and with the help of many of
the responses to my original post, including yours. As far as how
well I know Lisp goes, I am trying to learn it better by implementing
it. That's just the way I think. This helps me learn.
Thank you again for your response.
Justin Dubs
From: Tim Bradshaw
Subject: Re: Help understanding closures
Date:
Message-ID: <ey3smtu9phf.fsf@cley.com>
* Justin Dubs wrote:
> (let ((x 1))
> (defun get-x () x)
> (setf y 2))
> Now I have the problem that y is introduced into the symbol table for
> the lexical environment, and hence also into the closure. This is
> likely not the desired behavior, as y was not bound until after the
> closure was created.
No. Y was *never* bound. Some preexisting binding of Y was changed.
If there was no preexisting binding then this is likely an error.
Something like this seems to be more what you mean (removing the
global function stuff as that's just an obscurity):
(defun two-envs ()
(let ((x 1))
(list
(lambda (&optional (v nil vp))
(if vp (setf x v) x))
(let ((y 2))
(lambda (&optional (v nil vp))
(if vp (setf y v) (list x y)))))))
Then calling TWO-ENVS will return a list of two closures. The first
element of the list closes over an environment which contains a
binding of X to 1. It can modify this binding. The second element
closes over an environment which contains a binding of Y to 2, and the
outer environment. It can modify the binding of Y in this second
environment, and will see any modifications to the binding of X in the
first environment:
CL-USER 8 > (setf *x* (two-envs))
(#<closure (subfunction 1 two-envs) 205F405A>
#<closure (subfunction 2 two-envs) 205F4082>)
CL-USER 9 > (funcall (first *x*))
1
CL-USER 10 > (funcall (first *x*) 4)
4
CL-USER 11 > (funcall (first *x*))
4
CL-USER 12 > (funcall (second *x*))
(4 2)
CL-USER 13 > (funcall (second *x*) 3)
3
CL-USER 14 > (funcall (second *x*))
(4 3)
Conceptually, a lexical environment contains some bindings, and a
reference to the environment in which it was defined (which may be
null or some slightly magic `top-level' environment if the environment
has no parent). The value of a variable is the value of the innermost
binding in which it occurs, searching up through the parent
environments. Changing a binding by assignment changes that innermost
one. Assignment never creates bindings only, well, binding forms
create them.
I really can't stress enough how important it is to look at some tiny
lisp-in-lisp system to understand this. A fairly hairy such
implementation is only a few hundred lines, and makes completely clear
how these things need to work.
I also can't stress enough that this is likely *not* how serious
implementations actually do it - they do something which works like
this, but will be very much more optimized. For instance: all the
structure of the environments (what bindings exist, what parent
environments there are) is known when a closure is created and never
changes, so no actual searching needs to be done at runtime.
--tim
"Justin Dubs" <······@eos.ncsu.edu> wrote in message
·································@posting.google.com...
> Okay, I'm going to start completely over again. No one came even
> close to actually answering any of my questions. I must assume that
> this is my own fault for not phrasing them well. So, I'll try again.
>
> Let me preface this by saying that the reason for my interest in this
> "implementation" stuff is that, well, I am implementing it. I am
> writing a lisp interpreter. Yes, a pure interpreter. No, no
> compilng. Yes, it's for education purposes. Yes, I realize that
> everyone thinks I'm wasting my time.
You could implement it in CL, but I assume you are doing it with
some other language. :(
Wade
Justin Dubs wrote:
> I believe that I understand closures conceptually. They are rather
> simple. They are just a capture of the lexical environment in which a
> function is created, so as to provide bindings for free variables.
>
> What I am confused about is the implementation of a closure. I'm
> hoping you guys can help me out.
>
> Lets assume a local environment, whose symbol table contains the
> binding of the symbol x to the number 1.
>
> (let ((x 1))
> ...)
>
> So, under the hood we have a symbol table, who's entry for x contains
> an address. At this address is stored the number 1. Right?
>
> Then, within this local environment we create a function, and hence
> it's associated lexical closure.
>
> (let ((x 1))
> (defun get-x () x)
> ...)
>
> So, under the hood again, we have a closure who's entry for x contains
> an address? The same address that is stored in the local symbol
> table? And at that address, is still the number 1?
>
> Now, we modify the binding for x.
>
> (let ((x 1))
> (defun get-x () x)
> (setf x 2))
>
> So, under the hood again, the symbol table contains what now? The
> same as before? Is it just the contents of the address pointed to by
> the symbol table that have been changed? Has the number 1 been
> replaced by the number 2?
Did u try it?
(let ((x 1))
(defun get-x () x)
(setf x 2))
=> 2 [from the setf]
(get-x)
=> 2
>
> What if we did a (setf x "this can't fit in the same space as an
> integer!").
You can't. You need:
(let ((x 1))
(defun get-x () x)
(defun set-x (newx) (setf x newx)))
> Then what happens? The symbol table has to be updated to
> point to the address of the new string. But, this leaves the closure
> hanging in the wind, as it is still pointing to the number 1.
(set-x "hello, world.")
(get-x)
=> "Hello, world."
I'll stop here because I /think/ this much addresses some of your other
ruminations.
oh, but this:
(let ((x 1))
(defun get-x () (list x y))
(setf y 3))
(get-x)
=> (1 3)
If there were no setf of y, you'd get an error for the unbound variable.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
Justin Dubs wrote:
>
> I believe that I understand closures conceptually. They are rather
> simple. They are just a capture of the lexical environment in which a
> function is created, so as to provide bindings for free variables.
>
> What I am confused about is the implementation of a closure. I'm
> hoping you guys can help me out.
>
a useful step would be to go find a metacircular evaluator and look at how it works. once you do that, you will be able to answer all your questions.
try this for a start. "http://www.google.nl/search?q=metacircular&ie=ISO-8859-1&hl=nl&lr=" i think it should get you to a copy of abelson and sussman online.
look at chapter 4.
...
······@eos.ncsu.edu (Justin Dubs) writes:
> [..] Now, we modify the binding for x.
>
> (let ((x 1))
> (defun get-x () x)
> (setf x 2))
>
> So, under the hood again, the symbol table contains what now? The
> same as before? Is it just the contents of the address pointed to
> by the symbol table that have been changed? Has the number 1 been
> replaced by the number 2?
Obviously. After evaluating (setf x 2), the location that is named x
in the lexical scope of the let form, will hold the value 2.
> What if we did a (setf x "this can't fit in the same space as an
> integer!"). Then what happens?
This is no different from setting the value to 2. The allocation of
storage for the string's characters is a totally unrelated issue.
> So, it seems to me that the closure can't just point to the same
> address as the local symbol table, because then it will become out
> of sync if any of those symbol become re-bound.
I don't know what this means. You should probably learn to use
closures and the terminology before you try to understand how they are
implemented.
--
Frode Vatvedt Fjeld