SBCL has just turned 1.0!
····@ibmr52:~$ sbcl
This is SBCL 1.0, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
*
This is great. :D
http://digg.com/programming/SBCL_The_Common_Lisp_implementation_has_just_turned_1_0/
--
Lars Rune Nøstdal
http://nostdal.org/
Lars Rune Nøstdal wrote:
> SBCL has just turned 1.0!
A big congrats goes out to the dev team. SBCL is an awesome
implementation =)
Thanks guys!
- John Quigley
········@gmail.com wrote:
> Lars Rune N�stdal wrote:
>
>>SBCL has just turned 1.0!
>
>
> A big congrats goes out to the dev team. SBCL is an awesome
> implementation =)
Rubbish. No IDE and runs on like 5% of the world's computers. After a
quarter frickin century. Typical academic self-absorbed
non-accomplishment. Say what you will about commercial software, the
need to eat has no substitute when it comes to productivity.
Python wins because GvR was man enough to realize the wasted brainpower
going into replacing lambda and back down. Lisp loses because the best
and the brightest young Lisp turks are just trying to drive Franz and
Lispworks out of business when there is so much other amazing code to be
written.
Sad day, and sadder still when it does run on win32.
kzo
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
> ········@gmail.com wrote:
> > Lars Rune Nøstdal wrote:
> >
> >>SBCL has just turned 1.0!
> >
> >
> > A big congrats goes out to the dev team. SBCL is an awesome
> > implementation =)
>
> Rubbish. No IDE and runs on like 5% of the world's computers. After a
> quarter frickin century. Typical academic self-absorbed
> non-accomplishment. Say what you will about commercial software, the
> need to eat has no substitute when it comes to productivity.
>
> Python wins because GvR was man enough to realize the wasted brainpower
> going into replacing lambda and back down. Lisp loses because the best
> and the brightest young Lisp turks are just trying to drive Franz and
> Lispworks out of business when there is so much other amazing code to be
> written.
I love the way people rubbishing free and open-source software always
say:-
1. It's bad.
2. But it's really hurting the commercial competition.
"Rob Thorpe" <·······@realworldtech.com> writes:
> I love the way people rubbishing free and open-source software always
> say:-
> 1. It's bad.
> 2. But it's really hurting the commercial competition.
Why are you being sarcastic? It's perfectly valid thinking. Faced
with the choice between a free program that does 70% of what they want
mostly well (but costs nothing) and a commercial program that does
exactly what they want and does it very well (but costs money), many
people will settle for the free version.
It's harder for commercial software to be profitable when competing
against free software because vendors need to convince their customers
that they should pay for all of the costs of development to gain just
a few extra features. If free software were not free (as in beer),
it would be easier to make a living selling commercial software.
It's pretty tough to argue against this point. You could say that in
some cases free software is better than commercial software
(e.g. Emacs vs. Notepad) or that free software makes you a happier
human being, but I don't see how you can deny that no-cost software
will hurt the software industry. If I were a multimillionaire and I
started giving away shoddily-manufactured cars for free as a charity,
many people would undoubtedly put up with the lower quality to save
the purchase price, even if it only plays cassettes, breaks down once
a month, and has no air conditioning. Much as in the scenario we're
talking about, the auto industry would get wrecked, because I'm not
charging people for the costs of developing and manufacturing the
cars. But note that society has progressed backwards - people have
given up reliable cars, CD players, air conditioning, etc. And maybe
the auto manufacturers have to start cutting quality in an attempt to
compete with these free cars. In fact, not only the auto companies
but society as a whole is worse off.
Bill Atkins <······@rpi.edu> writes:
> If I were a multimillionaire and I started giving away
> shoddily-manufactured cars for free as a charity, many people would
> undoubtedly put up with the lower quality to save the purchase price,
> even if it only plays cassettes, breaks down once a month, and has no
> air conditioning. Much as in the scenario we're talking about, the
> auto industry would get wrecked, because I'm not charging people for
> the costs of developing and manufacturing the cars. But note that
> society has progressed backwards - people have given up reliable cars,
> CD players, air conditioning, etc.
But society hasn't regressed--folks have free cars, leaving them more
funds to invest in more useful things.
Low-priced software puts high-priced software out of business; this is
hardly economic news.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Don't underestimate the Vikings. They'd have gotten longships out to
the moon if they thought there was something worth killing, raping, or
stealing when they got there. --Mike Sphar
Robert Uhl wrote:
> Bill Atkins <······@rpi.edu> writes:
>
>> If I were a multimillionaire and I started giving away
>> shoddily-manufactured cars for free as a charity, many people would
>> undoubtedly put up with the lower quality to save the purchase price,
>> even if it only plays cassettes, breaks down once a month, and has no
>> air conditioning. Much as in the scenario we're talking about, the
>> auto industry would get wrecked, because I'm not charging people for
>> the costs of developing and manufacturing the cars. But note that
>> society has progressed backwards - people have given up reliable cars,
>> CD players, air conditioning, etc.
>
> But society hasn't regressed--folks have free cars, leaving them more
> funds to invest in more useful things.
>
> Low-priced software puts high-priced software out of business; this is
> hardly economic news.
Low-priced software puts high-priced low-value software out of business.
For high-priced software that offers good value for the money,
low-priced or free software can actually increase sales, just as free
distribution of other copyrighted content can ultimately increase sales.
paul
Robert Uhl <·········@NOSPAMgmail.com> writes:
> Bill Atkins <······@rpi.edu> writes:
>
>> If I were a multimillionaire and I started giving away
>> shoddily-manufactured cars for free as a charity, many people would
>> undoubtedly put up with the lower quality to save the purchase price,
>> even if it only plays cassettes, breaks down once a month, and has no
>> air conditioning. Much as in the scenario we're talking about, the
>> auto industry would get wrecked, because I'm not charging people for
>> the costs of developing and manufacturing the cars. But note that
>> society has progressed backwards - people have given up reliable cars,
>> CD players, air conditioning, etc.
>
> But society hasn't regressed--folks have free cars, leaving them more
> funds to invest in more useful things.
Sure it has. Society is accepting inferior products and people who
formerly would have bought cars can't help but opt for the free one.
Progress made on things like catalytic converters, fuel efficiency,
safety, etc. is lost, and these features are no longer enjoyed by the
bulk of car drivers because it would be too costly to add them to the
barebones free cars that I, the maverick billionaire philanthropist,
am giving away and it's too easy for people to ignore these
deficiencies when they have to pay nothing at all to own the car.
> Low-priced software puts high-priced software out of business; this is
> hardly economic news.
No kidding. I'm not saying its news; I'm just explaining why I
disagree with Mr. Thorpe's claim that free software can't both be bad
*and* capable of hurting the software industry.
I'd also point out software that costs absolutely nothing is different
than software that is simply less expensive than other software.
Bill Atkins <······@rpi.edu> writes:
> Robert Uhl <·········@NOSPAMgmail.com> writes:
> > Low-priced software puts high-priced software out of business; this is
> > hardly economic news.
>
> No kidding. I'm not saying its news; I'm just explaining why I
> disagree with Mr. Thorpe's claim that free software can't both be bad
> *and* capable of hurting the software industry.
Exactly. What I have a hard time understanding is why otherwise
seemingly intelligent people have a hard time understanding this.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
On Thu, 30 Nov 2006 20:43:51 -0500, Bill Atkins <······@rpi.edu> tried to
confuse everyone with this message:
>Robert Uhl <·········@NOSPAMgmail.com> writes:
>
>> Bill Atkins <······@rpi.edu> writes:
>>
>>> If I were a multimillionaire and I started giving away
>>> shoddily-manufactured cars for free as a charity, many people would
>>> undoubtedly put up with the lower quality to save the purchase price,
>>> even if it only plays cassettes, breaks down once a month, and has no
>>> air conditioning. Much as in the scenario we're talking about, the
>>> auto industry would get wrecked, because I'm not charging people for
>>> the costs of developing and manufacturing the cars. But note that
>>> society has progressed backwards - people have given up reliable cars,
>>> CD players, air conditioning, etc.
>>
>> But society hasn't regressed--folks have free cars, leaving them more
>> funds to invest in more useful things.
>
>Sure it has. Society is accepting inferior products and people who
>formerly would have bought cars can't help but opt for the free one.
>Progress made on things like catalytic converters, fuel efficiency,
>safety, etc. is lost, and these features are no longer enjoyed by the
>bulk of car drivers because it would be too costly to add them to the
>barebones free cars that I, the maverick billionaire philanthropist,
>am giving away and it's too easy for people to ignore these
>deficiencies when they have to pay nothing at all to own the car.
This analogy is rather flawed. In OSS case, some talented engineer can add some
device to the car, and then, somehow, give this upgraded car for free to anyone
who wants it. Oh wait, that doesn't make sense. Mimesis is broken. Bad analogy,
bad.
You just can't compare software and "hardware". Software is free to reproduce
and software companies make money out of thin air. Hardware costs money to
reproduce, and you pay the cost of reproducing it, not the cost of designing it
or something like that.
A better analogy would be: some billionaire designs a crappy car and gives the
design to anyone for free. You can see how your whole arguments falls apart. Car
companies actually benefit in this case, because they can take the basic design
and add mods until the car is decent enough.
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
····@mail.ru (Timofei Shatrov) writes:
> This analogy is rather flawed. In OSS case, some talented engineer
> can add some device to the car, and then, somehow, give this
> upgraded car for free to anyone who wants it. Oh wait, that doesn't
> make sense. Mimesis is broken. Bad analogy, bad.
All analogies are bad; it was my mistake to include one in my original
post, since people are now pointing out why the analogy doesn't work
instead of refuting my main argument.
> You just can't compare software and "hardware". Software is free to
> reproduce and software companies make money out of thin
> air. Hardware costs money to reproduce, and you pay the cost of
> reproducing it, not the cost of designing it or something like that.
I'm well aware of the difference between hardware and software and the
difference between variable and fixed costs. Nevertheless, I still
hold to my original point: if people choose not to recoup the costs of
developing and/or producing any product and give it away for free,
standards fall and well-designed products are harder to sell, since
they have to justify a price that includes the cost of development
while their free competitors do not. If people resort to the free
alternative, the better solutions are more likely to lose ground to
inferior but free solutions.
So I think we can agree that the availability of a free, "good enough"
solution will be attractive to many people, and will drive business
away from companies that are producing high-caliber software, but have
to recoup the costs of development. I don't think it's a huge logical
leap to point out this trend leads to lower software quality overall
and takes computing backwards instead of forwards. I think Ken is on
to something too that all of this time spent dabbling in open-source
stuff causes people to miss out on Lisp opportunities that could break
Lisp into the big time.
> A better analogy would be: some billionaire designs a crappy car and
> gives the design to anyone for free. You can see how your whole
> arguments falls apart. Car companies actually benefit in this case,
> because they can take the basic design and add mods until the car is
> decent enough.
My argument doesn't fall apart (in any case, this is now your argument
- not mine). Car companies ignore the design because it's crappy, and
because it's not being produced price-free as competition. Sorry.
> --
> |Don't believe this - you're not worthless ,gr---------.ru
> |It's us against millions and we can't take them all... | ue il |
> |But we can take them on! | @ma |
> | (A Wilhelm Scream - The Rip) |______________|
A Wilhelm Scream? Come on...
Bill Atkins wrote:
> while their free competitors do not. If people resort to the free
> alternative, the better solutions are more likely to lose ground to
> inferior but free solutions.
Once people focus on that free solution, however, it usually doesn't
take long until it is no longer inferior.
> So I think we can agree that the availability of a free, "good enough"
> solution will be attractive to many people, and will drive business
> away from companies that are producing high-caliber software, but have
> to recoup the costs of development.
As others have already pointed out, they can recoup the costs of
development by other means, like selling support and services.
Many companies do this with free software.
> I don't think it's a huge logical
> leap to point out this trend leads to lower software quality overall
> and takes computing backwards instead of forwards.
I don't think that's necessarily true. There is enough high quality
free software to suggest that it's not that simple.
> I think Ken is on
> to something too that all of this time spent dabbling in open-source
> stuff causes people to miss out on Lisp opportunities that could break
> Lisp into the big time.
It's short-sighted to say that free, "good enough" quality
implementations of Common Lisp are bad for the community. Yes, they
might be bad for commercial Common Lisp vendors, if they can't keep
up the innovation and provide enough value over the free
implementation of Common Lisp. If the commercial vendors are that
important to the community, then it may be bad. From what I've
seen, they're not.
However, pointing the finger at the SBCL development team is wrong.
Franz and others are not just competing with other vendors of CL,
they are competing with all language providers, whether it's CL or
something else. You can't deny that it's a very good argument for
any language to be able to say that "yes, we have this really good
implementation that you can get for free, of course you don't have
to pay royalties".
Python, Perl, Ruby, Java, C# - you can use any of them without
having to pay anything at all. If someone is looking for a language
to learn (and/or use for a commercial project), he'd be wise to
pick any language that has no cost for him, and there are plenty
to choose from. This is the competition Franz and LW are up against;
it's not just SBCL.
That's the way the market is today, and you might not like it.
Franz and LW probably hate it. That doesn't matter, because it's
just the way it is. Companies will adapt to the market or die, and
if they do die, we might lose many fine products and ideas.
Sad, but that's capitalism.
>>>>> "JW" == Joel Wilsson <············@gmail.com> writes:
JW> Once people focus on that free solution, however, it usually
JW> doesn't take long until it is no longer inferior.
>> So I think we can agree that the availability of a free, "good
>> enough" solution will be attractive to many people, and will
>> drive business away from companies that are producing
>> high-caliber software, but have to recoup the costs of
>> development.
JW> As others have already pointed out, they can recoup the costs
JW> of development by other means, like selling support and
JW> services. Many companies do this with free software.
And, if the architecture of the free software is decent and it's
licensed in a way that allows it, the high-caliber software company
can use the free, "good enough" solution for some things, improve on
it in others, and combine it with custom high-caliber software as
appropriate.
Your argument would have me believe that Mac OS X, as an example,
would be *better* if Apple had built it from the ground up as
proprietary software, rather than building on the open-source BSDs. I
offer you OS 9 and the Copland project as counterexamples: the former
was collapsing under its own weight and the legacy of design decisions
that made a lot more sense in 1984 or 1991 than they did in 2001, and
the latter was the failed attempt at re-engineering the former from
the ground up.
The thing actually sucking the money that would otherwise pay the cost
of development out of the software market is the GPL, which says you
can't take software licensed under the GPL, modify it, and release the
changes without also releasing the source code. This means that if
any high-value change to the software has to be paid for in advance;
you can't produce the change and then sell it to make up the
development cost, because the first person you sell it to can
redistribute it for free under the terms of the license. This is
intentional, and is widely considered a feature by those who do not
depend on selling software to make a living.
Charlton
--
Charlton Wilbur
·······@chromatico.net
Charlton Wilbur wrote:
> >>>>> "JW" == Joel Wilsson <············@gmail.com> writes:
>
> JW> Once people focus on that free solution, however, it usually
> JW> doesn't take long until it is no longer inferior.
>
> JW> As others have already pointed out, they can recoup the costs
> JW> of development by other means, like selling support and
> JW> services. Many companies do this with free software.
>
> Your argument would have me believe that Mac OS X, as an example,
> would be *better* if Apple had built it from the ground up as
> proprietary software, rather than building on the open-source BSDs. I
> offer you OS 9 and the Copland project as counterexamples
I have no idea how you got that from my post. I don't think that
Mac OS X would be better if it had been built from the ground up
as proprietary software. Maybe if you misread my post as if I was
saying that all free software was inferior... but that would take
some pretty creative interpretation, and it's certainly not what
I meant.
Indeed, I use OS X, and that would never have happened if there
wasn't a *nix system beneath the shiny interface. Please don't put
words in my mouth.
I think it was a very good business move to base OS X on BSD.
It's the main reason why Macs are popular among hackers nowadays.
>>>>> "JW" == Joel Wilsson <············@gmail.com> writes:
JW> Charlton Wilbur wrote:
>> Your argument would have me believe that Mac OS X, as an
>> example, would be *better* if Apple had built it from the
>> ground up as proprietary software, rather than building on the
>> open-source BSDs. I offer you OS 9 and the Copland project as
>> counterexamples
JW> I have no idea how you got that from my post.
It was carelessness on my part; I was disagreeing with Bill Atkins and
agreeing with you, in a response to a post you made, and should have
been more specific in the "your."
Charlton
--
Charlton Wilbur
·······@chromatico.net
"Joel Wilsson" <············@gmail.com> writes:
> That's the way the market is today, and you might not like it.
> Franz and LW probably hate it.
I won't speak for Franz on this, but I'll tell you what I hated; I
hated the mid-90's - Lisp Companies were dying left and right; we were
barely scraping by, and Lisp itself was deemed "dead" by many software
experts. Obviously things have turned around. If those of you guys
on c.l.l who really insist on renaming Lisp to something else, why not
try Lazarus...
Life would obviously be easier in a world where competition is less
stiff, but I'd much rather compete in a game that is popular enough to
have many competitors, than to compete in a game about which nobody
cares.
--
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
Bill Atkins <······@rpi.edu> writes:
> ····@mail.ru (Timofei Shatrov) writes:
>
>> This analogy is rather flawed. In OSS case, some talented engineer
>> can add some device to the car, and then, somehow, give this
>> upgraded car for free to anyone who wants it. Oh wait, that doesn't
>> make sense. Mimesis is broken. Bad analogy, bad.
>
> All analogies are bad; it was my mistake to include one in my original
> post, since people are now pointing out why the analogy doesn't work
> instead of refuting my main argument.
>
>> You just can't compare software and "hardware". Software is free to
>> reproduce and software companies make money out of thin
>> air. Hardware costs money to reproduce, and you pay the cost of
>> reproducing it, not the cost of designing it or something like that.
>
> I'm well aware of the difference between hardware and software and the
> difference between variable and fixed costs. Nevertheless, I still
> hold to my original point: if people choose not to recoup the costs of
> developing and/or producing any product and give it away for free,
> standards fall and well-designed products are harder to sell, since
> they have to justify a price that includes the cost of development
> while their free competitors do not. If people resort to the free
> alternative, the better solutions are more likely to lose ground to
> inferior but free solutions.
>
> So I think we can agree that the availability of a free, "good enough"
> solution will be attractive to many people, and will drive business
> away from companies that are producing high-caliber software, but have
> to recoup the costs of development. I don't think it's a huge logical
> leap to point out this trend leads to lower software quality overall
> and takes computing backwards instead of forwards. I think Ken is on
> to something too that all of this time spent dabbling in open-source
> stuff causes people to miss out on Lisp opportunities that could break
> Lisp into the big time.
>
>> A better analogy would be: some billionaire designs a crappy car and
>> gives the design to anyone for free. You can see how your whole
>> arguments falls apart. Car companies actually benefit in this case,
>> because they can take the basic design and add mods until the car is
>> decent enough.
>
> My argument doesn't fall apart (in any case, this is now your argument
> - not mine). Car companies ignore the design because it's crappy, and
> because it's not being produced price-free as competition. Sorry.
>
>> --
>> |Don't believe this - you're not worthless ,gr---------.ru
>> |It's us against millions and we can't take them all... | ue il |
>> |But we can take them on! | @ma |
>> | (A Wilhelm Scream - The Rip) |______________|
>
> A Wilhelm Scream? Come on...
All right, I feel very responsible for taking this thread way off
topic and for ranting in such an inflammatory way. So I am going to
duck out of this argument. I don't think anyone's point of view is
going to be affected by this back-and-forth posting (mine certainly
hasn't). I feel like my replies are getting increasingly snippy and
rude and I am feeling uncomfortably like a troll. Mea culpa,
comp.lang.lisp. Please, carry on. Nothing to see here.
Bill
Bill Atkins <······@rpi.edu> writes:
>>
>> But society hasn't regressed--folks have free cars, leaving them more
>> funds to invest in more useful things.
>
> Sure it has. Society is accepting inferior products and people who
> formerly would have bought cars can't help but opt for the free one.
If costly cars offered value for money, people would pay for them. That
they would not do so indicates that those features obviously aren't
worth enough to them.
Henry Ford put an awful lot of handmade car manufacturers out of
business, and I daresay that a handmade car is in many ways better than
one manufactured on an assembly line. And yet it seems that most people
are happier with inferior cars for less money.
And in the software realm, it typically seems that the inferior software
is proprietary and the superior is free, which is even better. I'm a
Unix sysadmin--while the proprietary Unixes are slightly more stable
than Linux or *BSD, their userlands are embarrassing--beyond
embarrassing, even: they're an insult to any sane admin. And yet things
today are no better than they were half-a-decade ago.
Meanwhile Linux and *BSD offer more pleasant userlands and are quickly
getting more stable.
More to the point: SBCL offers part of what the proprietary Lisp
implementations offer; if the additional features are actually
worthwhile, people with either pay for them or reimplement them.
Meanwhile everyone has access to a good-quality Common Lisp
implementation, which is hardly a bad thing.
In fact, I would go so far as to argue that a free language
implementation, while neither necessary nor sufficient, greatly
increases a language's chances of success nowadays. There are other
ways, e.g. marketing (how Java succeeded) or muscle (how C# appears to
be succeeding), but being free certainly appears to have helped Perl,
Python, Ruby, Objective-C and so forth.
--
Robert Uhl <http://public.xdi.org/=ruhl>
After you've heard two eyewitness accounts of an accident, it makes you
wonder about history. --Dave Barry
Robert Uhl <·········@NOSPAMgmail.com> writes:
> If costly cars offered value for money, people would pay for them. That
> they would not do so indicates that those features obviously aren't
> worth enough to them.
But they do offer value for the money; their price gets distorted when
you have someone giving away cars for free.
> Henry Ford put an awful lot of handmade car manufacturers out of
> business, and I daresay that a handmade car is in many ways better than
> one manufactured on an assembly line. And yet it seems that most people
> are happier with inferior cars for less money.
Handmade cars are also so hard to make that the only company who makes
cars that way now is Rolls Royce (AFAIK). But you also have to pay
like $400,000.
The assembly line lets car companies make more cars, so more people
can get transportation. This is good. The crucial thing is that even
companies that use the assembly line don't give their cars away for
free.
I really regret making this car analogy.
> After you've heard two eyewitness accounts of an accident, it makes you
> wonder about history. --Dave Barry
:-)
Bill Atkins wrote:
> Robert Uhl <·········@NOSPAMgmail.com> writes:
>
> > If costly cars offered value for money, people would pay for them. That
> > they would not do so indicates that those features obviously aren't
> > worth enough to them.
>
> But they do offer value for the money; their price gets distorted when
> you have someone giving away cars for free.
>
> > Henry Ford put an awful lot of handmade car manufacturers out of
> > business, and I daresay that a handmade car is in many ways better than
> > one manufactured on an assembly line. And yet it seems that most people
> > are happier with inferior cars for less money.
>
> Handmade cars are also so hard to make that the only company who makes
> cars that way now is Rolls Royce (AFAIK). But you also have to pay
> like $400,000.
>
> The assembly line lets car companies make more cars, so more people
> can get transportation. This is good. The crucial thing is that even
> companies that use the assembly line don't give their cars away for
> free.
What is the difference between the a price differential between two
items where both have finite price, and another price differential
where one of the items is free?
You seem to be saying one of them is a part of the market system and
the other is a distortion of the market. I don't really see much
difference between them. Whether either are considered distortions is
very much a matter of point-of-view.
Robert Uhl <·········@NOSPAMgmail.com> writes:
> Bill Atkins <······@rpi.edu> writes:
>
> > If I were a multimillionaire and I started giving away
> > shoddily-manufactured cars for free as a charity, many people would
> > undoubtedly put up with the lower quality to save the purchase price,
> > even if it only plays cassettes, breaks down once a month, and has no
> > air conditioning. Much as in the scenario we're talking about, the
> > auto industry would get wrecked, because I'm not charging people for
> > the costs of developing and manufacturing the cars. But note that
> > society has progressed backwards - people have given up reliable cars,
> > CD players, air conditioning, etc.
>
> But society hasn't regressed--folks have free cars, leaving them more
> funds to invest in more useful things.
LOL!
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
Bill Atkins ha escrito:
> "Rob Thorpe" <·······@realworldtech.com> writes:
>
> > I love the way people rubbishing free and open-source software always
> > say:-
> > 1. It's bad.
> > 2. But it's really hurting the commercial competition.
>
> Why are you being sarcastic? It's perfectly valid thinking. Faced
> with the choice between a free program that does 70% of what they want
> mostly well (but costs nothing) and a commercial program that does
> exactly what they want and does it very well (but costs money), many
> people will settle for the free version.
>
> It's harder for commercial software to be profitable when competing
> against free software because vendors need to convince their customers
> that they should pay for all of the costs of development to gain just
> a few extra features. If free software were not free (as in beer),
> it would be easier to make a living selling commercial software.
That's nice! Isn't it crude capitalism? :-)
Or, do you want to regulate people when they produce free software if
they want to? This is closer to socialism, communism and corporatism.
I clearly prefer freedom.
> It's pretty tough to argue against this point. You could say that in
> some cases free software is better than commercial software
> (e.g. Emacs vs. Notepad) or that free software makes you a happier
> human being, but I don't see how you can deny that no-cost software
> will hurt the software industry. If I were a multimillionaire and I
> started giving away shoddily-manufactured cars for free as a charity,
> many people would undoubtedly put up with the lower quality to save
> the purchase price, even if it only plays cassettes, breaks down once
> a month, and has no air conditioning.
Stop there! Cars need to be assembled, and the material of every unit
cost money.
Software has no material, and does not need to be assembled if you
want, so your analogy is completely incorrect.
And look at Franz... are they making profit because their software is
closed, or because they are doing support and consulting? ...think
about it.
"Javier" <·······@gmail.com> writes:
> That's nice! Isn't it crude capitalism? :-)
> Or, do you want to regulate people when they produce free software if
> they want to? This is closer to socialism, communism and corporatism.
> I clearly prefer freedom.
Whoa, where did I say government should regulate this? In fact, where
did I say that anything at all should be done about the situation?
> Stop there! Cars need to be assembled, and the material of every unit
> cost money.
> Software has no material, and does not need to be assembled if you
> want, so your analogy is completely incorrect.
All analogies are incorrect, by definition. But it doesn't matter if
the cost of software (time and talent) is fixed or variable. There
are still costs, even if those costs are fixed and even if they don't
involve purchasing material.
> And look at Franz... are they making profit because their software is
> closed, or because they are doing support and consulting? ...think
> about it.
Both? People that don't want support and consulting still pay Franz
(lots of) money to use their software.
Bill Atkins wrote:
> "Javier" <·······@gmail.com> writes:
>
> > That's nice! Isn't it crude capitalism? :-)
> > Or, do you want to regulate people when they produce free software if
> > they want to? This is closer to socialism, communism and corporatism.
> > I clearly prefer freedom.
>
> Whoa, where did I say government should regulate this? In fact, where
> did I say that anything at all should be done about the situation?
>
> > Stop there! Cars need to be assembled, and the material of every unit
> > cost money.
> > Software has no material, and does not need to be assembled if you
> > want, so your analogy is completely incorrect.
>
> All analogies are incorrect, by definition. But it doesn't matter if
> the cost of software (time and talent) is fixed or variable. There
> are still costs, even if those costs are fixed and even if they don't
> involve purchasing material.
>
> > And look at Franz... are they making profit because their software is
> > closed, or because they are doing support and consulting? ...think
> > about it.
>
> Both? People that don't want support and consulting still pay Franz
> (lots of) money to use their software.
No offense, I don't think that you really have thought out your
argument very well.
Markets change, and so do business models. The fact is that a good
deal of the market is moving towards FOSS (Free/Open Source) software.
Software distribution over the internet has gotten very cheap, and a
lot of companies and individuals have figured out that they can save a
whole lot of money and time polling resources. Sure, this sucks for
many software companies that are used to making proprietary software
that has free alternatives, but the software industry is constantly
evolving.
I have worked with companies that have used FOSS software to their
advantage: selling services, taking an application and improving it for
their own use (and contributing the source back). I have been paid to
make improvements to FOSS software, and there are businesses that make
money selling and supporting it.
I don't see how FOSS is hurting the market. It has opened it up for a
lot of companies. There will always be companies that sell proprietary
software, and there will be others who compete with them.
You could flood the market with poorly made cheap or even free cars. I
doubt that Mercedes, BMW, or Lexus would be hit too hard. They sell
cheap fake cheese at my grocery store that almost tastes like cheese,
but I (and a lot of you, from the insane amount of cheese choices
available) still pay more to eat the real stuff.
Chris
"Chris Parker" <··········@gmail.com> writes:
> No offense, I don't think that you really have thought out your
> argument very well.
Perhaps so. I'm somewhat biased by my own experiences. I ran Linux
and various other open-source packages for four years. I now feel
like I wasted a tremendous amount of time trying to get half-assed
stuff to work and putting up with a computer that wasn't as useful as
it could be.
> Markets change, and so do business models. The fact is that a good
> deal of the market is moving towards FOSS (Free/Open Source) software.
> Software distribution over the internet has gotten very cheap, and a
> lot of companies and individuals have figured out that they can save a
> whole lot of money and time polling resources. Sure, this sucks for
> many software companies that are used to making proprietary software
> that has free alternatives, but the software industry is constantly
> evolving.
Free software is not part of the market, since nothing is being
exchanged for it. It would be more like a public good.
> I have worked with companies that have used FOSS software to their
> advantage: selling services, taking an application and improving it for
> their own use (and contributing the source back). I have been paid to
> make improvements to FOSS software, and there are businesses that make
> money selling and supporting it.
>
> I don't see how FOSS is hurting the market. It has opened it up for a
> lot of companies. There will always be companies that sell proprietary
> software, and there will be others who compete with them.
>
> You could flood the market with poorly made cheap or even free cars. I
> doubt that Mercedes, BMW, or Lexus would be hit too hard. They sell
True. But the many, many people who realize they could save 15k by
going for the free car would make an appreciable impact on the market.
> cheap fake cheese at my grocery store that almost tastes like cheese,
> but I (and a lot of you, from the insane amount of cheese choices
> available) still pay more to eat the real stuff.
But the cheese still has a price. It is not free.
Bill Atkins wrote:
> Perhaps so. I'm somewhat biased by my own experiences. I ran Linux
> and various other open-source packages for four years. I now feel
> like I wasted a tremendous amount of time trying to get half-assed
> stuff to work and putting up with a computer that wasn't as useful as
> it could be.
Isn't this kind of a counter-example to your original point, about
people settling for half-assed (or 70%-assed) stuff 'cause it's free?
After all, you didn't.
Cheers,
Pillsy
(message (Hello 'Bill)
(you :wrote :on '(Thu, 30 Nov 2006 15:21:41 -0500))
(
BA> human being, but I don't see how you can deny that no-cost software
BA> will hurt the software industry.
oh, tell this to SUN Microsystems that recently made Java open-source. it
was free before, but now it's open-source -- that means they encourage
making customized implementations.
SUN did that because they care about the community.
and SUN was able to create community around Java. the community that orders
of magnitude larger that lisp's community.
and SUN makes incomes order of magnitued larger than Franz and Lispworks
do.
so no-cost software is exactly a part of business, but it's a bit more
complex than selling food or selling cars.
software can be given for no-cost to create community arround it, and then
it can be charged for addons and support.
yes, Franz and Lispworks offer free personal/trial versions, but they are
trials not useful of itself -- it's heap-limited, time-limited,
feature-limited.
with free Java implementation i can either establish a web-server, or make a
GUI or console application. can i do that with Franz or Lispworks?
hell no, it's only suitable for some experiments, at most.
so, free Common Lisp implementations are very important for Lisp community.
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
"Alex Mizrahi" <········@users.sourceforge.net> writes:
> (message (Hello 'Bill)
> (you :wrote :on '(Thu, 30 Nov 2006 15:21:41 -0500))
> (
>
> BA> human being, but I don't see how you can deny that no-cost software
> BA> will hurt the software industry.
>
> oh, tell this to SUN Microsystems that recently made Java open-source. it
> was free before, but now it's open-source
Come on - this is totally irrelevant and you should know it is.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
On 2006-11-30 21:55:20 +0000, "Alex Mizrahi"
<········@users.sourceforge.net> said:
> oh, tell this to SUN Microsystems that recently made Java open-source.
> it was free before, but now it's open-source -- that means they
> encourage making customized implementations.
> SUN did that because they care about the community.
This explains everything. Some bloody bunch of hippies have taken them
over (I mean, look at that Schwartz guy, hair down to his waist) & are
busy caring about `the community' when they should be caring about `the
shareholders'. Kick em out and replace them with Bill Gates, I say.
You don't see him doing this whole open-source thing, do you now?
Bloody hippies.
--tim
Tim Bradshaw wrote:
> Kick em out and replace them with Bill Gates, I say.
> You don't see him doing this whole open-source thing, do you now?
but at least Microsoft has Shared Source and some development tools are
free:
http://www.microsoft.com/resources/sharedsource/default.mspx
http://msdn.microsoft.com/vstudio/express/default.aspx
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
(message (Hello 'Tim)
(you :wrote :on '(Thu, 30 Nov 2006 23:18:31 +0000))
(
TB> This explains everything. Some bloody bunch of hippies have taken them
TB> over (I mean, look at that Schwartz guy, hair down to his waist) & are
TB> busy caring about `the community' when they should be caring about `the
TB> shareholders'. Kick em out and replace them with Bill Gates, I say.
TB> You don't see him doing this whole open-source thing, do you now?
hell no, Microsoft gives their compiler for free, charging only for
additional libraries and IDE.
you can create applications using Microsoft tools for free.
Microsoft cares that there are a lot of applications for Windows.
do lisp vendos care that much about lisp?
certainly, if lisp community grows, sales of lisp vendors can be increased,
so more people would be involved, and more of them will buy their
implementations for additional features. also, they can lower prices, so
more people would buy that.
it's a complex inter-induction process, requiring much more analysis than
simple selling stuff.
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
"Alex Mizrahi" <········@users.sourceforge.net> writes:
> hell no, Microsoft gives their compiler for free, charging only for
> additional libraries and IDE.
> you can create applications using Microsoft tools for free.
> Microsoft cares that there are a lot of applications for Windows.
Microsoft makes almost all of its revenue from Windows and Office.
Giving away development tools simply helps boost revenue for Windows.
This is why they care. How does this apply to the Lisp vendors? (the
tables have turned, now I'm criticizing an analogy...)
> certainly, if lisp community grows, sales of lisp vendors can be increased,
> so more people would be involved, and more of them will buy their
> implementations for additional features. also, they can lower prices, so
> more people would buy that.
> it's a complex inter-induction process, requiring much more analysis than
> simple selling stuff.
It is pretty complex (though I don't know for sure if it involves
"inter-induction"), but somehow you seem to grasp the intricacies of
it better than the vendors themselves, who have been getting along
quite well for decades.
(message (Hello 'Bill)
(you :wrote :on '(Fri, 01 Dec 2006 04:51:10 -0500))
(
BA> Microsoft makes almost all of its revenue from Windows and Office.
BA> Giving away development tools simply helps boost revenue for Windows.
BA> This is why they care. How does this apply to the Lisp vendors? (the
BA> tables have turned, now I'm criticizing an analogy...)
they could give-away basic set of tools that is not suitable for comfortable
development, but is suitable for deployment.
and sell IDE and libs that serious developers would buy (if they've already
made a product that was shipped, they will buy additional comfort from same
vendor for sure).
SBCL is exactly like that -- it's suitable for deployment, but development
might be not-so-comfortable. but if people are not sure about how they
product goes, or just experimenting and learning, they will get SBCL rather
then Lispworks. but if they create a product, will they switch from SBCL to
Lispworks? unlikely.
??>> certainly, if lisp community grows, sales of lisp vendors can be
??>> increased, so more people would be involved, and more of them will buy
??>> their implementations for additional features. also, they can lower
??>> prices, so more people would buy that. it's a complex inter-induction
??>> process, requiring much more analysis than simple selling stuff.
BA> It is pretty complex (though I don't know for sure if it involves
BA> "inter-induction"), but somehow you seem to grasp the intricacies of
BA> it better than the vendors themselves, who have been getting along
BA> quite well for decades.
i don't think they get quite well -- Microsoft and SUN Microsystems managed
to get their .net and Java languages/environments to get popular in shortest
periods of time, and now they are very popular, and used widely for web
development (i think Microsoft understands that desktop OS market can
collapse with move to the web-applications, thus they have established a web
platform).
at same time, Lisp vendors, having Lisp that should be superior to .net and
Java (*), did not grow community comarable to above ones. certainly, they
have some sales -- but it's not a greate achievement, since Lisp has
40-years history, and they can sell some products without much inovations
just to support old needs.
(*) one can say that C#/Java are different since they have static typing,
but i think it's not that hard to make same thing for lisp -- with type
inference like in ML or Haskell -- so Lisp should be better in all aspects.
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
On Fri, 01 Dec 2006 11:46:31 +0100, Alex Mizrahi
<········@users.sourceforge.net> wrote:
>
> ??>> certainly, if lisp community grows, sales of lisp vendors can be
> ??>> increased, so more people would be involved, and more of them will
> buy
> ??>> their implementations for additional features. also, they can lower
> ??>> prices, so more people would buy that. it's a complex
> inter-induction
> ??>> process, requiring much more analysis than simple selling stuff.
>
> BA> It is pretty complex (though I don't know for sure if it involves
> BA> "inter-induction"), but somehow you seem to grasp the intricacies of
> BA> it better than the vendors themselves, who have been getting along
> BA> quite well for decades.
>
I fail to see the comparison. .NET is a ibrary which is language
independent
automatizing some of the managament necessary under COM. Java's cross
compatible libraries
makes it popular. How does Lisp compete? Lisp can also use .NET and Java
libraries.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
(message (Hello 'John)
(you :wrote :on '(Fri, 01 Dec 2006 13:07:04 +0100))
(
JT> I fail to see the comparison. .NET is a ibrary which is language
JT> independent
JT> automatizing some of the managament necessary under COM.
.net is a buzzword for a set of technologies.
i meant mainly the Common Language Infrastructure -- basically it's a
byte-code interpreter/JIT-compiler standartized by ECMA.
it appears to be less braindamaged than Java -- you can make object files
other than "class" files.
and it's a programming language -- C#, i think it's most popular with .net.
there is a totally free implementation -- Mono
(http://www.mono-project.com/Main_Page). they have all the libraries,
compilers, runtime environments.
JT> Java's cross compatible libraries
JT> makes it popular. How does Lisp compete? Lisp can also use .NET and
JT> Java libraries.
i'd like to see lisp runtime environment as solid as Java's and .net's.
Java is designed to be runned on multi-processor multi-core systems at it's
full speed. it has 4+ types GCs -- including parrallel ones (for example, on
Sun Fire T2000 server that is able to schedule 32 threads, SUN is running GC
in 8 threads), low-pause and incremental.
is there lisp "runtime environment" with comparable characteristics? well,
Scieneer Common Lisp is meant to run on multiple processors, but it costs
about 3000$ per installation, while Java and .net installations are free.
there's a lot of libraries for web development in lisp, but can they deliver
same stability and performance as Java and .net?
i've evaluated UCW running on SBCL -- it's simply slow. sometimes it does
"full gc" that stops execution for a few seconds. sometimes it just
crashes.. :-/
you say i should buy a commercial implementation? maybe, but it doesn't
scale to multiple cores, so what a hell should i if i can get Java or .net
for free -- and does it better?
i'm currently using Armed Bear Common Lisp implementation that runs on top
of JVM. i've hacked a small 'web-framework' that is very good for
prototyping. if i'll find that it's too unstable for production environment,
i can switch to pure Java.
so here is how Common Lisp competes with Java.
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
Alex Mizrahi wrote:
[...]
> is there lisp "runtime environment" with comparable characteristics? well,
> Scieneer Common Lisp is meant to run on multiple processors, but it costs
> about 3000$ per installation, while Java and .net installations are free.
[...]
> you say i should buy a commercial implementation? maybe, but it doesn't
> scale to multiple cores, so what a hell should i if i can get Java or .net
> for free -- and does it better?
Huh? You just said SCL did scale to multiple cores. Where's the beef?
Besides, even if SCL is too expensive or whatever, your complaints
might be better directed at Lispworks, Franz and Corman. The more money
they think they're leaving on the table by not having threading that's
competitive with .Net and Java, the more likely they are to do
something about it.
Cheers,
Pillsy
On 2006-12-01 12:45:06 +0000, "Alex Mizrahi"
<········@users.sourceforge.net> said:
> you say i should buy a commercial implementation? maybe, but it doesn't
> scale to multiple cores, so what a hell should i if i can get Java or
> .net for free -- and does it better?
Well, do that then. For fucks sake just STOP WHINING.
Tim Bradshaw <···@tfeb.org> writes:
> On 2006-12-01 12:45:06 +0000, "Alex Mizrahi"
> <········@users.sourceforge.net> said:
>
>> you say i should buy a commercial implementation? maybe, but it
>> doesn't scale to multiple cores, so what a hell should i if i can
>> get Java or .net for free -- and does it better?
>
> Well, do that then. For fucks sake just STOP WHINING.
The problem is that the people who are WHINING are the
anti-free-software folks. I refer you to a long thread about this
very issue from a few months ago: suffice to say that there is *ZERO*
quantifiable evidence that free software hurts the proprietary
software market. If you want to convince anyone who's not already
convinced, that would be a good place to start.
Oh and your argument about having to waste time on printing labels by
hand is not an argument against free software -- it is an argument
against management stupidity.
rsi
--
<···@panix.com> a.k.a. Rajappa Iyer.
They also surf who stand in the waves.
On 2006-12-01 22:27:50 +0000, Rajappa Iyer <···@panix.com> said:
>
> The problem is that the people who are WHINING are the
> anti-free-software folks.
Where did I even mention free software? I was just asking him to stop
whining. I don't care if he's pro free software, anti free software
(whatever those terms might mean), or a space alien. I just want him
to shut up and go away rather than sitting there complaining that he
can't get what he wants, since he can, in fact, get what he wants.
> Oh and your argument about having to waste time on printing labels by
> hand is not an argument against free software -- it is an argument
> against management stupidity.
Um, hello? Did you read the last paragraph? I'll repeat it. "Damn, you
have no idea how much I wish people had basic (basic) economic
literacy. They should teach it instead of CS, it would be a lot more
useful."
Now is that an argument against free software? No, it's not. It looks
like an argument for basic economic literacy to me.
So stop putting words in my mouth, why don't you?
--tim
Tim Bradshaw <···@tfeb.org> writes:
> On 2006-12-01 22:27:50 +0000, Rajappa Iyer <···@panix.com> said:
>>
>> The problem is that the people who are WHINING are the
>> anti-free-software folks.
>
> Where did I even mention free software? I was just asking him to stop
> whining. I don't care if he's pro free software, anti free software
> (whatever those terms might mean), or a space alien. I just want him
> to shut up and go away rather than sitting there complaining that he
> can't get what he wants, since he can, in fact, get what he wants.
OK. I re-read what you wrote and agree that you were even-handed about
telling whiners on either side to put a sock in it. :-)
Sorry for implying otherwise.
rsi
--
<···@panix.com> a.k.a. Rajappa Iyer.
They also surf who stand in the waves.
On 2006-12-01 22:59:18 +0000, Rajappa Iyer <···@panix.com> said:
> OK. I re-read what you wrote and agree that you were even-handed about
> telling whiners on either side to put a sock in it. :-)
Exactly, I just want people to get on and do stuff, whether commercial
or free, and stop keening about how they can't.
>
> Sorry for implying otherwise.
Thanks, apology accepted.
(message (Hello 'Tim)
(you :wrote :on '(Fri, 1 Dec 2006 22:47:10 +0000))
(
TB> (whatever those terms might mean), or a space alien. I just want him
TB> to shut up and go away rather than sitting there complaining that he
TB> can't get what he wants, since he can, in fact, get what he wants.
yes, i've even mentionet what i've got -- "i'm currently using Armed Bear
Common Lisp implementation that runs on top of JVM."
i don't see why you qualify my post as WHINING -- i've exactly answered why
i think Common Lisp competes with Java.
btw i'm going to publically release open-source framework that makes a
bridge between Java Servlet Container and the Armed Bear Common Lisp.
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
On Fri, 1 Dec 2006 11:15:17 +0200, "Alex Mizrahi"
<········@users.sourceforge.net> wrote:
>(message (Hello 'Tim)
>(you :wrote :on '(Thu, 30 Nov 2006 23:18:31 +0000))
>(
>
> TB> This explains everything. Some bloody bunch of hippies have taken them
> TB> over (I mean, look at that Schwartz guy, hair down to his waist) & are
> TB> busy caring about `the community' when they should be caring about `the
> TB> shareholders'. Kick em out and replace them with Bill Gates, I say.
> TB> You don't see him doing this whole open-source thing, do you now?
>
>hell no, Microsoft gives their compiler for free, charging only for
>additional libraries and IDE.
>you can create applications using Microsoft tools for free.
>Microsoft cares that there are a lot of applications for Windows.
Microsoft giving away tools is a new deal. Up until 2003, Microsoft
considered developer tools and, in particular, API documentation to be
a revenue source just like any other.
And the price of support has gone up ... the professional edition of
VS2003 with MSDN subscription cost about $900 (I'd have to look up the
bill to be sure but $899 sticks in my brain), the current professional
edition of VS2005 with MSDN subscription costs $1199.
The free tools come with zero support.
I don't know about you, but using MSDN on the web is about as much fun
as pulling teeth. The only times it works acceptably are when the US
and Europe are sleeping. Buying it on DVD for $799/yr is all but a
necessity if you want decent access.
George
--
for email reply remove "/" from address
Tim Bradshaw wrote:
> On 2006-11-30 21:55:20 +0000, "Alex Mizrahi"
> <········@users.sourceforge.net> said:
>
> > oh, tell this to SUN Microsystems that recently made Java open-source.
> > it was free before, but now it's open-source -- that means they
> > encourage making customized implementations.
> > SUN did that because they care about the community.
>
> This explains everything. Some bloody bunch of hippies have taken them
> over (I mean, look at that Schwartz guy, hair down to his waist) & are
> busy caring about `the community' when they should be caring about `the
> shareholders'. Kick em out and replace them with Bill Gates, I say.
> You don't see him doing this whole open-source thing, do you now?
>
> Bloody hippies.
>
> --tim
you seem to have a very angry outlook on the world, I am sorry that
your life has formed such
a intolerant perspective towards others, and such a obvious glee in
watching people struggle
against each other in a hostile fashion. It's reminiscent of a plebe
watching the gladiators slaughter
each other in the arena.
I think you need a vacation, or a companion.
···········@gmail.com wrote:
> Tim Bradshaw wrote:
>
>>On 2006-11-30 21:55:20 +0000, "Alex Mizrahi"
>><········@users.sourceforge.net> said:
>>
>>
>>>oh, tell this to SUN Microsystems that recently made Java open-source.
>>>it was free before, but now it's open-source -- that means they
>>>encourage making customized implementations.
>>>SUN did that because they care about the community.
>>
>>This explains everything. Some bloody bunch of hippies have taken them
>>over (I mean, look at that Schwartz guy, hair down to his waist) & are
>>busy caring about `the community' when they should be caring about `the
>>shareholders'. Kick em out and replace them with Bill Gates, I say.
>>You don't see him doing this whole open-source thing, do you now?
>>
>>Bloody hippies.
>>
>>--tim
>
>
> you seem to have a very angry outlook on the world, I am sorry that
> your life has formed such
> a intolerant perspective towards others, and such a obvious glee in
> watching people struggle
> against each other in a hostile fashion. It's reminiscent of a plebe
> watching the gladiators slaughter
> each other in the arena.
>
> I think you need a vacation, or a companion.
>
Thx, we needed that. :)
kzo
ps. I think you need to learn the characters on this sit-com before you
will be able to understand the jokes.
k
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
On 2006-12-05 11:18:59 +0000, ···········@gmail.com said:
> you seem to have a very angry outlook on the world, I am sorry that
> your life has formed such
> a intolerant perspective towards others, and such a obvious glee in
> watching people struggle
> against each other in a hostile fashion.
It. Was. A. Joke.
Sorry not to have included the smiley.
Bill Atkins wrote:
> "Rob Thorpe" <·······@realworldtech.com> writes:
>
> > I love the way people rubbishing free and open-source software always
> > say:-
> > 1. It's bad.
> > 2. But it's really hurting the commercial competition.
>
> Why are you being sarcastic? It's perfectly valid thinking.
Well, I can see where point #2 might be supportable with the correct
data to back it up.
> Faced with the choice between a free program that does 70% of what they want
> mostly well (but costs nothing) and a commercial program that does
> exactly what they want and does it very well (but costs money), many
> people will settle for the free version.
Indeed.. Whether it actually 1) is bad and 2) is really hurting
commercial competition I don't think follows automatically, however. I
would be curious how many people deploying commercial software with the
intent of making $$ would actually rely on a free lisp. I could be
wrong, but most of the uses I have seen thus far of free lisp
implementations are to run free software, not commercial software.
Undoubtedly there are special cases where individual developers use
free lisps doing Real Work (paying commercial work), but I know of no
statistics which would be useful in arguing the point.
For businesses whose goal is to make $$, I think it's quite logical to
get a commercial lisp from a vendor. I might expect that people would
do initial development on a free lisp, hit some roadblocks/problems and
decide that the $$ paid to the commercial vendor for
support/development are well worth it, and switch. (Yay standards.)
For the rest of us, who are programming to have fun/learn something/do
projects that will never be commercially viable, it would never have
made any sense to use a commercial Lisp and if free lisps didn't exist
they just wouldn't get done at all.
> It's harder for commercial software to be profitable when competing
> against free software because vendors need to convince their customers
> that they should pay for all of the costs of development to gain just
> a few extra features. If free software were not free (as in beer),
> it would be easier to make a living selling commercial software.
Out of curiosity, can people cite cases/tell stories where people who
might realistically have used a commercial lisp went with a free one
instead? I understand the theory but I am curious if it actually
happens in practice.
In Real Business Situations I would think having some commercial entity
standing behind a product is a Very Important Feature. If it's your
bottom line that's at stake the extra insurance is what you're really
paying for.
> It's pretty tough to argue against this point.
It's logical enough, if potential commercial sales are in fact being
lost. There are other possible endpoints to the free software game not
yet explored (software that is backed by formal proof logic, for
example, which would never be profitable for most commercial software)
that might produce higher quality software than the commercial process
can produce, but even those would still wind up needing someone to
provide commercial support to those who need it.
> You could say that in
> some cases free software is better than commercial software
> (e.g. Emacs vs. Notepad) or that free software makes you a happier
> human being, but I don't see how you can deny that no-cost software
> will hurt the software industry.
It will result in lost revenue in those cases where a company is
willing to run the risk of using an irregularly supported product. I
have a feeling that such businesses are unlikely to command large
enough revenue streams in today's economy to represent a major loss to
the commercial lisp vendors (would YOU pay lots of money for critical
services/tools to someone whose toolchain doesn't have robust support?)
but I could be wrong. I would like to see some kind of hard numbers
before deciding the point either way. Without those, my sense is that
so far free lisps have been most beneficial to projects that would
never have forked out for commercial tools in the first place, because
they aren't really commercial in nature. (I assume no one will argue
that people are always (or should always be) motivated simply by
profit.)
We'll skip the car analogies - those have been beaten to death.
Instead I'll try to look for a situation that is a match for the one we
are seeing here, and I think the best one is probably commercial Unix
vs. Linux. Linux has replaced commercial Unix in a large number of
situations, it's true. But this has resulted in a new business where
companies like Redhat (and IBM, curiously enough) make lots of money
off of backing this new software commercially. Why would anyone pay
for Unix (or Linux) when you can simply download and use it? Well, of
course many people don't. But those people probably had no strong
motive to pay for commercial Unix, either. What they want to use it
for doesn't pay well enough to support license fees. Larger businesses
who really depend on it WANT to pay for it, to ensure that it will keep
working. From that standpoint, it makes very little difference if the
code is freely available for download - that's not what they want or
need. It does provide confidence that their code can survive the
collapse of a vendor AT NEED, but that is a desperate need and they
won't want it to come to pass.
Arguably, commercial support is always the most compelling reason to
pay money for software anyway. If Photoshop suddenly found a foolproof
way of preventing any illegal free copies of their program from being
made and used, how much would their revenue stream go up? I'm guessing
(and it's JUST a guess, mind you) most of the people not paying for the
software in the first place don't have enough of a revenue stream or
motivation to pay the license fee if compelled to, so they'll just drop
it. (Full disclosure - I use Gimp for what little work I do with
images.)
Community/charity spirit exists in the software world, too. It doesn't
seem to be a problem in the physical world, and I doubt it will be a
problem in the software world - people with money making
companies/products will want stability and reliability. Those of us
doing academic/hobby work on free lisps may not be funding the
commercial lisps, but we do spread the use and knowledge of lisp. In
the end, I'm glad we have Allegro, Lispworks, AND sbcl. I think they
all play their part, and who knows - perhaps in 30 years people will be
wanting to hire Franz to provide commercial support for sbcl.
"C Y" <···········@yahoo.com> writes:
> Indeed.. Whether it actually 1) is bad and 2) is really hurting
> commercial competition I don't think follows automatically, however. I
> would be curious how many people deploying commercial software with the
> intent of making $$ would actually rely on a free lisp. I could be
> wrong, but most of the uses I have seen thus far of free lisp
> implementations are to run free software, not commercial software.
> Undoubtedly there are special cases where individual developers use
> free lisps doing Real Work (paying commercial work), but I know of no
> statistics which would be useful in arguing the point.
One thing to consider is the fear of an expensive unknown. A
commercial CL implementation is not the same as a commercial meat
grinder. With a commercial meat grinder, you know exactly what the
difference in output will be compared to turning the crank by hand on
your consumer meat grinder, and you can accurately budget for it. For
anyone lacking experience with a commercial Lisp, there is no way to
calculate productivity increases that can be expected by switching.
Therefore, buying a license to one is a gamble. The free trial
versions help, but are still crippled to one extent or another
(Allegro gives you no IDE in the trial version so that it is virtually
indistinguishable from a free Lisp and even the LispWorks free trial
has some limitations, although admittedly not as many). When you are
in business, the mere fact of being in business is generally the only
gamble you can justifiably undertake.
> For businesses whose goal is to make $$, I think it's quite logical to
> get a commercial lisp from a vendor. I might expect that people would
> do initial development on a free lisp, hit some roadblocks/problems and
> decide that the $$ paid to the commercial vendor for
> support/development are well worth it, and switch. (Yay standards.)
> For the rest of us, who are programming to have fun/learn something/do
> projects that will never be commercially viable, it would never have
> made any sense to use a commercial Lisp and if free lisps didn't exist
> they just wouldn't get done at all.
I disagree with your conclusion here. I have many hobbies. I can't
think of a single one where I have less than $5,000 of sunk costs in
order to enjoy the hobby. For instance, I play guitar and, by the
time you consider my guitars, amps, recording equipment, and computer
software, I easily have $6,500 into just the items I am tallying in my
head right now. But the enjoyment I get out of the use of these
things greatly exceeds that number, and so the cost-benefit analysis
weighs in favor of purchasing them.
That's the real question here. Can you cost-justify purchasing a
commercial Lisp based on the marginal cost between it and the next
best alternative (i.e. a free Lisp)? While most people likely cannot,
quite a few can.
> Out of curiosity, can people cite cases/tell stories where people who
> might realistically have used a commercial lisp went with a free one
> instead? I understand the theory but I am curious if it actually
> happens in practice.
>
> In Real Business Situations I would think having some commercial entity
> standing behind a product is a Very Important Feature. If it's your
> bottom line that's at stake the extra insurance is what you're really
> paying for.
That's the problem stated above: you aren't purchasing insurance,
because you simply aren't ensuring any particular outcome. If your
bottom line is at stake and you have no way of predicting whether a
substantial (in comparison to your overall budget in a startup
situation) amount of money spent on a Lisp implementation will have
any effect on your bottom line other than the purchase price and a tax
deduction, you will generally decide not to try it.
Ari Johnson wrote:
> One thing to consider is the fear of an expensive unknown. A
> commercial CL implementation is not the same as a commercial meat
> grinder. With a commercial meat grinder, you know exactly what the
> difference in output will be compared to turning the crank by hand on
> your consumer meat grinder, and you can accurately budget for it. For
> anyone lacking experience with a commercial Lisp, there is no way to
> calculate productivity increases that can be expected by switching.
In business, once you scale up past a certain rather small size, it's
not productivity increases you are after so much as having Someone Else
standing behind the product.
In THAT sense, free lisps are an extremely good thing for customers
even if they never use them, because the most compelling argument for
paying $$ to a commercial company is the support they give you
(GUARANTEE to give you, mind) when you use their product. As a few
others have noted, you don't always get good support for commercial
products even if you buy them. If a company has free software
competition however, they MUST provide good support/responsiveness to
distinguish themselves (or justify themselves if you prefer). That's
exactly what a commercial company SHOULD do in any case, so free
software is just one more motivation to actually do it.
> Therefore, buying a license to one is a gamble.
It's a gamble on the quality of the company behind the lisp, more than
anything.
> The free trial
> versions help, but are still crippled to one extent or another
> (Allegro gives you no IDE in the trial version so that it is virtually
> indistinguishable from a free Lisp and even the LispWorks free trial
> has some limitations, although admittedly not as many). When you are
> in business, the mere fact of being in business is generally the only
> gamble you can justifiably undertake.
In the early stages, that's probably true. As companies get larger and
have more $$ at stake with respect to their software (large loses if
something breaks, more customers with more complaints and less time to
deal with each one personally, etc.) the cost benefit analysis of
commercial vs. free software (or more correctly free software without
commercial support) changes.
> > For businesses whose goal is to make $$, I think it's quite logical to
> > get a commercial lisp from a vendor. I might expect that people would
> > do initial development on a free lisp, hit some roadblocks/problems and
> > decide that the $$ paid to the commercial vendor for
> > support/development are well worth it, and switch. (Yay standards.)
> > For the rest of us, who are programming to have fun/learn something/do
> > projects that will never be commercially viable, it would never have
> > made any sense to use a commercial Lisp and if free lisps didn't exist
> > they just wouldn't get done at all.
>
> I disagree with your conclusion here. I have many hobbies. I can't
> think of a single one where I have less than $5,000 of sunk costs in
> order to enjoy the hobby. For instance, I play guitar and, by the
> time you consider my guitars, amps, recording equipment, and computer
> software, I easily have $6,500 into just the items I am tallying in my
> head right now. But the enjoyment I get out of the use of these
> things greatly exceeds that number, and so the cost-benefit analysis
> weighs in favor of purchasing them.
OK, that's a point. But I know in my case, any expensive software
purchase is completely out of the question just for budgetary reasons.
(Heck, I've still got only 256 megs of RAM :-( ) All the projects I'm
interested in doing (computer algebra systems with formal proof logic
behind them, for example) stand small chance of ever being commercially
viable or even interesting. Perhaps someday, if they come out well,
academics might be interested in them, but academics (at least in
physics) don't have very large budgets. Also, in academics an open
solution caries the credibility of being completely available to anyone
who wants to study/test/enhance it, which is excellent future proofing
(no one wants their work to become useless in 30 years if it can be
helped).
I guess I always tend to approach this from the academic side, where
costs loom large and freedom to do whatever I want with the software
looms just as large. From the business side neither of those factors
is (or should be) as critical as functionality and support, so it's
natural there are two ways of looking at this issue.
> That's the real question here. Can you cost-justify purchasing a
> commercial Lisp based on the marginal cost between it and the next
> best alternative (i.e. a free Lisp)? While most people likely cannot,
> quite a few can.
I know I certainly couldn't, but my interests may not be representative
of other cases.
> > In Real Business Situations I would think having some commercial entity
> > standing behind a product is a Very Important Feature. If it's your
> > bottom line that's at stake the extra insurance is what you're really
> > paying for.
>
> That's the problem stated above: you aren't purchasing insurance,
> because you simply aren't ensuring any particular outcome.
Of course you don't ensure a particular outcome, but you do increase
the probability of a consistently good outcome.
> If your bottom line is at stake and you have no way of predicting whether a
> substantial (in comparison to your overall budget in a startup
> situation) amount of money spent on a Lisp implementation will have
> any effect on your bottom line other than the purchase price and a tax
> deduction, you will generally decide not to try it.
Sure, a startup is a good bet to use free lisps. But once they are
making Actual Money, I would expect the equation to shift away from the
free solution to one that has backing from a dedicated service
provider.
Of course, most businesses might never get there. But lowering the
barrier to entry will likely increase the probability that someone will
try one and succeed, because more people will try.
I can even see a case for bundling otherwise free software with a
commercial lisp in some cases. Let's say, for the sake of argument,
that I wanted to make a commercially supported version of Maxima (or
make it Axiom, if GPL issues are going to be a hangup for anyone).
Bundle it up in a box, sell it, and support it. Well Maxima is free
and will remain free, but I have a choice about what lisp to put under
it. If I'm looking at supporting a commercial CAS, one thing I would
like NOT to have to worry about is bugs in the underlying lisp
implementation. But the quality of my product relies on said lisp
implementation functioning properly, so it would be my problem if it
doesn't work. That might make a good case for using Allegro - I have
to pay them some percentage, but I can presumably pass all complaints
that have a root cause in the underlying lisp to them. Franz seems to
have quite a good reputation, so it could very well make sense to do
that. Certainly it would be worth discussing.
Now, the second question would be whether there would be a market for
Maxima in such a configuration (from an academic standpoint I would
prefer the fully open one, myself) but that's a different discussion
and this thread has already gone overlong.
"C Y" <···········@yahoo.com> writes:
> Ari Johnson wrote:
>
>> One thing to consider is the fear of an expensive unknown. A
>> commercial CL implementation is not the same as a commercial meat
>> grinder. With a commercial meat grinder, you know exactly what the
>> difference in output will be compared to turning the crank by hand on
>> your consumer meat grinder, and you can accurately budget for it. For
>> anyone lacking experience with a commercial Lisp, there is no way to
>> calculate productivity increases that can be expected by switching.
>
> In business, once you scale up past a certain rather small size, it's
> not productivity increases you are after so much as having Someone Else
> standing behind the product.
>
> In THAT sense, free lisps are an extremely good thing for customers
> even if they never use them, because the most compelling argument for
> paying $$ to a commercial company is the support they give you
> (GUARANTEE to give you, mind) when you use their product. As a few
> others have noted, you don't always get good support for commercial
> products even if you buy them. If a company has free software
> competition however, they MUST provide good support/responsiveness to
> distinguish themselves (or justify themselves if you prefer). That's
> exactly what a commercial company SHOULD do in any case, so free
> software is just one more motivation to actually do it.
>
>> Therefore, buying a license to one is a gamble.
>
> It's a gamble on the quality of the company behind the lisp, more than
> anything.
It's a gamble on what's behind the curtain. Both features and support
are behind the curtain, in what I suggest are unknowable amounts. The
quality of the company has bearing on both of these, but I have seen
bad products from good companies and good products from bad companies,
so it's not always a good correlation.
>> The free trial
>> versions help, but are still crippled to one extent or another
>> (Allegro gives you no IDE in the trial version so that it is virtually
>> indistinguishable from a free Lisp and even the LispWorks free trial
>> has some limitations, although admittedly not as many). When you are
>> in business, the mere fact of being in business is generally the only
>> gamble you can justifiably undertake.
>
> In the early stages, that's probably true. As companies get larger and
> have more $$ at stake with respect to their software (large loses if
> something breaks, more customers with more complaints and less time to
> deal with each one personally, etc.) the cost benefit analysis of
> commercial vs. free software (or more correctly free software without
> commercial support) changes.
As companies get larger and have more dollars at stake, they also
become more sophisticated and will provide their own support if that
is the most efficient way to do things. That's one reason why FreeBSD
is popular at all and why Linux has some of its popularity: given the
right circumstances and priorities, it is possible that it is more
efficient to support those on your own than it is to hire someone else
to support something else.
I agree that support is an important feature. However, to me it is
just another feature that goes into the calculus of whether something
is worth the price tag.
>> > For businesses whose goal is to make $$, I think it's quite logical to
>> > get a commercial lisp from a vendor. I might expect that people would
>> > do initial development on a free lisp, hit some roadblocks/problems and
>> > decide that the $$ paid to the commercial vendor for
>> > support/development are well worth it, and switch. (Yay standards.)
>> > For the rest of us, who are programming to have fun/learn something/do
>> > projects that will never be commercially viable, it would never have
>> > made any sense to use a commercial Lisp and if free lisps didn't exist
>> > they just wouldn't get done at all.
>>
>> I disagree with your conclusion here. I have many hobbies. I can't
>> think of a single one where I have less than $5,000 of sunk costs in
>> order to enjoy the hobby. For instance, I play guitar and, by the
>> time you consider my guitars, amps, recording equipment, and computer
>> software, I easily have $6,500 into just the items I am tallying in my
>> head right now. But the enjoyment I get out of the use of these
>> things greatly exceeds that number, and so the cost-benefit analysis
>> weighs in favor of purchasing them.
>
> OK, that's a point. But I know in my case, any expensive software
> purchase is completely out of the question just for budgetary reasons.
> (Heck, I've still got only 256 megs of RAM :-( ) All the projects I'm
> interested in doing (computer algebra systems with formal proof logic
> behind them, for example) stand small chance of ever being commercially
> viable or even interesting. Perhaps someday, if they come out well,
> academics might be interested in them, but academics (at least in
> physics) don't have very large budgets. Also, in academics an open
> solution caries the credibility of being completely available to anyone
> who wants to study/test/enhance it, which is excellent future proofing
> (no one wants their work to become useless in 30 years if it can be
> helped).
>
> I guess I always tend to approach this from the academic side, where
> costs loom large and freedom to do whatever I want with the software
> looms just as large. From the business side neither of those factors
> is (or should be) as critical as functionality and support, so it's
> natural there are two ways of looking at this issue.
I do think it would be awfully nice to have an in-between option, but
it's an economic market so it's up to someone in a position to deliver
such an option to decide whether it is a good idea to do so.
>> That's the real question here. Can you cost-justify purchasing a
>> commercial Lisp based on the marginal cost between it and the next
>> best alternative (i.e. a free Lisp)? While most people likely cannot,
>> quite a few can.
>
> I know I certainly couldn't, but my interests may not be representative
> of other cases.
I think in the commercial Lisp area, your interests are in line with
those of the majority.
>> > In Real Business Situations I would think having some commercial entity
>> > standing behind a product is a Very Important Feature. If it's your
>> > bottom line that's at stake the extra insurance is what you're really
>> > paying for.
>>
>> That's the problem stated above: you aren't purchasing insurance,
>> because you simply aren't ensuring any particular outcome.
>
> Of course you don't ensure a particular outcome, but you do increase
> the probability of a consistently good outcome.
But you have no idea how much you increase that probability. If you
can tell before purchasing something what benefits it will give you,
it is easier to make the decision to purchase it. I think that Lisp
implementations are particularly difficult to tell apart.
>> If your bottom line is at stake and you have no way of predicting whether a
>> substantial (in comparison to your overall budget in a startup
>> situation) amount of money spent on a Lisp implementation will have
>> any effect on your bottom line other than the purchase price and a tax
>> deduction, you will generally decide not to try it.
>
> Sure, a startup is a good bet to use free lisps. But once they are
> making Actual Money, I would expect the equation to shift away from the
> free solution to one that has backing from a dedicated service
> provider.
>
> Of course, most businesses might never get there. But lowering the
> barrier to entry will likely increase the probability that someone will
> try one and succeed, because more people will try.
>
> I can even see a case for bundling otherwise free software with a
> commercial lisp in some cases. Let's say, for the sake of argument,
> that I wanted to make a commercially supported version of Maxima (or
> make it Axiom, if GPL issues are going to be a hangup for anyone).
> Bundle it up in a box, sell it, and support it. Well Maxima is free
> and will remain free, but I have a choice about what lisp to put under
> it. If I'm looking at supporting a commercial CAS, one thing I would
> like NOT to have to worry about is bugs in the underlying lisp
> implementation. But the quality of my product relies on said lisp
> implementation functioning properly, so it would be my problem if it
> doesn't work. That might make a good case for using Allegro - I have
> to pay them some percentage, but I can presumably pass all complaints
> that have a root cause in the underlying lisp to them. Franz seems to
> have quite a good reputation, so it could very well make sense to do
> that. Certainly it would be worth discussing.
>
> Now, the second question would be whether there would be a market for
> Maxima in such a configuration (from an academic standpoint I would
> prefer the fully open one, myself) but that's a different discussion
> and this thread has already gone overlong.
Agreed. :)
C Y wrote:
>> It's pretty tough to argue against this point.
>
> It's logical enough, if potential commercial sales are in fact being
> lost. There are other possible endpoints to the free software game not
Yes, the point is valid, but quite irrelevant, IMO:
You could launch the very same argument against any other commercial
compiler that is a bit cheaper.
So it's not really a free software specific point. It's a point against
anyone who is cheaper than you (even if they have less features or less
quality software or whatever).
Nobody cares much about "commercial sales" as a whole. Everybody cares
about *his* commercial sales.
Thomas
Thomas H�hn <·····@usenet.arcornews.de> writes:
> C Y wrote:
>
>>> It's pretty tough to argue against this point.
>>
>> It's logical enough, if potential commercial sales are in fact being
>> lost. There are other possible endpoints to the free software game not
>
> Yes, the point is valid, but quite irrelevant, IMO:
>
> You could launch the very same argument against any other commercial
> compiler that is a bit cheaper.
>
> So it's not really a free software specific point. It's a point against
> anyone who is cheaper than you (even if they have less features or less
> quality software or whatever).
Your parenthetical seems to make the point invalid, actually. The
fact that products are different makes the fact that one costs less
than the other a mere part of the formula and not its entirety. You
don't go car-shopping with a mind toward simply acquiring an
automobile at the lowest possible price. You instead weigh all the
features and attributes of each car against its price until you find
the best value for your needs. It's simply impossible to make the
decision based on an assumption that the products are atomic (much
less fungible).
Compare:
1. { Car A: $100
{ Car B: $58,000
to:
2. { Heavily used, barely running, poor condition Ford Pinto: $100
{ Brand new, loaded Acura RL: $58,000
List #1 is the equivalent of the argument that SBCL being free
significantly hurts commercial Lisp vendors. List #2 shows why. The
existence of used Ford Pintos is not preventing a single new Acura
sale.
It may be the case that free Lisps are preventing some number of
commercial Lisp sales, but the price difference isn't the main reason
for that. Like I stated in another message on this thread, I see the
main problem being lack of a predictable benefit from using a
commercial Lisp over a free one. Because there is no predictable
benefit, most people look at the options and see only list #1.
On 2006-12-03 10:32:00 -0500, Ari Johnson <·········@gmail.com> said:
> Compare:
> 1. { Car A: $100
> { Car B: $58,000
> to:
> 2. { Heavily used, barely running, poor condition Ford Pinto: $100
> { Brand new, loaded Acura RL: $58,000
>
> List #1 is the equivalent of the argument that SBCL being free
> significantly hurts commercial Lisp vendors. List #2 shows why. The
> existence of used Ford Pintos is not preventing a single new Acura
> sale.
1. In order for your analogy to be meaningful these would have to be
the only two choices in the market. If there exist other versions in
between, then your argument fall apart, because the bottom could indeed
hurt sales of the next-to-bottom, which would hurt sales of the next up
the price ladder and so on right up to the fully loaded acura.
2. SBCL is in no way comparable to a heavily used barely running poor
condition Ford Pinto. With slime, sbcl is pretty close in functionality
to some commercial implementations.
3. Finally, most eveyone posting to this thread has once again failed
to distinguish between infrastruture software and end user software.
SBCL is much more analagous to a community taxing itself to provide a
public highway system (infrastructure) than to some firm giving away
free cars (end user).
Now leaping off the train before the wreck...
Raffael Cavallaro <················@pas-d'espam-s'il-vous-plait-mac.com> writes:
> On 2006-12-03 10:32:00 -0500, Ari Johnson <·········@gmail.com> said:
>
>> Compare:
>> 1. { Car A: $100
>> { Car B: $58,000
>> to:
>> 2. { Heavily used, barely running, poor condition Ford Pinto: $100
>> { Brand new, loaded Acura RL: $58,000
>> List #1 is the equivalent of the argument that SBCL being free
>> significantly hurts commercial Lisp vendors. List #2 shows why. The
>> existence of used Ford Pintos is not preventing a single new Acura
>> sale.
>
> 1. In order for your analogy to be meaningful these would have to be
> the only two choices in the market. If there exist other versions in
> between, then your argument fall apart, because the bottom could
> indeed hurt sales of the next-to-bottom, which would hurt sales of the
> next up the price ladder and so on right up to the fully loaded acura.
False. A person who is in the market for a Ford Pinto is not in the
market for a new Acura. Your distinction does not make a real
difference here. While it is true that competition within a segment
of the spectrum will affect sales of other products in that segment,
this does not cascade the way you imply it does. Consider the
following spectrum:
Ferrari }-----------------customer A
Porsche } }--------------customer B
Acura } }-----------customer C
Lincoln } }--------customer D
New Ford } }-----customer E
Used Volkswagen } }--customer F
Used Pinto }
Customer F choosing the Pinto over the Volkswagen will decrease sales
of Volkswagens by one (or maybe one-half, depending on how you define
the words 'decrease' and 'sales'). However, F's choice has no bearing
on the choices of A through E.
I don't believe that I over-simplified by giving only two choices in
the original analogy. Feel free to demonstrate how my belief is
mistaken if you feel that it is.
> 2. SBCL is in no way comparable to a heavily used barely running poor
> condition Ford Pinto. With slime, sbcl is pretty close in
> functionality to some commercial implementations.
SBCL is indeed comparable to such a Pinto. I will address the
SLIME-enhanced comparability of SBCL to a commercial implementation
shortly, but first I should clarify that my analogy was not intended
to be disparaging at all. Rather, the analogy was supposed to be that
SBCL is to a used Pinto as LispWorks is to a new Acura because
LispWorks and the Acura both have features that SBCL and the Pinto,
respectively, lack. While the Pinto lacks features such as safety and
reliability, I did not mean that SBCL lacks those particular features;
just that it does indeed lack features that LispWorks has.
I agree that, with SLIME, SBCL and my MacOS choice of OpenMCL are
comparable to commercial implementations as far as features of the
actual software. I personally cannot identify a feature of any
commercial Lisp, unavailable in a free one, that I would personally
pay several thousand dollars to have. And that's the core of my
point: from my eyes and those of many others, the choice appears to
very nearly approximate that between Car A and Car B rather than
between a Pinto and an Acura. This is evidence of one of two
problems: either commercial Lisps are poorly marketed in terms of
explaining the benefits of ownership to potential buyers or there
simply isn't enough of a difference between them for potential buyers
to care about the features they would prospectively pay thousands of
dollars for.
Then again, it could simply be that commercial Lisps cost too much for
hobbyists to justify regardless of the features they provide when the
free alternatives are good enough, and most of the people around here
are hobbyists, thus limiting the overall tone of the debate.
Regardless of the price or the issues surrounding it, though, it's
simply a matter of supply and demand: maximize the product of price
times the number of willing sales at that price. If the commercial
vendors are maximizing that function and the free Lisps are, as well,
then there's no argument to be had. If the argument is that the free
Lisps screw up the ability to maximize profit, then it could simply be
the case of too many vendors driving up supply where demand is
constant. But I really doubt that free Lisps are truly driving down
demand for Lisp in general.
> 3. Finally, most eveyone posting to this thread has once again failed
> to distinguish between infrastruture software and end user
> software. SBCL is much more analagous to a community taxing itself to
> provide a public highway system (infrastructure) than to some firm
> giving away free cars (end user).
That's true under an assumption that there is a correlation between
use of SBCL and contribution to it. I don't know whether that is the
case. However, that seems orthogonal to the original claim that free
Lisp implementations hurt everyone because they steal revenue from
commercial Lisp vendors and thus reduce the overall quality of Lisp
implementations.
On 2006-12-03 15:43:02 -0500, Ari Johnson <·········@gmail.com> said:
> Consider the
> following spectrum:
>
> Ferrari }-----------------customer A
> Porsche } }--------------customer B
> Acura } }-----------customer C
> Lincoln } }--------customer D
> New Ford } }-----customer E
> Used Volkswagen } }--customer F
> Used Pinto }
>
> Customer F choosing the Pinto over the Volkswagen will decrease sales
> of Volkswagens by one (or maybe one-half, depending on how you define
> the words 'decrease' and 'sales'). However, F's choice has no bearing
> on the choices of A through E.
Supply and demand - lost sales of Used Volkswagens lowers prices in
that market, making them more attractive to prospective buyers of New
Fords (E), so Ford lowers their prices and so on, up the chain. Driving
prices down at the low end has a cascading effect which lowers prices
at the high end too. When Porshe lowers their prices, Ferarri loses
sales to Porsche.
Raffael Cavallaro <················@pas-d'espam-s'il-vous-plait-mac.com> writes:
> On 2006-12-03 15:43:02 -0500, Ari Johnson <·········@gmail.com> said:
>
>> Consider the
>> following spectrum:
>> Ferrari }-----------------customer A
>> Porsche } }--------------customer B
>> Acura } }-----------customer C
>> Lincoln } }--------customer D
>> New Ford } }-----customer E
>> Used Volkswagen } }--customer F
>> Used Pinto }
>> Customer F choosing the Pinto over the Volkswagen will decrease
>> sales
>> of Volkswagens by one (or maybe one-half, depending on how you define
>> the words 'decrease' and 'sales'). However, F's choice has no bearing
>> on the choices of A through E.
>
> Supply and demand - lost sales of Used Volkswagens lowers prices in
> that market, making them more attractive to prospective buyers of New
> Fords (E), so Ford lowers their prices and so on, up the
> chain. Driving prices down at the low end has a cascading effect which
> lowers prices at the high end too. When Porshe lowers their prices,
> Ferarri loses sales to Porsche.
Assume that each of the items only has one distinctive feature above
the item below it and that each item includes all the distinctive
features of those below it. The only exceptions are that the Pinto
has no item below it and the Ferrari has nothing above it. Also
assume an entirely unrealistic but progressive-enough-to-work initial
price list.
Item Feature Price
----------------------------------------
Ferrari 200mph $700
Porsche 180mph $600
Acura Longevity $500
Lincoln Leather $400
New Ford Reliability $300
Used Volkswagen Safety $200
Used Pinto Transportation $100
Assume that the reason that each of the customers from before is only
willing to settle for one of two cars is because he demands the
feature of the lesser car and is willing to pay the price of the
greater car. Customer A will not buy a car that won't go at least
180mph and is willing to pay $700. Customer F will buy any car that
runs but will not pay over $200.
For F, the decision is between safety and price. If he chooses price,
Volkswagen prices may go down to capture others in the same position
as F. The problem is that Volkswagens are never going to go down
enough to capture F himself, who only wants transportation. As a
result, the only fluctuations in the price of a Volkswagen will be to
seek the most efficient price at which to sell the feature of safety.
The same applies to each vehicle up the chain. The prices will seek
the optimum level to profit from the added feature. That said, the
overall margins at the top end will admittedly decrease because they
no longer include a markup for each of the features offered by lesser
products but must rather sell each feature at its market value, but
selling each feature at market value is probably a good thing.
If you measure profit in gross terms that include both cash and
utility to the vendor less the cost and frustration of production,
then how is it bad for a particular vendor to decide that its feature
set is most profitable at a price of $0 cash plus whatever utility he
realizes from people using his product? If the answer is "because it
forces vendors of products with additional features to compete with
respect to the features available in the free product," then there is
no actual harm done, is there?
On 2006-12-04 01:34:03 -0500, Ari Johnson <·········@gmail.com> said:
> That said, the
> overall margins at the top end will admittedly decrease
1. So a free low end product does have a knock on effect on the money
the high end vendor makes, which is what I was saying - a free sbcl
means less money for Franz.
2. Your analysis assumes that customers have fairly fixed requirements.
"Free" is a price that leads to great buyer flexibility - many
purchasers who "require" a certain feature in a for-pay market will
rationalize that feature as "unnecessary" if it is unavailabe in a free
version. This depresses the whole price scale even more.
3. Again, this is independent of the question of whether there is a
certain infrastructure market (developer tools) in which programmers as
a group should be willing to forgo maximizing profit as part of a
community effort to make programmers themselves more productive.
Raffael Cavallaro <················@pas-d'espam-s'il-vous-plait-mac.com> writes:
> On 2006-12-04 01:34:03 -0500, Ari Johnson <·········@gmail.com> said:
>
>> That said, the
>> overall margins at the top end will admittedly decrease
>
> 1. So a free low end product does have a knock on effect on the money
> the high end vendor makes, which is what I was saying - a free sbcl
> means less money for Franz.
That's not what I said. A free product that has a given feature will
force other products with that feature to be competitive in terms of
what is charged for that feature. Why does Franz charging $1,000
above the market price for a particular feature give you warm fuzzies?
> 2. Your analysis assumes that customers have fairly fixed
> requirements. "Free" is a price that leads to great buyer flexibility
> - many purchasers who "require" a certain feature in a for-pay market
> will rationalize that feature as "unnecessary" if it is unavailabe in
> a free version. This depresses the whole price scale even more.
Customers do have fixed requirements. Any feature that they really
require, they will pay for. It is their choice as to whether to pay
for it with money or with time - the two are essentially fungible. If
they can go without the feature altogether, then it was not a true
requirement and they overstated their requirements, and as a result of
the competition the customer can now meet its actual requirements and
do so more efficiently.
By the way, efficient markets don't depress price scales, they
optimize them. If your argument is that market competition pushes
prices downward, then the problem is that the prices were previously
inflated beyond optimum. If your argument is instead that free
software causes otherwise efficient markets to become inefficient,
then your conclusion is correct but you still need to prove that this
is the case.
> 3. Again, this is independent of the question of whether there is a
> certain infrastructure market (developer tools) in which programmers
> as a group should be willing to forgo maximizing profit as part of a
> community effort to make programmers themselves more productive.
It is, indeed, mostly independent of that question. However, that
question is one that ought to be answered by the individual
programmers choosing to work toward such a goal. And, of course,
working toward that goal and the fuzzy feeling it brings people is the
profit derived from free software, whose subjective value is the same
or greater than that of the cash income they could otherwise make with
the same use of time. In that sense, it's a related question but,
like most "should" questions, it is not answerable in any way that
would be meaningful to anyone but the person answering it.
On 2006-12-04 11:28:08 -0500, Ari Johnson <·········@gmail.com> said:
>>> That said, the
>>> overall margins at the top end will admittedly decrease
>>
>> 1. So a free low end product does have a knock on effect on the money
>> the high end vendor makes, which is what I was saying - a free sbcl
>> means less money for Franz.
>
> That's not what I said. A free product that has a given feature will
> force other products with that feature to be competitive in terms of
> what is charged for that feature. Why does Franz charging $1,000
> above the market price for a particular feature give you warm fuzzies?
I am not a Franz customer, and their pricing hardly gives me the warm
fuzzies. The warm fuzzies here are the subjective value that free
programmers receive for their work which is not otherwise compensated
with the consensus value of the rest of the market - money. In a market
customers receive value (goods and/or services) for consensus value
(money). With a free offering, customers recieve value for no money.
You cannot put value into a market (free lisp compilers) without
consequence - it must impact other exchanges in that market (drive down
prices and/or reduce the number of sales for commercial lisp vendors).
> Customers do have fixed requirements.
On this we irreconcilably disagree. My experience of the world has
shown me quite the contrary - that customer "requirements" are very
flexible, and the introduction of a no cost option into the purchasing
decision distorts what the customer perceives as "requirements" very
quickly and quite dramatically.
I strongly suspect that this is the root of our disagreement and I
honestly can't see any way around it which suggests that there would be
little to gain for either of us in continuing this particular
discussion.
> It is, indeed, mostly independent of that question. However, that
> question is one that ought to be answered by the individual
> programmers choosing to work toward such a goal. And, of course,
> working toward that goal and the fuzzy feeling it brings people is the
> profit derived from free software, whose subjective value is the same
> or greater than that of the cash income they could otherwise make with
> the same use of time. In that sense, it's a related question but,
> like most "should" questions, it is not answerable in any way that
> would be meaningful to anyone but the person answering it.
On this I think we are both in agreement - this is a personal valuation
- in my case I think it is worthwhile to benefit many lisp programmers
with excellent free and open source compilers like sbcl, cmucl, clisp,
openmcl, etc., while harming the bottom line of a few lisp programmers
who work for commercial lisp compiler vendors and possibly disrupting
the business of some of their customers (should competition from free
lisps put one or more commercial vendors out of business). Others of
course will have very different values.
Raffael Cavallaro <················@pas-d'espam-s'il-vous-plait-mac.com> writes:
> On 2006-12-04 11:28:08 -0500, Ari Johnson <·········@gmail.com> said:
>> Customers do have fixed requirements.
>
> On this we irreconcilably disagree. My experience of the world has
> shown me quite the contrary - that customer "requirements" are very
> flexible, and the introduction of a no cost option into the purchasing
> decision distorts what the customer perceives as "requirements" very
> quickly and quite dramatically.
>
> I strongly suspect that this is the root of our disagreement and I
> honestly can't see any way around it which suggests that there would
> be little to gain for either of us in continuing this particular
> discussion.
That may be the case. However, it appears to stem from our differing
definitions of "customer requirements." It seems to me that you are
talking about what customers *say* their requirements are. I intended
to mean only what their *actual* requirements are. A free offering
makes it easier to distill the stated requirements down to the actual
requirements, because you are willing to give up those things that you
previously said were requirements but in fact are not.
For instance, many people say that one of their requirements is the
ability to produce standalone executables. This is rarely a true
requirements, but rather a stated one. It may be a perceived
requirement, but it still is not a real one. The minute that the
customer realizes that it would cost thousands of dollars to get a
Lisp implementation capable of producing what he is willing to concede
is indeed a standalone executable, he drops the requirement. This
means it was not an actual requirement.
An actual requirement is one that cannot be dropped. An example of
this could be a GUI toolkit to use for an end-user application.
Implementation A costs $1000 and has one, Implementation B is free and
doesn't. If the customer chooses Implementation B, he will have to
implement (or, equivalently, synthesize from existing pieces) his own
GUI toolkit. His other choice is to produce a non-GUI product, which
is not a viable alternative. So now he is forced to decide between
paying $1000 and making his own GUI toolkit.
If we still disagree on whether it is all requirements or only some of
them that are flexible, then I agree that there's no need for further
discussion.
On 2006-12-04 18:14:38 -0500, Ari Johnson <·········@gmail.com> said:
> An actual requirement is one that cannot be dropped. An example of
> this could be a GUI toolkit to use for an end-user application.
> Implementation A costs $1000 and has one, Implementation B is free and
> doesn't. If the customer chooses Implementation B, he will have to
> implement (or, equivalently, synthesize from existing pieces) his own
> GUI toolkit. His other choice is to produce a non-GUI product, which
> is not a viable alternative. So now he is forced to decide between
> paying $1000 and making his own GUI toolkit.
Or the customer will decide he can use a non GUI lisp which talks over
a socket to a GUI written in another free language that has a GUI
toolkit. IOW, this "actual requirement" like many others dissolves when
faced with the possibility of acquiring a totally free solution.
Are threads a requirement but your free implementation doesn't have
'em? - spawn another lisp process and have 'em talk to eachother, etc.,
etc. The result is that even though free lisps don't have features that
many might otherwise pay for, they will be irresistable to many simply
because they are free. The missing features will be rationalized away
as not truly "required" but it is the availablity of a free alternative
that has changed the project "requirements" not the nature of the
project itself.
I think we really do disagree because you see customers as rational
agents who assess the "actual requirements" of their projects and I see
them as emotional human beings who will rationalize most anything if it
gets them stuff for free.
Raffael Cavallaro <················@pas-d'espam-s'il-vous-plait-mac.com> writes:
> On 2006-12-04 18:14:38 -0500, Ari Johnson <·········@gmail.com> said:
>
>> An actual requirement is one that cannot be dropped. An example of
>> this could be a GUI toolkit to use for an end-user application.
>> Implementation A costs $1000 and has one, Implementation B is free and
>> doesn't. If the customer chooses Implementation B, he will have to
>> implement (or, equivalently, synthesize from existing pieces) his own
>> GUI toolkit. His other choice is to produce a non-GUI product, which
>> is not a viable alternative. So now he is forced to decide between
>> paying $1000 and making his own GUI toolkit.
>
> Or the customer will decide he can use a non GUI lisp which talks over
> a socket to a GUI written in another free language that has a GUI
> toolkit. IOW, this "actual requirement" like many others dissolves
> when faced with the possibility of acquiring a totally free solution.
That's the same as making your own GUI toolkit. It's also not a
totally free solution, because there is labor involved in turning a
non-GUI Lisp over here plus a GUI toolkit written on another free
language over there into a GUI application.
> Are threads a requirement but your free implementation doesn't have
> em? - spawn another lisp process and have 'em talk to eachother, etc.,
> etc. The result is that even though free lisps don't have features
> that many might otherwise pay for, they will be irresistable to many
> simply because they are free. The missing features will be
> rationalized away as not truly "required" but it is the availablity of
> a free alternative that has changed the project "requirements" not the
> nature of the project itself.
You are still replacing the requirement with something that
accomplishes it. It's still a requirement.
> I think we really do disagree because you see customers as rational
> agents who assess the "actual requirements" of their projects and I
> see them as emotional human beings who will rationalize most anything
> if it gets them stuff for free.
Quite to the contrary. I see them the same way as you see them, but I
argue that there are actual requirements underlying each project.
Whether the customer actually knows what those actual requirements are
or how they relate to his stated requirements is debatable and
unlikely, but that doesn't change that there are actual requirements.
You can, of course, distill every requirement down to the point that
there are no requirements at all, but that is a purely theoretical
exercise that ignores any reality of the situation. For instance, the
requirement of "a computer" can be rationalized away by building your
own computer out of old tube radios you have lying around, but the
requirement of a computer is still there no matter whether you meet it
by buying a computer or building your own garage ENIAC.
The same applies to GUI toolkits, threading, database access, etc.
There *are* actual requirements of any given application. How you
break them apart might vary, but only within reasonable boundaries.
("I need a completed product." is too extreme on one end of the
spectrum and "I don't need a computer." is too extreme on the other
end.) How you meet the requirements is also up to you, and your
choice is usually between buying them and implementing them yourself.
But no, I never once intended to say that customers know their
requirements well enough to specify them out loud. Maybe that's where
we're having trouble resolving our differences.
Ari Johnson wrote:
> Thomas H�hn <·····@usenet.arcornews.de> writes:
>
>> C Y wrote:
>>
>>>> It's pretty tough to argue against this point.
>>>
>>> It's logical enough, if potential commercial sales are in fact being
>>> lost. There are other possible endpoints to the free software game not
>>
>> Yes, the point is valid, but quite irrelevant, IMO:
>>
>> You could launch the very same argument against any other commercial
>> compiler that is a bit cheaper.
>>
>> So it's not really a free software specific point. It's a point against
>> anyone who is cheaper than you (even if they have less features or less
>> quality software or whatever).
>
> Your parenthetical seems to make the point invalid, actually. The
> fact that products are different makes the fact that one costs less
> than the other a mere part of the formula and not its entirety. You
> don't go car-shopping with a mind toward simply acquiring an
> automobile at the lowest possible price. You instead weigh all the
> features and attributes of each car against its price until you find
> the best value for your needs. It's simply impossible to make the
> decision based on an assumption that the products are atomic (much
> less fungible).
That's true and I thought about leaving the parantheses out, but this
was part of the "free software is bad, even if it has less features,
because for some people the features are enough" argument, if I remember
correctly.
> It may be the case that free Lisps are preventing some number of
> commercial Lisp sales, but the price difference isn't the main reason
> for that. Like I stated in another message on this thread, I see the
> main problem being lack of a predictable benefit from using a
> commercial Lisp over a free one. Because there is no predictable
> benefit, most people look at the options and see only list #1.
Good point.
But maybe it can be modified such that not only a predictable benefit is
invisible (that is also the case with, say, C++ compilers), but that also
no "believed" benefit is visible (like "everyone uses MS Visual C++, so I
must have it, too" or "every magazine wrote about the new MSVC++ release,
buying that is the reasonable and safe route"). In the Lisp world there is
probably much less exposition to "peer pressure" or "being mainstream",
mainly because using Lisp is very non-mainstream and your peers might not
even know about it. :-)
Thomas
On Thu, 30 Nov 2006 12:57:35 -0500, Ken Tilton <·········@gmail.com> tried to
confuse everyone with this message:
>
>
>········@gmail.com wrote:
>> Lars Rune N�stdal wrote:
>>
>>>SBCL has just turned 1.0!
>>
>Sad day, and sadder still when it does run on win32.
It does actually, just installed it!
:(
Although it behaves quite funny when run in a certain way:
D:\SBCL\1.0>D:\SBCL\1.0\sbcl.exe
This is SBCL 1.0, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
fatal error encountered in SBCL pid 3596:
can't load .core for different runtime, sorry
LDB monitor
ldb> exit
Argh! lossage_handler() returned, total confusion..
That last message is classic.
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
I've tried the win32 version today. I got stuck trying to use asdf and
asdf-install. I get an error which I've pasted below. I notice also
that :unix appears in the *features* which is odd.
; loading system definition from C:\sbcl1\asdf-install\asdf-install.asd
into
; #<PACKAGE "ASDF0">
; registering #<SYSTEM ASDF-INSTALL {AF039E1}> as ASDF-INSTALL
debugger invoked on a ASDF:MISSING-DEPENDENCY:
component ASDF-INSTALL-SYSTEM::SB-BSD-SOCKETS not found, required by
#<SYSTEM "asdf-install" {AF039E1}>
On 30 Nov 2006 13:23:33 -0800, "justinhj" <········@gmail.com> tried to confuse
everyone with this message:
>I've tried the win32 version today. I got stuck trying to use asdf and
>asdf-install. I get an error which I've pasted below. I notice also
>that :unix appears in the *features* which is odd.
>
>; loading system definition from C:\sbcl1\asdf-install\asdf-install.asd
>into
>; #<PACKAGE "ASDF0">
>; registering #<SYSTEM ASDF-INSTALL {AF039E1}> as ASDF-INSTALL
>
>debugger invoked on a ASDF:MISSING-DEPENDENCY:
> component ASDF-INSTALL-SYSTEM::SB-BSD-SOCKETS not found, required by
> #<SYSTEM "asdf-install" {AF039E1}>
>
(require :asdf-install) seems to load it without errors. However making
asdf-install work under Windows requires some hacking. It downloads packages
just fine, but then fails to unpack them, or something. I think it's easier to
grab asdf-extensions.lisp from Lispbox and use it to install stuff.
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
Timofei Shatrov wrote:
> On 30 Nov 2006 13:23:33 -0800, "justinhj" <········@gmail.com> tried to confuse
> everyone with this message:
> (require :asdf-install) seems to load it without errors. However making
> asdf-install work under Windows requires some hacking. It downloads packages
> just fine, but then fails to unpack them, or something. I think it's easier to
> grab asdf-extensions.lisp from Lispbox and use it to install stuff.
>
Ah that works thanks. I don't really care if asdf-install can download
and install stuff, just as long as I can compile and run it by pointing
it at the directories the .asd's are in. Which I can't seem to get
working as yet.
Justin
Ken Tilton <·········@gmail.com> writes:
> Sad day, and sadder still when it does run on win32.
Are you made out of wet blankets and bile?
--
This post uses 100% post consumer electrons and 100% virgin photons.
At 2.6 miles per minute, you don't really have time to get bored.
--- Pete Roehling on rec.motorcycles
I bump into a lot of veteran riders in my travels.
--- David Hough: Proficient Motorcycling
David Steuber wrote:
> Ken Tilton <·········@gmail.com> writes:
>
>
>>Sad day, and sadder still when it does run on win32.
>
>
> Are you made out of wet blankets and bile?
>
Apparently not:
http://www.tilton-technology.com/rogercormannyc3.html
Are you made of adhominium?
I made a remark about how the community choses to allocate scarce
resources. It is pretty abstract cuz of course we are all free to do as
we please, and of course there is no community. In fact, I was just
counterbalancing a rather bizarre dancing-in-the-streets phenomenon over
I-am-not-sure-what accomplishment with an admittedly dubious point:
exactly what drives the development of CMUCL/SBCL when we have not-all
that-expensive pro licenses for LW and ACL, as well as utterly free
CLisp with aewsome FFI, MOP, and more?
Is it the "I am looking for a free XXX" disease RMS unleashed on the
software industry?
Oh, sorry, I am back on topic, you wanted to roll around kicking and
a-gouging in the mud and the blood and the beer. Nah, you gotta come to
LispNYC meetings and get to me before the bouncers do.
:)
kzo
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Hello, Ken
Ken Tilton wrote:
> I made a remark about how the community choses to allocate scarce
> resources. It is pretty abstract cuz of course we are all free to do as
> we please, and of course there is no community. In fact, I was just
> counterbalancing a rather bizarre dancing-in-the-streets phenomenon over
> I-am-not-sure-what accomplishment with an admittedly dubious point:
> exactly what drives the development of CMUCL/SBCL when we have not-all
> that-expensive pro licenses for LW and ACL, as well as utterly free
> CLisp with aewsome FFI, MOP, and more?
Utterly-free clisp doesn't support threads - which seriously hampers
web-development in my view. (Of course you may lunch new process for
every user, as PG apparently did, but I'm not sure how scalable /
efficient is that).
Pro licenses for LW / ACL are not-all-that-expensive indeed, at least
for folks who have government / university / company / sponsor money,
or want to start any serious software business.
I'm considering starting a company myself, and sales reps from both LW
and Franz were really friendly. The only thing that puzzles me is that
Franz requires *roaylties* for running binaries compiled with Allegro
CL (LW doesn't have that). When I explained the setting where I'm
going to use ACL - compiling binary on my development machine and
putting it on my web-server(s), he replied that Franz would want
*percentage* of my revenues as a roalties, or at least that was the way
I understood him. Which other (commercial) compiler manufacturer
requires such thing from his users?
On the other hand, Franz is really flexible supporting start-ups - I
asked for deferred payments, and they was ready to agree on almost any
reasonable scheme; LW wasn't that loyal. But pro license for LW is 4
times cheaper than ACL.
Overall, if I could combine Franz flexible approach to startups with
lower-cost and roalty-free LW pro license, I would negotiate the deal.
But right now, I have to use SBCL on linux-x86.
Regards,
Victor.
"Victor Kryukov" <··············@gmail.com> writes:
> Utterly-free clisp doesn't support threads - which seriously hampers
> web-development in my view. (Of course you may lunch new process for
> every user, as PG apparently did, but I'm not sure how scalable /
> efficient is that).
You could prefork some processes ahead of time to avoid the overhead
of making new processes. But I agree that threads would be much
nicer.
> I'm considering starting a company myself, and sales reps from both LW
> and Franz were really friendly. The only thing that puzzles me is that
> Franz requires *roaylties* for running binaries compiled with Allegro
> CL (LW doesn't have that). When I explained the setting where I'm
> going to use ACL - compiling binary on my development machine and
> putting it on my web-server(s), he replied that Franz would want
> *percentage* of my revenues as a roalties, or at least that was the way
> I understood him. Which other (commercial) compiler manufacturer
> requires such thing from his users?
I understood it the same way. Franz wouldn't explain why I should
give up a percentage of my revenue, so I looked into and bought
LispWorks, which I actually like better than Allegro.
> On the other hand, Franz is really flexible supporting start-ups - I
> asked for deferred payments, and they was ready to agree on almost any
> reasonable scheme; LW wasn't that loyal. But pro license for LW is 4
> times cheaper than ACL.
Since this is for a business, you might consider financing a LispWorks
license with a loan or even a credit card - that's how I paid for
mine. Even if Franz defers payments, you're going to have to pay
royalties for the rest of your business's life; paying down the cost
of a LispWorks license doesn't even come close to that.
Hello Bill,
Bill Atkins <······@rpi.edu> writes:
> "Victor Kryukov" <··············@gmail.com> writes:
>
>> On the other hand, Franz is really flexible supporting start-ups - I
>> asked for deferred payments, and they was ready to agree on almost any
>> reasonable scheme; LW wasn't that loyal. But pro license for LW is 4
>> times cheaper than ACL.
>
> Since this is for a business, you might consider financing a LispWorks
> license with a loan or even a credit card - that's how I paid for
> mine. Even if Franz defers payments, you're going to have to pay
> royalties for the rest of your business's life; paying down the cost
> of a LispWorks license doesn't even come close to that.
That's true. If a person is serious enough to start a business (and
lucky enough to live in developed world :), $1.5K is not a problem -
credit card, loan, friends & family, sell your fancy bike etc.
The main reason I'm not selling my fancy bike is that I don't see any
_serious_ advantage of LW over SBCL _on Linux platform_. Franz has
something: they have AllegroCashe, and they wrote AllegroServe which
means that if I would ever find a critical bug in it, they would
probably fix it per my request.
LW has nice development environment, I agree, but I doubt it has
significant marginal value over Emacs + SLIME. It also support threads
on Intel Mac, which SBCL currently doesn't, and it's nice as I own
Macbook and like the environment, but LW cannot cross-compile, so I
would need additional license to compile binaries for my servers.
Because of all that, I just ended up buying Linux development machine.
However, I'm open to changing my view. Do you have any argumentation
for choosing LW over SBCL in the commercial environment*?
Regards,
Victor.
[*] A classmate of mine currently works for ITA Software. He said they
mainly use SBCL for their development (at least in his department),
though they have some ACL licenses as well. The reasons for choosing
SBCL over ACL were not financial, he said.
Victor Kryukov <···················@gmail.com> writes:
> LW has nice development environment, I agree, but I doubt it has
> significant marginal value over Emacs + SLIME. It also support threads
> on Intel Mac, which SBCL currently doesn't, and it's nice as I own
> Macbook and like the environment, but LW cannot cross-compile, so I
> would need additional license to compile binaries for my servers.
> Because of all that, I just ended up buying Linux development machine.
You should have considered Parallels. I've just started using that on
my MacBook Pro and my virtual debian server on my laptop now runs our
simple benchmark program (a binary generated with LispWorks for linux)
faster than several of our Opteron servers :-) Installing Debian sarge
was a piece of cake, except for X (so far), but I doubt that I really
need that - I just ssh into the virtual machine from the "real"
MacBook and run X applications via X tunneling. Works flawlessly. So
now I can do triple-OS lisp development on one machine :-)
Regarding LispWorks vs. SBCL: I guess YMMV. We're very satisfied with
the support we get and the pace of development at LispWorks - we just
put a lisp server based on their 64 bit linux version into production
and are very pleased with the performance. I haven't seriously tried
SBCL for a while, so I can't give a good assessment of the differences,
but I imagine that the Oracle support of LispWorks would be a selling
point? (Also, I do cross platform GUI stuff, so of course CAPI is a
good selling point)
--
(espen)
On Fri, 01 Dec 2006 06:12:28 +0100, Bill Atkins <······@rpi.edu> wrote:
>
> Since this is for a business, you might consider financing a LispWorks
> license with a loan or even a credit card - that's how I paid for
> mine. Even if Franz defers payments, you're going to have to pay
> royalties for the rest of your business's life; paying down the cost
> of a LispWorks license doesn't even come close to that.
One of the rules of company developement is to keep the costs of initial
developement
to a minimum. Only people that don't need money get easy loans. So this is
a major show
stopper. If you spend 20 000$ on software before developing anything
(which is easy)
you are going for a big fall if you fail.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
"John Thingstad" <··············@chello.no> writes:
> One of the rules of company developement is to keep the costs of
> initial developement
> to a minimum.
Yes, to an extent. But if spending a little more money up front will
get you a working product faster than your competition, spending a
little extra is well worth it.
> Only people that don't need money get easy loans. So
> this is a major show
> stopper. If you spend 20 000$ on software before developing anything
> (which is easy)
> you are going for a big fall if you fail.
I think there's a pretty serious difference between your $20000 and
the $1300 that we're discussing. $1300 is enough to squeeze under the
credit limit of most credit cards, if you can't get a loan.
It's very common to take out large loans when going into business. A
retail store needs to finance its building and its initial inventory.
Building a factory requires huge amounts of capital. Only a rare few
can finance a business's startup entirely out of their savings.
Victor Kryukov wrote:
> Hello, Ken
>
> Ken Tilton wrote:
>
>
>>I made a remark about how the community choses to allocate scarce
>>resources. It is pretty abstract cuz of course we are all free to do as
>>we please, and of course there is no community. In fact, I was just
>>counterbalancing a rather bizarre dancing-in-the-streets phenomenon over
>>I-am-not-sure-what accomplishment with an admittedly dubious point:
>>exactly what drives the development of CMUCL/SBCL when we have not-all
>>that-expensive pro licenses for LW and ACL, as well as utterly free
>>CLisp with aewsome FFI, MOP, and more?
>
>
> Utterly-free clisp doesn't support threads - which seriously hampers
> web-development in my view.
I smell the same bogus argument that misled someone into abandoning Lisp
to achieve the continuations "necessary" for web apps.
> (Of course you may lunch new process for
> every user, as PG apparently did, but I'm not sure how scalable /
> efficient is that).
>
> Pro licenses for LW / ACL are not-all-that-expensive indeed, at least
> for folks who have government / university / company / sponsor money,
> or want to start any serious software business.
>
> I'm considering starting a company myself, and sales reps from both LW
> and Franz were really friendly. The only thing that puzzles me is that
> Franz requires *roaylties* for running binaries compiled with Allegro
> CL (LW doesn't have that).
Well, that is how they make money, not sure why that is puzzling.
Undesirable, sure, but if you use all their tools and tech support it at
least had to come close to justifying the royalty, and likely more than
pays for it.
> When I explained the setting where I'm
> going to use ACL - compiling binary on my development machine and
> putting it on my web-server(s), he replied that Franz would want
> *percentage* of my revenues as a roalties, or at least that was the way
> I understood him. Which other (commercial) compiler manufacturer
> requires such thing from his users?
SleepycatDB? (royalty I mean, not compiler)
>
> On the other hand, Franz is really flexible supporting start-ups - I
> asked for deferred payments, and they was ready to agree on almost any
> reasonable scheme; LW wasn't that loyal.
Sorry, are you saying LW demanded their zero percent up front? :)
My problem with Franz was that if I /succeeded/ the chunk they wanted
was enough for me to hire a dozen yobbos to do KTCL from frickin
scratch. No wonder they seem friendly. Ask them a couple of intelligent
questions and see what they do.
> But pro license for LW is 4
> times cheaper than ACL.
>
> Overall, if I could combine Franz flexible approach to startups...
ok, you definitely did not ask the intelligent questions. :) of course,
if you plan on /failing/... :)
> with
> lower-cost and roalty-free LW pro license, I would negotiate the deal.
> But right now, I have to use SBCL on linux-x86.
You cannot afford LW Pro? And you are doing a Lisp start-up? You know,
that is fine, but i think you exist in a (lunatic?) fringe window of
commercial opportunity any vendor can safely lose. This is not a slam on
you, I just mean no one would ever be able to build a business on
customers like you, so they might as well lose you and bet the ranch on
a different pricing model.
I mean, you want LW to both give away runtimes and not charge for their
software, because you have this cash problem. yeah! Let /them/ have the
cash problem! that way they go out of busi... hang on.
You free-free-free people simply never imagine the vendor's postion in a
world where Lisp is still a niche market. This language is a commercial,
competitive, productivity grand slam and two vendors are providing
extraordinary implementations and add-ons and you are bleating about the
cost?!
You know what? No, you actually do not appreciate Lisp. No one who sees
the competitive advantage of Lisp and knows how to add makes such judgments.
kt
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
>>>>> "KT" == Ken Tilton <·········@gmail.com> writes:
KT> You free-free-free people simply never imagine the vendor's
KT> postion in a world where Lisp is still a niche market. This
KT> language is a commercial, competitive, productivity grand slam
KT> and two vendors are providing extraordinary implementations
KT> and add-ons and you are bleating about the cost?!
And yet, when Franz wanted to charge you royalties, you went to a
cheaper vendor.
Can't you imagine Franz's position? The language is a productivity
grand slam and they are offering you an extraordinary implementation
and add-ons, and you had the GALL to choose a different vendor based
on COST.
Pot, kettle, black.
Charlton
--
Charlton Wilbur
·······@chromatico.net
Charlton Wilbur wrote:
>>>>>>"KT" == Ken Tilton <·········@gmail.com> writes:
>
>
> KT> You free-free-free people simply never imagine the vendor's
> KT> postion in a world where Lisp is still a niche market. This
> KT> language is a commercial, competitive, productivity grand slam
> KT> and two vendors are providing extraordinary implementations
> KT> and add-ons and you are bleating about the cost?!
>
> And yet, when Franz wanted to charge you royalties,
No, "when we could not come to terms", and I do plan to try again
because of the added value they offer.
By the way, in giving examples of royalties I meant to mention the
on-line store people (and, shucks, why not the CC companies themselves?)
who all will have their hands in my pocket for 2-3%.
As I looked at all the hands in my pocket I decided, wtf, zero-percent
runtime royalty is not necessary. Of all the entities dipping in, Franz
is the one contributing most to my success if I start using AllegroCache
and any other proprietary goodies they offer. Also their support is
free. Granted, I am the one usually supporting them by reporting bugs in
the IDE (never a show-stopper), but come on, /someday/ even the Great
Kenny will have a problem he cannot fix, right?
>... you went to a
> cheaper vendor.
But not a free one, and I did not go home and write a lisp.
Besides, your mental image is wrong. If things do not work out, one
could also argue that Franz chased me out of their shop by not budging
in negotiations. I thought I made a good case, they told me where to get
off. I have argued in this forum before that they probably know what
they are doing since they are making money with a dead language, so
there ain't no good guys, there ain't no bad guys, we just disagree. Who
was it who said, "It's just business?"
>
> Can't you imagine Franz's position? The language is a productivity
> grand slam and they are offering you an extraordinary implementation
> and add-ons, and you had the GALL to choose a different vendor based
> on COST.
You are shouting because your argument is not really working, is it?
SBCL developers are not looking at cost. If they were, they would buy a
license for the tax-deductible cost of twelve hours work. I think we
have been over this a few times.
>
> Pot, kettle, black.
>
Left as an exercise: sweeping up the debris of your shattered argument.
:)
kt
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
>>>>> "KT" == Ken Tilton <·········@gmail.com> writes:
KT> By the way, in giving examples of royalties I meant to mention
KT> the on-line store people (and, shucks, why not the CC
KT> companies themselves?) who all will have their hands in my
KT> pocket for 2-3%.
KT> As I looked at all the hands in my pocket I decided, wtf,
KT> zero-percent runtime royalty is not necessary. Of all the
KT> entities dipping in, Franz is the one contributing most to my
KT> success if I start using AllegroCache and any other
KT> proprietary goodies they offer.
Right. What's the *qualitative* difference between that and someone
looking at all the hands in his pocket and deciding wtf, license fees
for software are not necessary when there's a free alternative that
gives an acceptable boost to productivity?
>> ... you went to a cheaper vendor.
KT> But not a free one, and I did not go home and write a lisp.
Free is just the asymptotic limit of cheaper.
And in your position, given what your goals are, writing a Lisp
yourself from scratch would have been very cost-ineffective.
Contributing a feature to a free Lisp, on the other hand....
>> Can't you imagine Franz's position? The language is a
>> productivity grand slam and they are offering you an
>> extraordinary implementation and add-ons, and you had the GALL
>> to choose a different vendor based on COST.
KT> You are shouting because your argument is not really working,
KT> is it?
No, I'm shouting because I'm mocking you. That was nearly a
word-for-word copy of what you said in your post, and it works about
as well when I say it in mockery as it does when you say it with a
straight face. That was the point.
KT> SBCL developers are not looking at cost. If they were, they
KT> would buy a license for the tax-deductible cost of twelve
KT> hours work. I think we have been over this a few times.
I expect the SBCL developers know damn well how much licenses cost.
They're not doing it because it's cheaper; they're doing it because
they believe the reward (a non-proprietary Lisp implementation, not
tied to the whims of any one vendor) is worth the effort.
If the commercial Lisp vendors can't offer more value than a free Lisp
assembled by a team of enthusiasts in their spare time, they deserve
to go out of business. Shouting at the volunteers doesn't change this.
Charlton
--
Charlton Wilbur
·······@chromatico.net
Charlton Wilbur wrote:
>>>>>>"KT" == Ken Tilton <·········@gmail.com> writes:
>
>
> KT> By the way, in giving examples of royalties I meant to mention
> KT> the on-line store people (and, shucks, why not the CC
> KT> companies themselves?) who all will have their hands in my
> KT> pocket for 2-3%.
>
> KT> As I looked at all the hands in my pocket I decided, wtf,
> KT> zero-percent runtime royalty is not necessary. Of all the
> KT> entities dipping in, Franz is the one contributing most to my
> KT> success if I start using AllegroCache and any other
> KT> proprietary goodies they offer.
>
> Right. What's the *qualitative* difference between that and someone
> looking at all the hands in his pocket and deciding wtf, license fees
> for software are not necessary when there's a free alternative that
> gives an acceptable boost to productivity?
>
> >> ... you went to a cheaper vendor.
>
> KT> But not a free one, and I did not go home and write a lisp.
>
> Free is just the asymptotic limit of cheaper.
>
> And in your position, given what your goals are, writing a Lisp
> yourself from scratch would have been very cost-ineffective.
> Contributing a feature to a free Lisp, on the other hand....
>
> >> Can't you imagine Franz's position? The language is a
> >> productivity grand slam and they are offering you an
> >> extraordinary implementation and add-ons, and you had the GALL
> >> to choose a different vendor based on COST.
>
> KT> You are shouting because your argument is not really working,
> KT> is it?
>
> No, I'm shouting because I'm mocking you. That was nearly a
> word-for-word copy
Those, btw, are always sooooo clever on Usenet.
> ...of what you said in your post, and it works about
> as well when I say it in mockery as it does when you say it with a
> straight face. That was the point.
No, the point is that your attempt at a reversal was fundamentally an
analogy, and those are a waste of time when it comes to discussions
because one then has to argue over the accuracy of the analogy. That is
like a bottomless slippery slope.
You might as well give up on your attempted rhetorical stunt and just
talk about the issues. Then you might have come up with a telling point,
such as "was it worth it for Kenzo to spend all that time on Cello just
to avoid getting locked into Franz's..." but then I am not sure how to
finish that because Franz does not have a GUI for OSX (and Cells-Gtk did
not exist when i did Cello).
You'd lose anyway because I already wonder if I made that mistake (and I
am considering it a mistake if I can fill in that blank with something
-- CAPI is a candidate, but then that still means dumping Franz).
I am trying to save your argument, but getting nowhere. Maybe if I start
pitching in on Rucksack instead of using AllegroCache? Esp. since
Rucksack seems not to be ready for prime time. Yeah, that would do it.
I'll let you know if I do that, then you can bring out your cookware
<sigh> analogy.
:)
hth, kzo
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
>>>>> "KT" == Ken Tilton <·········@gmail.com> writes:
>> ...of what you said in your post, and it works about as well
>> when I say it in mockery as it does when you say it with a
>> straight face. That was the point.
KT> No, the point is that your attempt at a reversal was
KT> fundamentally an analogy, and those are a waste of time when
KT> it comes to discussions because one then has to argue over the
KT> accuracy of the analogy. That is like a bottomless slippery
KT> slope.
Except that it's not a reversal, nor is it an analogy.
You chose one vendor over another because they both had the feature
set you were looking for, and one was cheaper than the other even
after taking into account the necessity of working around any missing
features in the cheaper implementation.
Why is it acceptable to do that if "cheaper" still involves money, but
not if "cheaper" is free?
Would SBCL be acceptable if they charged $1 for a license? $10? $100?
That's the issue that you're avoiding with all this smoke and mirrors
about analogies, and that I pointed out by restating your words to you.
Charlton
--
Charlton Wilbur
·······@chromatico.net
Charlton Wilbur wrote:
>>>>>>"KT" == Ken Tilton <·········@gmail.com> writes:
>
>
> >> ...of what you said in your post, and it works about as well
> >> when I say it in mockery as it does when you say it with a
> >> straight face. That was the point.
>
> KT> No, the point is that your attempt at a reversal was
> KT> fundamentally an analogy, and those are a waste of time when
> KT> it comes to discussions because one then has to argue over the
> KT> accuracy of the analogy. That is like a bottomless slippery
> KT> slope.
>
> Except that it's not a reversal, nor is it an analogy.
>
> You chose one vendor over another because they both had the feature
> set you were looking for, and one was cheaper than the other even
> after taking into account the necessity of working around any missing
> features in the cheaper implementation.
>
> Why is it acceptable to do that if "cheaper" still involves money, but
> not if "cheaper" is free?
>
> Would SBCL be acceptable if they charged $1 for a license? $10? $100?
>
> That's the issue that you're avoiding with all this smoke and mirrors
> about analogies, and that I pointed out by restating your words to you.
I think you might be missing the point. It is fine to /use/ SBCL, and
for all I know I could end up shipping with that on OS X (unlikely tho
with LW available so /reasonably/).
But if I trace a problem using SBCL /to/ SBCL and make a bug report and
someone from the dev team responds "The open source fairy has left the
building, we eagerly await your patch. You can download the sources
here, the build instructions here, and... hello? hello? Kenny?", I'll be
on the phone to Lispworks or begging Franz for forgiveness.
See, this is what happens when you get all riled up and change the
subject to whether Kenny is consistent or not, you get so emotional you
cannot read straight. And my inconsistency varies quite a bit, so I do
not know if you can build an argument on that anyway.
:)
kenzo
ps. Random problem cloning is going well, but obviously slowly enough to
have me dashing here to hide pretty regularly. :) What kind of Lisp did
you write today? k
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
>>>>> "KT" == Ken Tilton <·········@gmail.com> writes:
KT> But if I trace a problem using SBCL /to/ SBCL and make a bug
KT> report and someone from the dev team responds "The open source
KT> fairy has left the building, we eagerly await your patch. You
KT> can download the sources here, the build instructions here,
KT> and... hello? hello? Kenny?", I'll be on the phone to
KT> Lispworks or begging Franz for forgiveness.
Ah, but that's preferable to the situation I've been in before - I
trace the problem to the vendor, make a bug report, and the vendor
responds "Thanks, it's entered in our bug database."
At my first professional programming job, I tracked down a bug in the
shared library code in a certain OS. Proprietary OS, but we had a
magical support contract, so I filed a support request and included
the code needed to consistently reproduce it. They thanked us and
informed us that a fix was planned for a later release at an
unspecified date. This was a show-stopping bug; while it persisted,
we could not get our database to talk to our webserver.
But wait! We had paid umpty-thousand more for a source code license!
Armed with that and gdb, another programmer managed to find the line
of code with the bug and fix it! We then submitted a patch to the
vendor, who at least gave us credit when they finally got around to
issuing the update.
I don't know what we would have done without that support contract!
Thank goodness the vendor was responsive to our needs! I don't know
what would have happened if we had gone with an open-source operating
system with no support!
There are cases in which the feature set is so compelling that there
is no free alternative -- I use OS X on my desktop for that reason.
But I prefer the honest lack of a support guarantee, plus available
source code, to a guarantee of support that's only enforceable because
I can walk away from that product. If I have access to the source
code, I can fix the problem or pay someone else to fix it for me; if I
don't have access to the source code, I'm completely at the mercy of
the vendor. You apparently trust the vendor much more than I do.
Charlton
--
Charlton Wilbur
·······@chromatico.net
On Dec 1, 2:57 pm, Charlton Wilbur <·······@chromatico.net> wrote:
> >>>>> "KT" == Ken Tilton <·········@gmail.com> writes: KT> But if I trace a problem using SBCL /to/ SBCL and make a bug
> KT> report and someone from the dev team responds "The open source
> KT> fairy has left the building, we eagerly await your patch. You
> KT> can download the sources here, the build instructions here,
> KT> and... hello? hello? Kenny?", I'll be on the phone to
> KT> Lispworks or begging Franz for forgiveness.
>
> Ah, but that's preferable to the situation I've been in before - I
> trace the problem to the vendor, make a bug report, and the vendor
> responds "Thanks, it's entered in our bug database."
>
> At my first professional programming job, I tracked down a bug in the
> shared library code in a certain OS. Proprietary OS, but we had a
> magical support contract, so I filed a support request and included
> the code needed to consistently reproduce it. They thanked us and
> informed us that a fix was planned for a later release at an
> unspecified date. This was a show-stopping bug; while it persisted,
> we could not get our database to talk to our webserver.
>
> But wait! We had paid umpty-thousand more for a source code license!
> Armed with that and gdb, another programmer managed to find the line
> of code with the bug and fix it! We then submitted a patch to the
> vendor, who at least gave us credit when they finally got around to
> issuing the update.
>
> I don't know what we would have done without that support contract!
> Thank goodness the vendor was responsive to our needs! I don't know
> what would have happened if we had gone with an open-source operating
> system with no support!
>
> There are cases in which the feature set is so compelling that there
> is no free alternative -- I use OS X on my desktop for that reason.
> But I prefer the honest lack of a support guarantee, plus available
> source code, to a guarantee of support that's only enforceable because
> I can walk away from that product. If I have access to the source
> code, I can fix the problem or pay someone else to fix it for me; if I
> don't have access to the source code, I'm completely at the mercy of
> the vendor. You apparently trust the vendor much more than I do.
>
> Charlton
I also have had past experiences like Charlton. I have three
experiences with vendors/software.
1) Small company vendor. We paid a boatload of money for a file system
that "will just work". I spend many months getting it working and
feeding back bug fixes, it was obvious that their code had never run on
ARM processsor before. They were extremely receptive of the patches, I
had full code access and they rolled my fixes in. However, this was a
product we paid a lot of money for so that we wouldn't need to fix it,
and they got our fixes for free! We ended up ditching the system and
using an open source filesystem. Not really a bad experience, but not
good either.
2) Microsoft. I had partial access to code, which is the biggest issue
- you can't even really determine how to work around bugs. MS will
only talk to you if you pay them to or are a huge customer. Even when
we hand MS the backtraces, steps to reproduce and a possible fix they
may or may not look at it. If they do fix it, you don't get the fix
until the next release cycle and you can't ship your product until you
get the official MS binaries - ie, no way for us to patch it.
3) Linux kernel & other opensource projects. You have the code and you
are able to fix it given enough motivation. You may or may not get
help from mailing lists, but in generally it is pretty good. Your
patch if it is good will go into the main source. You don't need to
wait for the maintainer to bless the patch for you to ship.
Number 1 and 3 were pretty much the same in terms of support and
feedback, though giving time and effort to something that you paid big
money for hurts.
Trying to get support from MS is like getting blood from a stone.
So, like all things, it is not a case of Free Software is better/worse
than propriety software - it is shades of grey.
This thread started as a simple "well done for hitting 1.0, an
important milestone", but somehow got trolled into a free/propriety
flame fest.
Anyhow - well done to the SBCL devs. I appreciate the hard work you've
put in, and I'm glad you're all having fun working on free software.
Cheers
Brad
Charlton Wilbur wrote:
>>>>>>"KT" == Ken Tilton <·········@gmail.com> writes:
>
>
> KT> But if I trace a problem using SBCL /to/ SBCL and make a bug
> KT> report and someone from the dev team responds "The open source
> KT> fairy has left the building, we eagerly await your patch. You
> KT> can download the sources here, the build instructions here,
> KT> and... hello? hello? Kenny?", I'll be on the phone to
> KT> Lispworks or begging Franz for forgiveness.
>
> Ah, but that's preferable to the situation I've been in before - I
> trace the problem to the vendor, make a bug report, and the vendor
> responds "Thanks, it's entered in our bug database."
Franz has only done that once, and it was just (an insanely irritating)
mis-warning -- well, no, the person handling the report would only admit
the mis-warning was "confusing".
I did see that Lispworks reserves the right not to move on a bug. Hmmm.
When we started using AllegroStore, I could tell we would flush out a
number of bugs and we did, but it also a huge productivity win (I did
some really sick things with it).
>
> At my first professional programming job, I tracked down a bug in the
> shared library code in a certain OS. Proprietary OS, but we had a
> magical support contract, so I filed a support request and included
> the code needed to consistently reproduce it. They thanked us and
> informed us that a fix was planned for a later release at an
> unspecified date. This was a show-stopping bug; while it persisted,
> we could not get our database to talk to our webserver.
You do have to pick your vendors. :) And if Franz or LW acted like that
there is one good argument for an open source Lisp.
>
> But wait! We had paid umpty-thousand more for a source code license!
> Armed with that and gdb, another programmer managed to find the line
> of code with the bug and fix it! We then submitted a patch to the
> vendor, who at least gave us credit when they finally got around to
> issuing the update.
I know one vendor who would have sued you. I got thrown in to install a
release and it did not build, so I innocently fixed the include files
and sent back the fixes, starting a funny little firefight.
>
> I don't know what we would have done without that support contract!
> Thank goodness the vendor was responsive to our needs! I don't know
> what would have happened if we had gone with an open-source operating
> system with no support!
>
> There are cases in which the feature set is so compelling that there
> is no free alternative -- I use OS X on my desktop for that reason.
> But I prefer the honest lack of a support guarantee, plus available
> source code, to a guarantee of support that's only enforceable because
> I can walk away from that product. If I have access to the source
> code, I can fix the problem or pay someone else to fix it for me; if I
> don't have access to the source code, I'm completely at the mercy of
> the vendor. You apparently trust the vendor much more than I do.
Er, maybe I size them up better? :)
The premise has shifted now to ACL and LW being such unusable pieces of
crap that the cost of developing SBCL... nah, I shill ACL, but I also
see/hear terrific things about LW all the time here on c.l.l.
kt
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
>>>>> "KT" == Ken Tilton <·········@gmail.com> writes:
KT> You do have to pick your vendors. :) And if Franz or LW acted
KT> like that there is one good argument for an open source Lisp.
And they're vendors; they might start acting like that at any moment,
and the existence of an open source Lisp will keep them on their toes.
>> If I have access to the source code, I can fix the problem or
>> pay someone else to fix it for me; if I don't have access to
>> the source code, I'm completely at the mercy of the vendor.
>> You apparently trust the vendor much more than I do.
KT> Er, maybe I size them up better? :)
In the specific case, you've found two decent vendors. This will
stand you in good stead until ownership or management changes at
either or both vendors.
KT> The premise has shifted now to ACL and LW being such unusable
KT> pieces of crap that the cost of developing SBCL... nah, I
KT> shill ACL, but I also see/hear terrific things about LW all
KT> the time here on c.l.l.
No -- it's more that the cost of developing SBCL is being paid by
people who do it gladly -- because, as you note, somewhere in the
neighborhood of 12 developer-hours will pay for a commercial Lisp, and
anyone competent to work on a free Lisp assuredly knows this -- and
the existence of SBCL is insurance against ACL and LW *becoming*
unusable pieces of crap and a goad to ACL and LW to make sure that
they add value that can't be had in an open source Lisp.
It seems to me that this is only a good thing, because people can try
out Lisp with a very low commitment, while LW and ACL can compete on
quality, feature set, and support. If LW and ACL *don't* beat the
free Lisps in those areas, why *should* anyone pay money for them?
Charlton
--
Charlton Wilbur
·······@chromatico.net
Charlton Wilbur wrote:
>>>>>>"KT" == Ken Tilton <·········@gmail.com> writes:
>
>
> KT> You do have to pick your vendors. :) And if Franz or LW acted
> KT> like that there is one good argument for an open source Lisp.
>
> And they're vendors; they might start acting like that at any moment,
> and the existence of an open source Lisp will keep them on their toes.
Yes, my argument cuts both ways. Without SBCL the proprietary Lisps
might well be more expensive. And since the FSF has indeed successfully
convinced everyone not to pay for their tools, SBCL might be the only
way to suck in the great unwashed. Then I can enjoy some serious abuse
here on c.l.l.
Of course the GUw will balk at that ASDF/Slime/Emacs hodgepodge, so they
either run back to Java or Franz strikes it rich with their great IDE,
less so LW methinks, but then maybe they spend a weekend on it and fix
it. :)
>
> >> If I have access to the source code, I can fix the problem or
> >> pay someone else to fix it for me; if I don't have access to
> >> the source code, I'm completely at the mercy of the vendor.
> >> You apparently trust the vendor much more than I do.
>
> KT> Er, maybe I size them up better? :)
>
> In the specific case, you've found two decent vendors. This will
> stand you in good stead until ownership or management changes at
> either or both vendors.
>
> KT> The premise has shifted now to ACL and LW being such unusable
> KT> pieces of crap that the cost of developing SBCL... nah, I
> KT> shill ACL, but I also see/hear terrific things about LW all
> KT> the time here on c.l.l.
>
> No -- it's more that the cost of developing SBCL is being paid by
> people who do it gladly -- because, as you note, somewhere in the
> neighborhood of 12 developer-hours will pay for a commercial Lisp, and
> anyone competent to work on a free Lisp assuredly knows this --
I don't know. I have heard some pretty fierce claims from people about
never ever paying for software. We get 'em here pretty regularly on
c.l.l. I think contra some people's opinions, I am the one obsessed with
cost.
> and
> the existence of SBCL is insurance against ACL and LW *becoming*
> unusable pieces of crap and a goad to ACL and LW to make sure that
> they add value that can't be had in an open source Lisp.
>
> It seems to me that this is only a good thing, because people can try
> out Lisp with a very low commitment, while LW and ACL can compete on
> quality, feature set, and support.
Well, both vendors do offer not-very-crippled-at-all free versions.
Clearly the best argument for SBCL is the same as for Everest: because
it is there.*
kt
* Apparently never meant to be profound. Mallory was just blowing off
some reporter who irritated him by asking why he climbed mountains. So
now the yobbos have a nice short answer for me. :) k
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
>>>>> "KT" == Ken Tilton <·········@gmail.com> writes:
(quoting me)
>> No -- it's more that the cost of developing SBCL is being paid
>> by people who do it gladly -- because, as you note, somewhere
>> in the neighborhood of 12 developer-hours will pay for a
>> commercial Lisp, and anyone competent to work on a free Lisp
>> assuredly knows this --
KT> I don't know. I have heard some pretty fierce claims from
KT> people about never ever paying for software. We get 'em here
KT> pretty regularly on c.l.l. I think contra some people's
KT> opinions, I am the one obsessed with cost.
I didn't say it was a cost they were willing to pay.
The decision to never ever pay for software has its own cost; not all
costs are measured in dollars. I expect anyone competent to work on
an open-source Lisp understands this too. The qualification is important.
Charlton
--
Charlton Wilbur
·······@chromatico.net
On 2006-12-02 01:04:47 +0000, Charlton Wilbur <·······@chromatico.net> said:
> And they're vendors; they might start acting like that at any moment,
> and the existence of an open source Lisp will keep them on their toes.
So long as they are not monopolists they will not start acting like
this, because their customers will go elsewhere and they will go
bankrupt. *Monopoly* is the enemy, not commercial (or free) software.
--tim
>>>>> "TB" == Tim Bradshaw <···@tfeb.org> writes:
TB> On 2006-12-02 01:04:47 +0000, Charlton Wilbur
TB> <·······@chromatico.net> said:
>> And they're vendors; they might start acting like that at any
>> moment, and the existence of an open source Lisp will keep them
>> on their toes.
TB> So long as they are not monopolists they will not start acting
TB> like this, because their customers will go elsewhere and they
TB> will go bankrupt. *Monopoly* is the enemy, not commercial (or
TB> free) software.
Except that in a market like commercial Lisps, which is tiny to begin
with, it's entirely possible to have all the major players act like
that and not have enough of a market left for another commercial Lisp
to get traction -- especially if they have to convince venture
capitalists to fund the whole thing.
Monopoly is the enemy, but free software is a very effective tool
against monopoly.
Charlton
--
Charlton Wilbur
·······@chromatico.net
On 2006-12-03 16:42:49 +0000, Charlton Wilbur <·······@chromatico.net> said:
> Except that in a market like commercial Lisps, which is tiny to begin
> with, it's entirely possible to have all the major players act like
> that and not have enough of a market left for another commercial Lisp
> to get traction -- especially if they have to convince venture
> capitalists to fund the whole thing.
But they don't. I could be a commercial Lisp vendor: I could take SBCL
or CMUCL and start selling support for it.
On 2006-12-01 22:57:43 +0000, Charlton Wilbur <·······@chromatico.net> said:
> At my first professional programming job, I tracked down a bug in the
> shared library code in a certain OS. Proprietary OS, but we had a
> magical support contract, so I filed a support request and included
> the code needed to consistently reproduce it. They thanked us and
> informed us that a fix was planned for a later release at an
> unspecified date. This was a show-stopping bug; while it persisted,
> we could not get our database to talk to our webserver.
In my experience this is almost always due to a failure of
communication. You're the customer, you're paying them money. Tell
them to get their finger out and fix the bloody problem, don't sit and
let them crap all over you. I've seen this happen so many times: the
machine keeps dying because of some known memory issue, so someone
files a support call and they say `let it fall over a few more times
and then perhaps we'll swap the board', so you have to get on the phone
and explain that no, they will come tonight and replace the board,
thank you very much. And lo, they do.
--tim
>>>>> "TB" == Tim Bradshaw <···@tfeb.org> writes:
TB> On 2006-12-01 22:57:43 +0000, Charlton Wilbur
TB> <·······@chromatico.net> said:
>> At my first professional programming job, I tracked down a bug
>> in the shared library code in a certain OS. Proprietary OS,
>> but we had a magical support contract, so I filed a support
>> request and included the code needed to consistently reproduce
>> it. They thanked us and informed us that a fix was planned for
>> a later release at an unspecified date. This was a
>> show-stopping bug; while it persisted, we could not get our
>> database to talk to our webserver.
TB> In my experience this is almost always due to a failure of
TB> communication. You're the customer, you're paying them money.
TB> Tell them to get their finger out and fix the bloody problem,
TB> don't sit and let them crap all over you. I've seen this
TB> happen so many times: the machine keeps dying because of some
TB> known memory issue, so someone files a support call and they
TB> say `let it fall over a few more times and then perhaps we'll
TB> swap the board', so you have to get on the phone and explain
TB> that no, they will come tonight and replace the board, thank
TB> you very much. And lo, they do.
When the only weapon you have to hold over them is the chance that
you'll go to another vendor, and they know you are tied to them
because you've got custom code written against their operating system
so that you changing to another vendor will cost you more than it does
them, what motivation do they have to fix things?
If "This is a showstopper bug, and if you can't fix it, we'll have to
move to another vendor, and we want this project ready to deploy in
three months" won't get them to move, what will?
(The company in question, incidentally, was basically put out of
business because they couldn't compete with the free operating
systems, which offered all the same benefits but none of the costs.)
Charlton
--
Charlton Wilbur
·······@chromatico.net
On 2006-12-03 16:47:39 +0000, Charlton Wilbur <·······@chromatico.net> said:
> If "This is a showstopper bug, and if you can't fix it, we'll have to
> move to another vendor, and we want this project ready to deploy in
> three months" won't get them to move, what will?
Talking to the right person in the company.
On Sun, 03 Dec 2006 11:47:39 -0500, Charlton Wilbur wrote:
> When the only weapon you have to hold over them is the chance that
> you'll go to another vendor, and they know you are tied to them
> because you've got custom code written against their operating system
> so that you changing to another vendor will cost you more than it does
> them, what motivation do they have to fix things?
That really isn't the only weapon that you hold. It's just a pity that
there don't seem to have been enough trade practices cases run against
software manufacturers: everyone's been trained to expect software to be
broken.
In some jurisdictions you can't contract out of your basic trade-practices
law rights to be sold something that isn't broken, or works as described.
Of course, you only get your money back, but that's a lot different for
the vendor than simply having you go off in a huff to another supplier.
A few court cases will (eventually) change the way that the software
industry works. It's young, yet.
Cheers,
--
Andrew
>>>>> "AR" == Andrew Reilly <···············@areilly.bpc-users.org> writes:
AR> On Sun, 03 Dec 2006 11:47:39 -0500, Charlton Wilbur wrote:
>> When the only weapon you have to hold over them is the chance
>> that you'll go to another vendor, and they know you are tied to
>> them because you've got custom code written against their
>> operating system so that you changing to another vendor will
>> cost you more than it does them, what motivation do they have
>> to fix things?
AR> That really isn't the only weapon that you hold. It's just a
AR> pity that there don't seem to have been enough trade practices
AR> cases run against software manufacturers: everyone's been
AR> trained to expect software to be broken.
In other words, you're recommending a legal route?
Let me reiterate the problem. We were building something that we
wanted to have done in three months -- not a huge project, but
potentially lucrative. It required getting a webserver on one machine
to talk to a database server on another machine. There was a bug in
the operating system's shared library code that prevented this from
happening. We used our tech support license to file a support
request; the response was "This bug is on our list of things to be
fixed in the next release."
And it wasn't as if this was a bug they should reasonably have caught:
it was a fairly bizarre case. If we had not had the particular
combination of server OS version, client OS version, and various
library versions, we would never have hit it. If I remember right, it
had to do with a set of libraries having been compiled by a different
vendor with some foolish assumptions; but that vendor wanted a
five-figure license fee before it would even accept bug reports.
AR> In some jurisdictions you can't contract out of your basic
AR> trade-practices law rights to be sold something that isn't
AR> broken, or works as described. Of course, you only get your
AR> money back, but that's a lot different for the vendor than
AR> simply having you go off in a huff to another supplier.
The cost here was not the license or the support contract -- the time
spent tracking this bug down would have paid for both a dozen times
over. I am not so naive to think that software of a size sufficient
to do something useful can be free of bugs, regardless of what the law
may eventually claim; and the vendor giving back every penny we spent
on the license would have been a larger problem, because we had over a
dozen servers running without any problems, and for a lot of what we
were doing, that OS *was* the best then available.
This was the first lesson in the course that taught me that vendors
are simply not to be trusted. Sometimes they're a necessary evil;
sometimes they're actually helpful and supportive. But in the end,
you only get from them what they're willing to give you -- which may
change at any moment -- and what you can make them give you. Support
is an illusion.
Charlton
--
Charlton Wilbur
·······@chromatico.net
Charlton Wilbur wrote:
> We used our tech support license to file a support
> request; the response was "This bug is on our list of things to be
> fixed in the next release."
The question is: what did you do then? Did you, for instance explain
that this wasn't a good answer (in such a way as to not piss the vendor
off), and escalate the issue until you either hit the CEO and they said
to get lost, or (much more likely) you got to someone who understood
and was willing to cut you a private patch or other workaround.
This approach can fail, but it works surprisingly often. The three
tricks involved are:
(a) don't behave like some emotionally-disfunctional geek. You have to
be *nice* to them so they want to help you.
(b) get above the front-line support people (and the developers if any,
as they will be busy behaving like emotionally-disfunctional geeks), to
someone who understand the business case.
(c) keep on escalating, being nice all the time.
It helps if you are a reasonably large customer. But on the other hand
I have, on behalf of a 2-and-a-bit person company, exchanged mail with
the CEO of a multi-billion-dollar company to get issues fixed (and they
did get fixed).
--tim
>>>>> "TB" == Tim Bradshaw <··········@tfeb.org> writes:
TB> Charlton Wilbur wrote:
>> We used our tech support license to file a support request; the
>> response was "This bug is on our list of things to be fixed in
>> the next release."
TB> The question is: what did you do then? Did you, for instance
TB> explain that this wasn't a good answer (in such a way as to
TB> not piss the vendor off), and escalate the issue until you
TB> either hit the CEO and they said to get lost, or (much more
TB> likely) you got to someone who understood and was willing to
TB> cut you a private patch or other workaround.
I explained to the engineers that this was not an acceptable answer,
because the next release did not have a firm release date, and the
project we needed that particular bug fixed for did.
I have no idea if we could have gotten it resolved at all through
proper channels; we solved it ourself with the source code we had
bought a license for.
TB> This approach can fail, but it works surprisingly often. The
TB> three tricks involved are: (a) don't behave like some
TB> emotionally-disfunctional geek. You have to be *nice* to them
TB> so they want to help you. (b) get above the front-line
TB> support people (and the developers if any, as they will be
TB> busy behaving like emotionally-disfunctional geeks), to
TB> someone who understand the business case. (c) keep on
TB> escalating, being nice all the time.
(a) was not a problem; the engineers thought this was a fascinating
bug, but the line they were getting from their management was that it
was so rare that it was not worth spending the time to produce a
custom patch when they were trying to get more critical bugs fixed in
the next release. Clearly, to get this bug fixed, I had to convince
management.
(b) was something I tried. The problem is, the business case didn't
support fixing the bug at a very high priority. We were doing
something unusual and (frankly) stupid, and the best technical
solution to the problem would not have tickled that particular bug.
Unfortunately, the best technical solution was not available for
political and marketing reasons. So the managers were faced with a
problem which they did not think was a high-priority fix: we may have
been the only customer that needed that bug fixed immediately, and
there was a clear workaround that their engineers recommended.
(c) was in progress when we fixed the bug ourselves using the source
code. At that point I had handed the interaction with the vendor over
to my manager, because I was a 21-year-old coder and had little clout
in my company and none at all with the vendor.
TB> It helps if you are a reasonably large customer. But on the
TB> other hand I have, on behalf of a 2-and-a-bit person company,
TB> exchanged mail with the CEO of a multi-billion-dollar company
TB> to get issues fixed (and they did get fixed).
We were a 10-person company, and I don't think they had more than 50.
They are no longer in business, having been bought -- I think mainly
for the quality of the engineering staff, because the open source
operating systems with support contracts collectively destroyed their
business model.
And this is the thing - I think these guys were overall a *good*
vendor -- their product was very good, and probably the best option in
its price range. (I don't recall what the alternatives were at that
point; thus the hedge language.) When push comes to shove, a vendor
acts in the vendor's best interest, which may or may not be the
client's best interest.
Charlton
--
Charlton Wilbur
·······@chromatico.net
Charlton Wilbur wrote:
> And this is the thing - I think these guys were overall a *good*
> vendor -- their product was very good, and probably the best option in
> its price range. (I don't recall what the alternatives were at that
> point; thus the hedge language.) When push comes to shove, a vendor
> acts in the vendor's best interest, which may or may not be the
> client's best interest.
>From all of the stuff I elided it sounds as if the approach of
escalating would have worked just fine with this vendor, but you got it
fixed first. Probably you (your company I mean) did not escalate
quickly enough, but that's the usual case.
So I think this is a really poor argument for open source or whatever
basically. (Not that there are not good arguments, this just isn't one).
>>>>> "TB" == Tim Bradshaw <··········@tfeb.org> writes:
TB> From all of the stuff I elided it sounds as if the approach of
TB> escalating would have worked just fine with this vendor, but
TB> you got it fixed first. Probably you (your company I mean)
TB> did not escalate quickly enough, but that's the usual case.
TB> So I think this is a really poor argument for open source or
TB> whatever basically. (Not that there are not good arguments,
TB> this just isn't one).
I disagree; it's impossible to know what would have happened, but the
line we got for a full month was that it would be fixed in the next
yet-to-be-announced release, and nothing we did got that to change.
Without the source code, that fix would have been *completely* at the
vendor's whim. Preventing that is the *point* of free software, in
the FSF sense.
You're using a "would have worked, if only" hypothetical to refute the
argument. The fact is, we could not afford to wait for the "if only"
to come to fruition. We had already wasted a month of a three-month
schedule on this bug, and if we had wasted another two weeks we would
almost certainly have missed our deadline completely, and lost a
seven-figure contract as a result.
Charlton
--
Charlton Wilbur
·······@chromatico.net
On 2006-12-05 18:45:40 +0000, Charlton Wilbur <·······@chromatico.net> said:
> You're using a "would have worked, if only" hypothetical to refute the
> argument.
I'm not trying to refute it. I'm trying to indicate that may be the
balance of probabilities is that my escalate approach works a lot of
the time. Based on a single data point (and a number I haven't
described and probably can't, but still a small number) there's not
enough evidence either way to draw any conclusion, either way (so
that's why it's a `really poor argument': any argument from a single
data point is really poor).
--tim
Ken Tilton wrote:
> See, this is what happens when you get all riled up and change the
> subject to whether Kenny is consistent or not, you get so emotional you
> cannot read straight. And my inconsistency varies quite a bit, so I do
> not know if you can build an argument on that anyway.
"And my inconsistency varies quite a bit..."
well done :)
>
> :)
>
> kenzo
>
> ps. Random problem cloning is going well, but obviously slowly enough to
> have me dashing here to hide pretty regularly. :) What kind of Lisp did
> you write today? k
>
Ken Tilton <·········@gmail.com> writes:
> I did not go home and write a lisp.
Are you saying this because you think someone else did this when they
found out how much LW and ACL cost?
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Ken Tilton <·········@gmail.com> writes:
>
> SBCL developers are not looking at cost. If they were, they would buy
> a license for the tax-deductible cost of twelve hours work.
You're quite right--they're doing what they do for the love of
programming. Free software developer are to proprietary software
developers as amateur athletes are to professionals: they do it for love
rather than money.
Of course, there's another love/money divide: that between spouses and
prostitutes...
--
Robert Uhl <http://public.xdi.org/=ruhl>
Skill without imagination is craftsmanship and gives us many useful
objects such as wickerwork picnic baskets. Imagination without skill
gives us modern art. --Tom Stoppard
On 2006-12-01 16:48:58 +0000, Charlton Wilbur <·······@chromatico.net> said:
> Can't you imagine Franz's position? The language is a productivity
> grand slam and they are offering you an extraordinary implementation
> and add-ons, and you had the GALL to choose a different vendor based
> on COST.
You know, it's all about the cost, and Kenny actually, shockingly, has
*thought* about it. Probably he'd even done some of those horrible
calculations of what things actually cost, rather than just assuming
that it's free because they don't charge you for a copy of the software
or something.
Do you know what I did today? I spent about 3 hours printing out bar
codes, cutting them out with scissors, and sticking them onto LTO
tapes. And then peeling off most of them because the bloody PDF
printer thought it was a clever idea to scale the output slightly so
the robot could only read about 1 in 3 of them which took another hour
or 2.
I did this because the company thinks that 44p each for professionally
printed labels was too much to pay and some random bit of free software
will print them anyway.
So let's see how much they save each week, shall we? Say we go through
50 tapes a week, that's a saving of, well, �22. Oh, but 4 hours a week
with paper and scissors at, well, quite a lot more than �22 an hour.
And let's hope that the labels don't fall off inside the library and
get in the works causing all the backups to fail (may be Sun will even
not charge for pulling all the bits of label out of the thing).
Damn, you have no idea how much I wish people had basic (basic)
economic literacy. They should teach it instead of CS, it would be a
lot more useful.
--tim
>>>>> "TB" == Tim Bradshaw <···@tfeb.org> writes:
TB> On 2006-12-01 16:48:58 +0000, Charlton Wilbur
TB> <·······@chromatico.net> said:
>> Can't you imagine Franz's position? The language is a
>> productivity grand slam and they are offering you an
>> extraordinary implementation and add-ons, and you had the GALL
>> to choose a different vendor based on COST.
TB> You know, it's all about the cost, and Kenny actually,
TB> shockingly, has *thought* about it. Probably he'd even done
TB> some of those horrible calculations of what things actually
TB> cost, rather than just assuming that it's free because they
TB> don't charge you for a copy of the software or something.
It *is* all about the cost. But Kenny doesn't want someone else
deciding that choosing a vendor who doesn't charge a license fee is an
acceptable way to reduce the cost. That's what I'm objecting to. He
can spend his own money any damnfool way he wants to; he just doesn't
get to tell me how to spend my money.
If it's acceptable and laudable for him to decide that he'll go with
vendor B because vendor B charges less than vendor A for the feature
set he wants or needs, where does he get off telling me that I *can't*
go with vendor C because vendor C charges less than vendor A or B for
the feature set that *I* want or need, simply because vendor C isn't
charging at all? "Free" is just the asymptotic limit of "cheaper."
Assuming that things cost *more* because you aren't charged a license
fee is just as fallacious as assuming that they cost *less*, and
assuming that the set of tradeoffs that is acceptable to you is
universally acceptable is just stupid.
Charlton
--
Charlton Wilbur
·······@chromatico.net
Charlton Wilbur <·······@chromatico.net> writes:
> If it's acceptable and laudable for him to decide that he'll go with
> vendor B because vendor B charges less than vendor A for the feature
> set he wants or needs, where does he get off telling me that I *can't*
> go with vendor C because vendor C charges less than vendor A or B for
> the feature set that *I* want or need, simply because vendor C isn't
> charging at all? "Free" is just the asymptotic limit of "cheaper."
I don't think that's true. If you're paying for a product, a company
has an incentive to provide support and fix bugs; if you don't pay,
they don't get your money, their reputation is diminished, and they
run the risk of going out of business or losing sales at a minimum.
If you're getting a product for free, the developers have no incentive
to help you out other than their own generosity. That's a pretty
fundamental difference.
Going to a cheaper vendor is still going to a vendor - someone who has
a vested interest in seeing that you, personally, do well.
Charlton Wilbur wrote:
>>>>>>"TB" == Tim Bradshaw <···@tfeb.org> writes:
>
>
> TB> On 2006-12-01 16:48:58 +0000, Charlton Wilbur
> TB> <·······@chromatico.net> said:
>
> >> Can't you imagine Franz's position? The language is a
> >> productivity grand slam and they are offering you an
> >> extraordinary implementation and add-ons, and you had the GALL
> >> to choose a different vendor based on COST.
>
> TB> You know, it's all about the cost, and Kenny actually,
> TB> shockingly, has *thought* about it. Probably he'd even done
> TB> some of those horrible calculations of what things actually
> TB> cost, rather than just assuming that it's free because they
> TB> don't charge you for a copy of the software or something.
>
> It *is* all about the cost. But Kenny doesn't want someone else
> deciding that choosing a vendor who doesn't charge a license fee is an
> acceptable way to reduce the cost. That's what I'm objecting to. He
> can spend his own money any damnfool way he wants to; he just doesn't
> get to tell me how to spend my money.
No, you are completely confused. I am arguing that the cost to the
developers of SBCL dwarfs the cost of LW/ACL, if only they understood
their time has value. I am trying to save them money. You? I don't know
what you are doing. You working on SBCL? How many hours you got in on
it? How do you price your time?
If they were working on cffi-grovel or a truly excellent cl-sockets or
even Ltk or Cells-Gtk, Lisp would have a larger customer base and Franz
and LW could try different prices. And every Lispnik would be more
productive (that has to do with the cost of doing business, you know).
I am the one talking about cost, you are just obsessing over Kenny. It
happens.
kt
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
This thread is such a trainwreck that I was going to stay away from it.
"Ooops."
> I am arguing that the cost to the developers of SBCL dwarfs the cost of LW/ACL
Perfectly correct.
However, using money to buy X and using time worth more money to build
Y are comparable only if X and Y are equivalent or means to the same
goal for the person whose time and money we're talking about.
Perhaps you can see how this is not the case for SBCL developers?
Cheers,
-- Nikodemus Siivola
On 2006-12-01 18:53:01 -0500, ·········@random-state.net said:
> This thread is such a trainwreck that I was going to stay away from it.
Come all you lispers if you wanna hear,
The story of a brave engineer
Kenzo Tilton was the lisper's name,
With a dataflow paradigm he won his fame
Kenzo Tilton, seated at his keyboard
Kenzo Tilton, sexps flowing from his hands
Kenzo Tilton, seated at his keyboard
And he closed his last parenthesis in the promised land
Kenzo checked the data and the data it flowed
He ran his benchmarks but his benchmarks were slow
He turned to a yobbo and this is what he said
"Yob I'm gonna finish Cello but we'll both be dead!"
Kenzo Tilton, seated at his keyboard
Kenzo Tilton, sexps flowing from his hands
Kenzo Tilton, seated at his keyboard
And he closed his last parenthesis in the promised land
Raffael Cavallaro wrote:
> On 2006-12-01 18:53:01 -0500, ·········@random-state.net said:
>
>> This thread is such a trainwreck that I was going to stay away from it.
>
>
> Come all you lispers if you wanna hear,
> The story of a brave engineer
> Kenzo Tilton was the lisper's name,
> With a dataflow paradigm he won his fame
>
> Kenzo Tilton, seated at his keyboard
> Kenzo Tilton, sexps flowing from his hands
> Kenzo Tilton, seated at his keyboard
> And he closed his last parenthesis in the promised land
>
> Kenzo checked the data and the data it flowed
> He ran his benchmarks but his benchmarks were slow
Nonsense! I have never had a Cells performance problem Cells itself
could not handle.
> He turned to a yobbo and this is what he said
> "Yob I'm gonna finish Cello but we'll both be dead!"
>
> Kenzo Tilton, seated at his keyboard
> Kenzo Tilton, sexps flowing from his hands
> Kenzo Tilton, seated at his keyboard
> And he closed his last parenthesis in the promised land
>
I ask you guys to write some frickin code and I get ballads.
Anyway, random problem generation is "done". Good work, everyone.
kt
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
On 2006-12-02 04:03:00 -0500, Ken Tilton <·········@gmail.com> said:
> I ask you guys to write some frickin code and I get ballads.
c'mon, admit it - you just sent a copy to your mom ;)
Raffael Cavallaro wrote:
> On 2006-12-02 04:03:00 -0500, Ken Tilton <·········@gmail.com> said:
>
>> I ask you guys to write some frickin code and I get ballads.
>
>
> c'mon, admit it - you just sent a copy to your mom ;)
>
No, I made a few changes and sent it to the Copyright Office.
For Mom I am holding out for the cover of Wired. (She already takes
America's Most Wanted.)
kt
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
>>>>> "KT" == Ken Tilton <·········@gmail.com> writes:
KT> No, you are completely confused. I am arguing that the cost to
KT> the developers of SBCL dwarfs the cost of LW/ACL, if only they
KT> understood their time has value. I am trying to save them
KT> money.
I expect they understand that their time has value; they're just
trading it for things that have a higher value to them than they do to
you. Sorry, but you don't get to spend their time for them any more
than you get to spend their money for them.
Charlton
--
Charlton Wilbur
·······@chromatico.net
Ken Tilton ha escrito:
> I am arguing that the cost to the
> developers of SBCL dwarfs the cost of LW/ACL, if only they understood
> their time has value. I am trying to save them money.
No, you don't. You are trying to evangelize others to your scary and
pathetic world of confusion, while destroying others who logically
defend themselves from your crazy attacks.
You attack SBCL because the SBCL people is not turning around you.
Give up for a moment, let the people live in peace, stop destroying
c.l.l and the Lisp community, please.
On 2006-12-01 23:18:29 +0000, Ken Tilton <·········@gmail.com> said:
> No, you are completely confused. I am arguing that the cost to the
> developers of SBCL dwarfs the cost of LW/ACL, if only they understood
> their time has value. I am trying to save them money. You? I don't know
> what you are doing. You working on SBCL? How many hours you got in on
> it? How do you price your time?
I think that's not clear, if by `developers' you mean `developers of
SBCL'. Sure, it's clear in some mundane time-is-money sense (and this
is exactly the sense I was talking about earlier), but there may be
lots of intangible benefits which are not factored into that.
For instance I spend a lot of time taking making photographs, and since
I do this on film and mostly develop & print them myself I mean a *lot*
of time. And, well, I'm some good, but not really good: not good
enough to make a living at it, say. I could obviously do something
that is *far* more efficient. I could either get a digital camera
(though one to compete with my P67 would still be a serious amount of
money) or I could continue sourcing stuff on film but scan the negs.
But actually, the time in the darkroom is part of the fun. And the
time away from bloody computers is more of it.
The same can be true for the developers of SBCL: they can be working on
it because they *enjoy* working on it. Time spent working on SBCL for
them really isn't money.
This is quite different than the situation for a company considering
which system to use. There time really *is* money - it is *not* useful
for the company to fund some bunch of hackers to have a good time
writing a programming language implementation when it should just use a
(commercial or free, open or closed source) implementation which is as
good. It's not useful *even if the hackers would enjoy that*, because
the company's job is to make money for its shareholders. (Actually, it
might be useful, if retaining said hackers was important enough to the
company.)
--tim
Tim Bradshaw wrote:
> On 2006-12-01 23:18:29 +0000, Ken Tilton <·········@gmail.com> said:
>
>> No, you are completely confused. I am arguing that the cost to the
>> developers of SBCL dwarfs the cost of LW/ACL, if only they understood
>> their time has value. I am trying to save them money. You? I don't
>> know what you are doing. You working on SBCL? How many hours you got
>> in on it? How do you price your time?
>
>
> I think that's not clear, if by `developers' you mean `developers of
> SBCL'. Sure, it's clear in some mundane time-is-money sense (and this
> is exactly the sense I was talking about earlier), but there may be lots
> of intangible benefits which are not factored into that.
>
> For instance I spend a lot of time taking making photographs, and since
> I do this on film and mostly develop & print them myself I mean a *lot*
> of time. And, well, I'm some good, but not really good: not good enough
> to make a living at it, say. I could obviously do something that is
> *far* more efficient. I could either get a digital camera (though one
> to compete with my P67 would still be a serious amount of money) or I
> could continue sourcing stuff on film but scan the negs. But actually,
> the time in the darkroom is part of the fun.
To me it was half the fun. The darkroom was where I first discovered
diamonds in the rough (promising 24x36 chunks of celluloid) and then cut
and polished them in the printing process to produce finished gems of
prints (not that Ansel Adams had anything to worry about).
> And the time away from
> bloody computers is more of it.
>
> The same can be true for the developers of SBCL: they can be working on
> it because they *enjoy* working on it. Time spent working on SBCL for
> them really isn't money.
Fine. Dandy. One such wrote to me in a huff ( a 1949 Huff, to be
specific, with bronze hubcaps) last time I pissed on their work.
But then why is everyone thanking them for all that incredibly hard and
painful labor and self-sacrifice? Oops. :)
For the accomplishment? Oh great! Now we have a native Lisp on Linux!
Nope, can't be that. The awesome SBCL IDE? Oops, sorry, forgot. That
superb, portable SBCL sockets or GUI? Hang on... For what?
Naaahhhhh, come clean: everyone is thanking them for creating a free
alternative to LW and ACL when the community would benefit so much more
if we had so many other things other than a way to avoid letting Lisp
businesses succeed.
What a charming way to expend the intellectual horsepower of all those
young turks, destroying markets for Lisp developers. Franz and LW /are/
our brothers/sisters, right? This is not Microsoft they are undercutting
/liberating us from, these are two great groups of Lisp engineers.
And there really is so much other infrastructure they could be building
that would be of immense value to Lisp, but which is going unbuilt.
What a waste.
kt
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
[...]
> But then why is everyone thanking them for all that incredibly hard and
> painful labor and self-sacrifice? Oops. :)
I thank the pizza guy when he brings food to my door, and, hell, I pay
him for that.
[...]
> Naaahhhhh, come clean: everyone is thanking them for creating a free
> alternative to LW and ACL when the community would benefit so much more
> if we had so many other things other than a way to avoid letting Lisp
> businesses succeed.
I wouldn't benefit more from a portable sockets or GUI library than I
have from SBCL. And yeah, part of the benefit that I've had from SBCL
is that it was free (in the gratis sense). It's given me an opportunity
to try CL for non-trivial work which requires decent performance and be
pleased with the results.
This doesn't mean that I'll never buy a Lispworks license---their
academic pricing is pretty reasonable and if I find that I really like
their IDE[1] I'll go for it. If it weren't for SBCL, it's a good bet
that LW would never have had a shot at my money.
> What a charming way to expend the intellectual horsepower of all those
> young turks, destroying markets for Lisp developers.
Why don't you think the portable GUI you're calling for have a similar
effect, at least on LW? I thought the cross-platform GUI toolkit was a
major selling for it.
Cheers,
Pillsy
[1] LW doesn't have an trial version out for Mac x86 yet, and I need to
try it out to see if it's worth it/
"Pillsy" <·········@gmail.com> writes:
> [1] LW doesn't have an trial version out for Mac x86 yet, and I need to
> try it out to see if it's worth it/
SPOILER: It is. :)
Bill Atkins <······@rpi.edu> wrote:
> "Pillsy" <·········@gmail.com> writes:
>
> > [1] LW doesn't have an trial version out for Mac x86 yet, and I need to
> > try it out to see if it's worth it/
>
> SPOILER: It is. :)
Where? I just checked their web site and didn't see it. It says:
The current version is LispWorks 4.4.6 Personal Edition.
There will be a LispWorks 5.0 Personal Edition, though its
release date is not yet set.
····@stablecross.com (Bob Felts) writes:
> Bill Atkins <······@rpi.edu> wrote:
>
>> "Pillsy" <·········@gmail.com> writes:
>>
>> > [1] LW doesn't have an trial version out for Mac x86 yet, and I need to
>> > try it out to see if it's worth it/
>>
>> SPOILER: It is. :)
>
> Where? I just checked their web site and didn't see it. It says:
>
> The current version is LispWorks 4.4.6 Personal Edition.
>
> There will be a LispWorks 5.0 Personal Edition, though its
> release date is not yet set.
Well, it wouldn't have to be a spoiler if the Personal Edition were
already out. But the Professional Edition has been available since
August.
Bill Atkins <······@rpi.edu> wrote:
> ····@stablecross.com (Bob Felts) writes:
>
> > Bill Atkins <······@rpi.edu> wrote:
> >
> >> "Pillsy" <·········@gmail.com> writes:
> >>
> >> > [1] LW doesn't have an trial version out for Mac x86 yet, and I need to
> >> > try it out to see if it's worth it/
> >>
> >> SPOILER: It is. :)
> >
> > Where? I just checked their web site and didn't see it. It says:
> >
> > The current version is LispWorks 4.4.6 Personal Edition.
> >
> > There will be a LispWorks 5.0 Personal Edition, though its
> > release date is not yet set.
>
> Well, it wouldn't have to be a spoiler if the Personal Edition were
> already out. But the Professional Edition has been available since
> August.
Well, yes. But that's not a trial version, is it?
Did we cross wires? Was the "SPOILER: It is." referring to the
availability of a trial verson, or whether or not LW on the x86 Mac
worth it? On further review, I do believe I missed your original
meaning.
Yes, LW is worth it. I'm aching to put out the $1500 for it, but it
just isn't in the budget.
····@stablecross.com (Bob Felts) writes:
> Bill Atkins <······@rpi.edu> wrote:
>
>> ····@stablecross.com (Bob Felts) writes:
>>
>> > Bill Atkins <······@rpi.edu> wrote:
>> >
>> >> "Pillsy" <·········@gmail.com> writes:
>> >>
>> >> > [1] LW doesn't have an trial version out for Mac x86 yet, and I need to
>> >> > try it out to see if it's worth it/
>> >>
>> >> SPOILER: It is. :)
>> >
>> > Where? I just checked their web site and didn't see it. It says:
>> >
>> > The current version is LispWorks 4.4.6 Personal Edition.
>> >
>> > There will be a LispWorks 5.0 Personal Edition, though its
>> > release date is not yet set.
>>
>> Well, it wouldn't have to be a spoiler if the Personal Edition were
>> already out. But the Professional Edition has been available since
>> August.
>
> Well, yes. But that's not a trial version, is it?
>
> Did we cross wires? Was the "SPOILER: It is." referring to the
I think we did. :)
I thought you were saying that you had yet to try LispWorks and were
waiting for the Macintel version of the Personal Edition to try it and
see if LW was a worthwhile program. All I'm saying is that it is.
Sorry for any confusion.
Pillsy <·········@gmail.com> wrote:
> Ken Tilton wrote:
> [...]
> > But then why is everyone thanking them for all that incredibly hard and
> > painful labor and self-sacrifice? Oops. :)
>
> I thank the pizza guy when he brings food to my door, and, hell, I pay
> him for that.
Did you pay the SBCL team? That's Ken's point. They are the people who
make and deliver pizzas -for free-, to the (alleged) detriment of the
commercial vendors.
[...]
Bob Felts wrote:
> Pillsy <·········@gmail.com> wrote:
> > Ken Tilton wrote:
> > > But then why is everyone thanking them for all that incredibly hard and
> > > painful labor and self-sacrifice? Oops. :)
> > I thank the pizza guy when he brings food to my door, and, hell, I pay
> > him for that.
> Did you pay the SBCL team? That's Ken's point.
I was pretty sure Ken's point was that they were doing it for reasons
beyond altruism and self-sacrifice, and was wondering why we'd thank
them in that case.
[...]
Cheers,
Pillsy
Pillsy wrote:
> Bob Felts wrote:
>
>> Pillsy <·········@gmail.com> wrote:
>
>>> Ken Tilton wrote:
>
>>>> But then why is everyone thanking them for all that incredibly hard and
>>>> painful labor and self-sacrifice? Oops. :)
>
>>> I thank the pizza guy when he brings food to my door, and, hell, I pay
>>> him for that.
>
>> Did you pay the SBCL team? That's Ken's point.
>
> I was pretty sure Ken's point was that they were doing it for reasons
> beyond altruism and self-sacrifice, and was wondering why we'd thank
> them in that case.
...for the same reason that we thank the commercial CL vendors for their
products although they also don't make them out of altruism.
I sincerely hope, _I sincerely hope_, that the people at Franz,
LispWorks, Corman, Digitool, and so on, _enjoy_ what they do and get
satisfaction out of the fact that people use their products. I sincerely
hope that they don't work on their products just for the money!
Stop painting black&white pictures, please. The world is not as simple
as that.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> Pillsy wrote:
[...]
> > I was pretty sure Ken's point was that they were doing it for reasons
> > beyond altruism and self-sacrifice, and was wondering why we'd thank
> > them in that case.
> ...for the same reason that we thank the commercial CL vendors for their
> products although they also don't make them out of altruism.
Well, sure, that too. I was just saying that *even if* someone's
providing a good or service just for the money, it's still nice to
thank them for it. I don't see why it should change when their motives
go from just making money, to making money and enjoying the work and
deriving satisfaction from providing a good product, or to not making
money directly out of the product at all...?
Cheers,
Matt
Pascal Costanza <··@p-cos.net> writes:
> Pillsy wrote:
>> Bob Felts wrote:
>>
>>> Pillsy <·········@gmail.com> wrote:
>>
>>>> Ken Tilton wrote:
>>
>>>>> But then why is everyone thanking them for all that incredibly hard and
>>>>> painful labor and self-sacrifice? Oops. :)
>>
>>>> I thank the pizza guy when he brings food to my door, and, hell, I pay
>>>> him for that.
>>
>>> Did you pay the SBCL team? That's Ken's point.
>>
>> I was pretty sure Ken's point was that they were doing it for reasons
>> beyond altruism and self-sacrifice, and was wondering why we'd thank
>> them in that case.
>
> ...for the same reason that we thank the commercial CL vendors for
> their products although they also don't make them out of altruism.
>
> I sincerely hope, _I sincerely hope_, that the people at Franz,
> LispWorks, Corman, Digitool, and so on, _enjoy_ what they do and get
> satisfaction out of the fact that people use their products. I
> sincerely hope that they don't work on their products just for the
> money!
Indeed. And perhaps this gives another perspective, for those who
complain about open software. Perhaps both sbcl (and other freedom
implementations) developers, and commercial developers do what they do
for the joy of it. It just happens that the market is not big enough
to support all the implementations commercially. So complainers
should be happy that the free implementations actually aren't in the
commercial market, because where two or three commercial enterprises
survive, perhaps 6 or 8 wouldn't.
> Stop painting black&white pictures, please. The world is not as simple
> as that.
--
__Pascal Bourguignon__ http://www.informatimago.com/
ATTENTION: Despite any other listing of product contents found
herein, the consumer is advised that, in actuality, this product
consists of 99.9999999999% empty space.
····@stablecross.com (Bob Felts) writes:
> Pillsy <·········@gmail.com> wrote:
>
>> Ken Tilton wrote:
>> [...]
>> > But then why is everyone thanking them for all that incredibly hard and
>> > painful labor and self-sacrifice? Oops. :)
>>
>> I thank the pizza guy when he brings food to my door, and, hell, I pay
>> him for that.
>
> Did you pay the SBCL team? That's Ken's point. They are the people who
> make and deliver pizzas -for free-, to the (alleged) detriment of the
> commercial vendors.
>
> [...]
Yeah, and all these low-paid delivery boys working for Domino's are
killing the market for professional couriers. What ever will they do?
And while we're at it, tractors are putting farmers out of business all
over the place. Where you once needed dozens of farmers to harvest a
field, you only need a few now! Tractors should be illegal!
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain <·····@nyct.net> writes:
> Yeah, and all these low-paid delivery boys working for Domino's are
> killing the market for professional couriers. What ever will they do?
No, they're not.
> And while we're at it, tractors are putting farmers out of business all
> over the place. Where you once needed dozens of farmers to harvest a
> field, you only need a few now! Tractors should be illegal!
This analogy will work if and when open-source Lisps become better
than their commercial counterparts
Bill Atkins <······@rpi.edu> wrote:
[...]
>
> > And while we're at it, tractors are putting farmers out of business all
> > over the place. Where you once needed dozens of farmers to harvest a
> > field, you only need a few now! Tractors should be illegal!
>
> This analogy will work if and when open-source Lisps become better
> than their commercial counterparts
Indeed; I'll pay for Mac OS X over Linux any day of the week.
····@stablecross.com (Bob Felts) writes:
>
> Indeed; I'll pay for Mac OS X over Linux any day of the week.
And yet for my part I saw a Mac OS X box in the machine room today and
went "Ick, what's that doing in here." Economic value is subjective.
--
Fred Gilham ······@csl.sri.com
All languages have Lisp syntax, of course, except that so many of them
insist on encrypting it using a mechanism called "grammar."
-- Drew McDermott
Bob Felts wrote:
> Pillsy <·········@gmail.com> wrote:
>
>> Ken Tilton wrote:
>> [...]
>>> But then why is everyone thanking them for all that incredibly hard and
>>> painful labor and self-sacrifice? Oops. :)
>> I thank the pizza guy when he brings food to my door, and, hell, I pay
>> him for that.
>
> Did you pay the SBCL team? That's Ken's point. They are the people who
> make and deliver pizzas -for free-,
No, they don't. They get something back in return.
> to the (alleged) detriment of the
> commercial vendors.
>
> [...]
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> wrote:
> Bob Felts wrote:
> > Pillsy <·········@gmail.com> wrote:
> >
> >> Ken Tilton wrote:
> >> [...]
> >>> But then why is everyone thanking them for all that incredibly hard and
> >>> painful labor and self-sacrifice? Oops. :)
> >> I thank the pizza guy when he brings food to my door, and, hell, I pay
> >> him for that.
> >
> > Did you pay the SBCL team? That's Ken's point. They are the people who
> > make and deliver pizzas -for free-,
>
> No, they don't. They get something back in return.
>
The recipient gets it for free; the provider receives an intangible.
For better or for worse, our economy isn't built on intangibles.
I have a hard time siding with Ken on this, because:
1) Worth is relative. It may be that I find an intangible of more value
than dollars. But no one else gets to make that decision for me
(spouses excepted ;-), and
2) It's hard to measure the effect that goods and services received for
intangibles has on the same goods and services received for money.
Bob Felts wrote:
> Pascal Costanza <··@p-cos.net> wrote:
>
>> Bob Felts wrote:
>>> Pillsy <·········@gmail.com> wrote:
>>>
>>>> Ken Tilton wrote:
>>>> [...]
>>>>> But then why is everyone thanking them for all that incredibly hard and
>>>>> painful labor and self-sacrifice? Oops. :)
>>>> I thank the pizza guy when he brings food to my door, and, hell, I pay
>>>> him for that.
>>> Did you pay the SBCL team? That's Ken's point. They are the people who
>>> make and deliver pizzas -for free-,
>> No, they don't. They get something back in return.
>>
>
> The recipient gets it for free; the provider receives an intangible.
> For better or for worse, our economy isn't built on intangibles.
Not exclusively, no. But it's also not exclusively built on tangibles.
> I have a hard time siding with Ken on this, because:
> 1) Worth is relative. It may be that I find an intangible of more value
> than dollars. But no one else gets to make that decision for me
> (spouses excepted ;-), and
> 2) It's hard to measure the effect that goods and services received for
> intangibles has on the same goods and services received for money.
...and vice versa.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Ken Tilton wrote:
> Naaahhhhh, come clean: everyone is thanking them for creating a free
> alternative to LW and ACL when the community would benefit so much more
> if we had so many other things other than a way to avoid letting Lisp
> businesses succeed.
>
> What a charming way to expend the intellectual horsepower of all those
> young turks, destroying markets for Lisp developers. Franz and LW /are/
> our brothers/sisters, right? This is not Microsoft they are undercutting
> /liberating us from, these are two great groups of Lisp engineers.
>
> And there really is so much other infrastructure they could be building
> that would be of immense value to Lisp, but which is going unbuilt.
How do you know all this?
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Am 03.12.2006 23:35 Uhr schrieb "Pascal Costanza" unter <··@p-cos.net> in
···············@mid.individual.net:
> Ken Tilton wrote:
>
>> Naaahhhhh, come clean: everyone is thanking them for creating a free
>> alternative to LW and ACL when the community would benefit so much more
>> if we had so many other things other than a way to avoid letting Lisp
>> businesses succeed.
Where does LW originally come from? ;-)
Make a guess. Hint: the LispWorks editor looks a lot like Hemlock.
>>
>> What a charming way to expend the intellectual horsepower of all those
>> young turks, destroying markets for Lisp developers. Franz and LW /are/
>> our brothers/sisters, right? This is not Microsoft they are undercutting
>> /liberating us from, these are two great groups of Lisp engineers.
>>
>> And there really is so much other infrastructure they could be building
>> that would be of immense value to Lisp, but which is going unbuilt.
>
> How do you know all this?
>
>
> Pascal
Rainer Joswig wrote:
> Am 03.12.2006 23:35 Uhr schrieb "Pascal Costanza" unter <··@p-cos.net> in
> ···············@mid.individual.net:
>
>
>>Ken Tilton wrote:
>>
>>
>>>Naaahhhhh, come clean: everyone is thanking them for creating a free
>>>alternative to LW and ACL when the community would benefit so much more
>>>if we had so many other things other than a way to avoid letting Lisp
>>>businesses succeed.
>
>
> Where does LW originally come from? ;-)
That's actually a non-sequitor if you think about it hard enough.
kt
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Rainer Joswig wrote:
> Where does LW originally come from? ;-)
>
> Make a guess. Hint: the LispWorks editor looks a lot like Hemlock.
Well, CMUCL was "US tax dollars at work."
That's why it got put in the public domain.
"Free" (i.e. someone is paying for it, but not the user, at least not
directly) software pressures software vendors to find ways to give
extra value in their software. For a long time the licenses of
software vendors said, "This doesn't have to work, and if it doesn't,
it's your problem." Often there was no alternative for the user to
accomplish that task. Free software presents alternatives and loosens
the software vendor's grip on the user's nether parts.
I will pay for software that gives features that I want that I can't
otherwise get. When I do, I hold my nose and obey the license
agreement. But often there are free alternatives, and sometimes they
even provide value over and beyond that of pay software.
These things change. Right now I'm willing to put a fair amount of
effort into getting a piece of software to work. But in the old days
I used to change the oil, sparkplugs and so on in my car. No more. I
also used to build my own computers. No more. Eventually I might
wind up buying software on a regular basis. However, since I do have
a lot of knowledge about software and how to deal with its foibles,
and can often fix a piece of software that has minor bugs in a short
time, it is hard for me to feel like it is worth it at this point to
spend a lot of money to buy software that I can't fix, can't change if
I don't like the way it works, and that has onerous license
agreements.
--
Fred Gilham ······@csl.sri.com
"I'm an expert at installing free software. I've installed software
packages that had 412 steps, the first two of which were 'Remove small
children and animals from the premises' and 'Don protective gloves and
mask'. If you made a mistake you had to go back to the very
beginning, including getting the kids and pets back in the house."
On 2006-12-03 22:15:42 +0000, Ken Tilton <·········@gmail.com> said:
> But then why is everyone thanking them for all that incredibly hard and
> painful labor and self-sacrifice? Oops. :)
I don't know. I don't think it's self-sacrifice: I assume they do it
because they enjoy it.
> And there really is so much other infrastructure they could be building
> that would be of immense value to Lisp, but which is going unbuilt.
Well, it's up to them what they give their time to, I think.
--tim
>> And there really is so much other infrastructure they could be
>> building that would be of immense value to Lisp, but which is going
>> unbuilt.
>
>
> Well, it's up to them what they give their time to, I think.
No argument there, just as it's up to them if they want to kill
themselves to avoid buying from Lispworks, so I am not sure this insight
advances the debate.
Despite copious opinion to the contrary, I speak not as Grand Poobah of
Common Lisp and have not the power to marshall our forces to maximize
the benefit of their labor. I can only pause between rides to town on my
pushbox to wonder aloud in camp why a serous chunk of our tribe is over
there under the tree working on the wheel and axle -- ones no better
than the one on my pushcart.
Kenzo: "Dudes, it's been twenty-five years, prices down at Throg's Wheel
& Axle aren't all that bad. Why not work on a mast and sail?"
Answer: "We will never use anything we have to pay for."
Fortunately civilization had made a little headway before Marx and
Stallman came up with that one.
As for: "Oh, golly, I just /live/ for compiler work."... Sure, true in
rare cases, universally claimed when some Wet Blanket(tm) points out the
implicit cost of all the work they did to avoid cost.
kt
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
> No argument there, just as it's up to them if they want to kill
> themselves to avoid buying from Lispworks, so I am not sure this insight
> advances the debate.
Well, I think my argument is something like:
* There's no God-given right for vendors to survive. It's a market,
and they'll survive if they provide something it wants.
* It's up to people what they donate their time to, and they should not
be castigated for working on an OSS Lisp, *even if there is something
which might be more useful to some nebulous `lisp community' for them
to give time to*. (In the same way, for instance, I should not be
castigated for not, say, producing a spec for a better package system
for CL but spending my scarce free time writing stuff to generate
syslog test output in Java, and you shouldn't be castigated for wasting
time flaming on cll).
* There's no God-given right for *Lisp* to survive. If it dies it
dies, and so what. If it dies `because' people spent time on OSS
implementations or something, then so what. There are more important
things in life. (I don't think this outcome is likely though: either
death of Lisp or death-of-lisp-because-of-OSS-implementations.)
* But (and this was my original point) people looking to use Lisp
should actually look at what the various options cost (and not what
they naively think they cost). That may often lead them to non-OSS
solutions (it has lead me to such, twice now).
Really, the last point is the one I wanted to make, since people are in
general very, very poor at doing these kinds of calculation.
--tim
Tim Bradshaw wrote:
> * There's no God-given right for *Lisp* to survive.
<cough> If Mr. Adams had it right, God *is* a Lisp program.
> If it dies it
> dies, and so what.
Oh, plz, that is a red card foul. We are on comp.lang.lisp, that defines
the universe allowed to any discourse. You don't want me to bring up the
Tao Te Ching again, do you?
> If it dies `because' people spent time on OSS
> implementations or something, then so what.
I will have been proven right beyond my wildest dreams?
> There are more important
> things in life.
Security!
> (I don't think this outcome is likely though: either
> death of Lisp or death-of-lisp-because-of-OSS-implementations.)
> * But (and this was my original point) people looking to use Lisp
> should actually look at what the various options cost (and not what
> they naively think they cost). That may often lead them to non-OSS
> solutions (it has lead me to such, twice now).
>
> Really, the last point is the one I wanted to make, since people are in
> general very, very poor at doing these kinds of calculation.
Buy this man a Guinness!
kzo
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
"Tim Bradshaw" <··········@tfeb.org> writes:
> * There's no God-given right for *Lisp* to survive. If it dies it
> dies, and so what. If it dies `because' people spent time on OSS
> implementations or something, then so what. There are more important
> things in life.
No there isn't! :-)
Seriously, I see your point, but the "so what" depends on whether
there are viable alternatives or not: I think that as programmers we
should strive to keep a "craftman's pride". Which includes the usage
of good tools. If a really good tool disappears from the market, and
there are only crappy replacements - shouldn't a proud craftsman be
worried?
--
(espen)
Espen Vestre wrote:
>
> Seriously, I see your point, but the "so what" depends on whether
> there are viable alternatives or not: I think that as programmers we
> should strive to keep a "craftman's pride". Which includes the usage
> of good tools. If a really good tool disappears from the market, and
> there are only crappy replacements - shouldn't a proud craftsman be
> worried?
The point is that the good tool will only disappear if no one cares any
more. And then, well, so what?
Actually, there's another reason for a good tool to disappear: people
care, but think it's too expensive to use. And then one of the
following is true.
* It is too expensive. Consider Kodachrome: it's a fantastic film
which has properties (durability which I don't care much about, colour
characteristics which I care a lot about), but it requires weird
chemistry which doesn't scale down, and which is (perhaps was) rather
toxic. It will probably vanish in the next year or so. This is a
tragedy but, actually, it really was too expensive. Things that are
too expensive are not good tools in an engineering sense.
* It isn't too expensive but people are economically illiterate. I
refer you to my original post.
(And there are some other reasons: it's known to be good but bad guys
want to suppress it and so on. Lisp isn't suffering from those other
than in some people's deranged imaginations.)
--tim
"Tim Bradshaw" <··········@tfeb.org> writes:
> The point is that the good tool will only disappear if no one cares any
> more. And then, well, so what?
I think I'm concerned with much more general issues of society here:
Good craftmanship is having hard times. And what seems cheap now may
not pay off in the long run. Not only because good craftmanship may
die off (as Rob pointed out), but also because some of the substitutes
(e.g. factory-baked bread) may be quite inferior or even dangerous,
and also because many things that are built today, be it software
(some software systems built today will still be in use in 30 years),
bridges, furniture or houses, will be with us for many years. This is
the age of mass-produced short-lived objects, but we still build
things that are supposed to last, too.
> * It is too expensive. Consider Kodachrome: it's a fantastic film
> which has properties (durability which I don't care much about, colour
> characteristics which I care a lot about),
Yes, but this is a somewhat odd example, since film in general is on
its way to being reduced to a strange speciality product for people
with weird interests. And then of course you can't afford to keep the
products that need that much infrastructure (Btw. I made a lot of
photos with Kodachrome 25 in Himalaya many years ago, but I wish
I had them all as RAW files now - would make it easier to correct
that bluish tint (despite skylight filters) :-))
> (And there are some other reasons: it's known to be good but bad guys
> want to suppress it and so on. Lisp isn't suffering from those other
> than in some people's deranged imaginations.)
No, but I think it's pretty obvious that a lot of large companies
suffer from a kind of stalinist company culture that is quite
oppressive against good craftmanship. Free enterprise hasn't had its
Glasnost yet ;-)
--
(espen)
Espen Vestre wrote:
> I think I'm concerned with much more general issues of society here:
> Good craftmanship is having hard times. And what seems cheap now may
> not pay off in the long run. Not only because good craftmanship may
> die off (as Rob pointed out), but also because some of the substitutes
> (e.g. factory-baked bread) may be quite inferior or even dangerous,
> and also because many things that are built today, be it software
> (some software systems built today will still be in use in 30 years),
> bridges, furniture or houses, will be with us for many years. This is
> the age of mass-produced short-lived objects, but we still build
> things that are supposed to last, too.
I agree with this, but I still claim that the good tool (Lisp here)
will only vanish if either people don't think it's a good tool, or
people (correctly or incorrectly) think it's too expensive. I was just
trying to address the `too expensive' part by pointing out the kind of
mass financial illiteracy that so many people suffer from.
And, just to be contentious (which is kind of my job on usenet): the
craftsmanship thing doesn't depend on Lisp. I've seen *awful* Lisp
programs, and not a few of them. Some of them written by novices, but
a disturbingly large amount written by people who really should have
known better. And I've seen really nicely written Perl, C and Java. I
don't even know if Lisp helps people write good programs in general: I
rather think it doesn't, actually.
[insert long rant about film]
--tim
"Tim Bradshaw" <··········@tfeb.org> writes:
> And, just to be contentious (which is kind of my job on usenet): the
> craftsmanship thing doesn't depend on Lisp.
Sure. The point was just that proud craftsmen dislike inferior tools.
--
(espen)
Espen Vestre wrote:
> Sure. The point was just that proud craftsmen dislike inferior tools.
But good craftsmen, if stuck with inferior tools, do not sit and
complain in a loud voice about how, if only they had better (or,
perhaps, cheaper) tools, they could do wonderful work. They get on and
do the work, probably building superior tools along the way. There's a
saying in there, somewhere.
--tim (no, not you, of course, but others)
Tim Bradshaw wrote:
> Espen Vestre wrote:
>
>
>>Sure. The point was just that proud craftsmen dislike inferior tools.
>
>
> But good craftsmen, if stuck with inferior tools, do not sit and
> complain in a loud voice about how, if only they had better (or,
> perhaps, cheaper) tools, they could do wonderful work. They get on and
> do the work, probably building superior tools along the way. There's a
> saying in there, somewhere.
The good news is yes. The bad news is that it involves Turing equivalence.
:)
kt
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
>>>>> "TB" == Tim Bradshaw <··········@tfeb.org> writes:
TB> But good craftsmen, if stuck with inferior tools, do not sit
TB> and complain in a loud voice about how, if only they had
TB> better (or, perhaps, cheaper) tools, they could do wonderful
TB> work. They get on and do the work, probably building superior
TB> tools along the way. There's a saying in there, somewhere.
My experience is that good craftsmen mutter quite a bit about foolish
restrictions and Greenspun's Tenth Law while building those superior
tools, and if not allowed by management to build tools, eventually
vote with their feet.
Charlton
--
Charlton Wilbur
·······@chromatico.net
On 2006-12-05 22:02:37 +0000, Charlton Wilbur <·······@chromatico.net> said:
> My experience is that good craftsmen mutter quite a bit about foolish
> restrictions and Greenspun's Tenth Law while building those superior
> tools, and if not allowed by management to build tools, eventually
> vote with their feet.
Yeah, I deal with programmers like that all the time. We make them into soap.
Tim Bradshaw <···@tfeb.org> wrote:
+---------------
| Charlton Wilbur <·······@chromatico.net> said:
| > My experience is that good craftsmen mutter quite a bit about foolish
| > restrictions and Greenspun's Tenth Law while building those superior
| > tools, and if not allowed by management to build tools, eventually
| > vote with their feet.
|
| Yeah, I deal with programmers like that all the time.
| We make them into soap.
+---------------
I almost snorted my beverage onto my keyboard, since I initially
misread that last sentence as: "We make them use SOAP." ;-]
[Though maybe those two aren't *that* different...] ;-}
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
"Tim Bradshaw" <··········@tfeb.org> writes:
> But good craftsmen, if stuck with inferior tools, do not sit and
> complain in a loud voice about how, if only they had better (or,
> perhaps, cheaper) tools, they could do wonderful work. They get on and
> do the work, probably building superior tools along the way.
Of course they will, but they will end up with only halfway usable
tools, because they don't have the high-precision tools you need to
craft real tools...
--
(espen)
On 2006-12-05 18:55:48 +0000, Espen Vestre <·····@vestre.net> said:
> Of course they will, but they will end up with only halfway usable
> tools, because they don't have the high-precision tools you need to
> craft real tools...
You know, those high-precision tools were built starting by chipping
bits off rocks.
(Now you're going to respond by saying `yes, but it took thousands of
years'. Tragically I will have already dispatched the nukes by then.)
Tim Bradshaw wrote:
> On 2006-12-05 18:55:48 +0000, Espen Vestre <·····@vestre.net> said:
>
>> Of course they will, but they will end up with only halfway usable
>> tools, because they don't have the high-precision tools you need to
>> craft real tools...
>
>
> You know, those high-precision tools were built starting by chipping
> bits off rocks.
>
> (Now you're going to respond by saying `yes, but it took thousands of
> years'. Tragically I will have already dispatched the nukes by then.)
>
You were only showing initiative*.
kt
* http://www.tigersweat.com/movies/strange/slove12.wav
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
>>>>> "TB" == Tim Bradshaw <··········@tfeb.org> writes:
[...]
TB> ... I don't
TB> even know if Lisp helps people write good programs in general:
TB> I rather think it doesn't, actually.
Why do you think this? Actually, I am not sure I understand what you
mean. I would agree with you on a weaker assertion: that lisp is
powerful and unconstrained enough that it doesn't hinder the
production of working but outrageously badly written and inefficient
programs. Still, could we have a clarification?
cheers,
BM
Bulent Murtezaoglu wrote:
> Why do you think this? Actually, I am not sure I understand what you
> mean. I would agree with you on a weaker assertion: that lisp is
> powerful and unconstrained enough that it doesn't hinder the
> production of working but outrageously badly written and inefficient
> programs. Still, could we have a clarification?
Pretty much that's what I meant. I guess these are two sides of the
same coin. Lisp allows outrageously bad programs to run (as do many
modern languages: GC & related things are mostly the reason - a lot of
the `Java is slow' mythology is actually `Java allows outrageously bad
programs to run, too'), and empirically people do seem to write such
programs, given the chance (and not just naive programmers).
--tim
Espen Vestre wrote:
> I think that as programmers we should strive to keep a "craftman's pride".
I used to think so too, but then I realized I suck. Was hard to keep
the pride thing going after that.
--
-asbjxrn
>>>>> "AB" == Asbj�rn Bj�rnstad <·······@gmail.com> writes:
AB> Espen Vestre wrote:
>> I think that as programmers we should strive to keep a
>> "craftman's pride".
AB> I used to think so too, but then I realized I suck. Was hard
AB> to keep the pride thing going after that.
I try to keep a craftsman's pride, but when it means fighting the
people who sign my paychecks, it's difficult. You can't build
anything but crap when your tools are crap and you aren't allowed to
choose better tools or build new ones.
So I build crap with crap at work, and save my free time for other, at
this point almost completely non-technical, pursuits.
Charlton
--
Charlton Wilbur
·······@chromatico.net
Espen Vestre <·····@vestre.net> wrote:
+---------------
| "Tim Bradshaw" <··········@tfeb.org> writes:
| > * There's no God-given right for *Lisp* to survive. If it dies it
| > dies, and so what. If it dies `because' people spent time on OSS
| > implementations or something, then so what. ...
...
| ... I think that as programmers we should strive to keep a
| "craftman's pride". Which includes the usage of good tools.
| If a really good tool disappears from the market, and there are
| only crappy replacements - shouldn't a proud craftsman be worried?
+---------------
Given how wide-spread the Lisp meme is at this point, it isn't
very likely that Lisp will disappear as long as its advocate
craftsmen are still alive. What is possibly more likely is that
all the serious Lisp users & implementors die off without passing
on the meme. Said another way, it is not enough to be craftsmen
with pride in the great tools we use -- we must be spokesmen
and mentors on behalf of those tools for the next generation
of craftsmen... if there are to be any.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Ken Tilton wrote:
> Fortunately civilization had made a little headway before Marx and
> Stallman came up with that one.
Hey, isn't there some kind of corollary to Godwin's law as regards
mentioning Karl Marx. If not, can we at least pretend that there is?
On 4842 September 1993, Ken Tilton wrote:
> Kenzo: "Dudes, it's been twenty-five years, prices down at Throg's
> Wheel & Axle aren't all that bad. Why not work on a mast and sail?"
> Answer: "We will never use anything we have to pay for."
This analogy is, like any other as has been said before by definition,
misleading at best. CL implementations are quite more complicated and
much more *interesting* things than axes. I guess it would be more
correct to attribute the motivation to the NIH syndrome.
> As for: "Oh, golly, I just /live/ for compiler work."... Sure, true in
> rare cases, universally claimed when some Wet Blanket(tm) points out
> the implicit cost of all the work they did to avoid cost.
I think most people start working on some technology by using it and
wanting extensions nobody else is willing to build. I'm fairly certain
that a lot of motivation for writing such extensions for free software
comes directly from some felt moral obligation to pay back. I would be
surprised to learn that SBCL is an exception, after all it's build on
CMUCL. One might argue that SBCLs major achievement is keeping CMUCL
or at least its underlying technology from becoming irrelevant.
And looking under the hood of a full-fledged lisp implementation is
probably interesting in itself.
Holger
--
--- http://hillview.bugwriter.net/ ---
Fachbegriffe der Informatik - Einfach erkl�rt
28: ... werden wir den Schutz Minderj�hriger in den Vordergrund stellen.
Im Grunde wei� ich genausowenig �ber die ganze Sache wie meine
W�hler, aber verbieten bringt mehr Stimmen. (Peter Berlich)
Ken Tilton <·········@gmail.com> writes:
> As for: "Oh, golly, I just /live/ for compiler work."... Sure, true in
> rare cases, universally claimed when some Wet Blanket(tm) points out
> the implicit cost of all the work they did to avoid cost.
You are not wrong. But what is Lisp's actual competition? Python?
Ruby? Java? There are other languages that are also obtainable for
about the same cost as SBCL for doing a lot of the same jobs.
When some bioinformatics company considers Franz, it is probably also
looking at Sun or Python (who pays to develope Python?) or whatever.
That company might see that there are 100* Python developers for each
Lisp developer and not even consider Lisp at that point.
* yet another made up statistic
--
This post uses 100% post consumer electrons and 100% virgin photons.
At 2.6 miles per minute, you don't really have time to get bored.
--- Pete Roehling on rec.motorcycles
I bump into a lot of veteran riders in my travels.
--- David Hough: Proficient Motorcycling
David Steuber wrote:
> Ken Tilton <·········@gmail.com> writes:
>
>
>>As for: "Oh, golly, I just /live/ for compiler work."... Sure, true in
>>rare cases, universally claimed when some Wet Blanket(tm) points out
>>the implicit cost of all the work they did to avoid cost.
>
>
> You are not wrong. But what is Lisp's actual competition? Python?
> Ruby? Java? There are other languages that are also obtainable for
> about the same cost as SBCL for doing a lot of the same jobs.
>
> When some bioinformatics company considers Franz, it is probably also
> looking at Sun or Python (who pays to develope Python?) or whatever.
> That company might see that there are 100* Python developers for each
> Lisp developer and not even consider Lisp at that point.
You forget, Python is the same as Lisp* and Ruby is aka MatzLisp, so all
those Python and Ruby programmers can also program Lisp.
kt
* http://norvig.com/python-lisp.html
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
"""Ken Tilton �����(�):
"""
> If they were working on cffi-grovel or a truly excellent cl-sockets or
> even Ltk or Cells-Gtk, Lisp would have a larger customer base and Franz
> and LW could try different prices. And every Lispnik would be more
> productive (that has to do with the cost of doing business, you know).
Everybody thinks their front is most important. For me, SBCL was road
to loving Lisp - I could not afford nor LW nor ACL at that time and
their free offerings were limited (esp. sudden exits and no prefs).
So, I doubt that shifting to libraries development will yield more
newbs coming. Esp. that 'larger customer base' as a result is
suspicious (without SBCL development).
·······@mail.wplus.net wrote:
> """Ken Tilton �����(�):
> """
>
>>If they were working on cffi-grovel or a truly excellent cl-sockets or
>>even Ltk or Cells-Gtk, Lisp would have a larger customer base and Franz
>>and LW could try different prices. And every Lispnik would be more
>>productive (that has to do with the cost of doing business, you know).
>
>
> Everybody thinks their front is most important. For me, SBCL was road
> to loving Lisp - I could not afford nor LW nor ACL at that time and
> their free offerings were limited (esp. sudden exits and no prefs).
>
> So, I doubt that shifting to libraries development will yield more
> newbs coming.
Trolls complain about the parentheses, serious outsider critics complain
about the libraries. Is that in dispute?
> Esp. that 'larger customer base' as a result is
> suspicious (without SBCL development).
>
What is wrong with CLisp? Runs everywhere, unlike SBCL, and has done for
years.
kt
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
On Mon, 04 Dec 2006 11:47:45 -0500, Ken Tilton <·········@gmail.com> tried to
confuse everyone with this message:
>What is wrong with CLisp? Runs everywhere, unlike SBCL, and has done for
>years.
>
Restrictive license?
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
Timofei Shatrov wrote:
> On Mon, 04 Dec 2006 11:47:45 -0500, Ken Tilton <·········@gmail.com> tried to
> confuse everyone with this message:
>
>
>>What is wrong with CLisp? Runs everywhere, unlike SBCL, and has done for
>>years.
>>
>
>
> Restrictive license?
>
Not to use it.*
kt
* They had some language about 'if you use mechanism XXX our GPL infects
you', but when I asked they said they were going to clarify that not to
include FFI and the MOP stuff, which had seemed compromised. The things
still infectious seemed to be no harder to avoid than Franz's
proprietary stuff. If you want CL, the CL use is unencumbered.
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton <·········@gmail.com> writes:
>
> What is wrong with CLisp? Runs everywhere, unlike SBCL, and has done
> for years.
My problem is that it's not compiled to machine code--that's the first
thing I look for in a new language; while I use several
languages/implementations which don't do it (e.g. Python--and yes, there
are workarounds in that case). I much prefer an implementation.
Honestly, nowadays it's really more superstition than anything else, but
it is what it is.
--
Robert Uhl <http://public.xdi.org/=ruhl>
I have a love for coding. I have a love for staying up for days at a
time living off of Tea and Cigarettes, doing nothing but wearing the
letters off of the keys in front of my computer. My bills have a love
for being paid on time. --Jace of Fuse!
Robert Uhl wrote:
> Ken Tilton <·········@gmail.com> writes:
>
>>What is wrong with CLisp? Runs everywhere, unlike SBCL, and has done
>>for years.
>
>
> My problem is that it's not compiled to machine code--that's the first
> thing I look for in a new language; while I use several
> languages/implementations which don't do it (e.g. Python--and yes, there
> are workarounds in that case). I much prefer an implementation.
> Honestly, nowadays it's really more superstition than anything else, but
> it is what it is.
Well, yes. You never tried CLisp and ascertained it was too slow to beat
Deep Blue or anything. We build our own prisons.
kt
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton <·········@gmail.com> writes:
>
> Well, yes. You never tried CLisp and ascertained it was too slow to
> beat Deep Blue or anything. We build our own prisons.
Actually, clisp was the first CL implementation I used. At the time I
was trying to decide between playing with CL or playing with Scheme
(specifically Guile); the docs for Guile were better and so I went off
to that.
More recently, I tried using clisp for some real work (at work, even);
there were some issues with SLIME, and then I had trouble with CLSQL.
Eventually I was able to fix the reasons I wasn't using SBCL in the
first place, and went back to it.
Clisp is a nice implementation--and I admitted that my major reason for
avoiding it is superstition mostly.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Fight to your last cartridge, then fight with your bayonets.
No surrender. Fight to the death.
--Gen. Henri Guisan, Switzerland, July '40
Robert Uhl wrote:
> Ken Tilton <·········@gmail.com> writes:
> >
> > Well, yes. You never tried CLisp and ascertained it was too slow to
> > beat Deep Blue or anything. We build our own prisons.
>
> Actually, clisp was the first CL implementation I used. At the time I
We can conclude that Kenny finds something seriously wrong with CLisp
for him to be pimping it so much, and at the same time getting his
panties in a bunch over SBCL.
············@gmail.com wrote:
> Robert Uhl wrote:
>
>>Ken Tilton <·········@gmail.com> writes:
>>
>>>Well, yes. You never tried CLisp and ascertained it was too slow to
>>>beat Deep Blue or anything. We build our own prisons.
>>
>>Actually, clisp was the first CL implementation I used. At the time I
>
>
> We can conclude that Kenny finds something seriously wrong with CLisp
> for him to be pimping it so much, and at the same time getting his
> panties in a bunch over SBCL.
>
Holy sh*t! "Create filter from message..."! Hellasweet.
kzo
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
> ············@gmail.com wrote:
> > Robert Uhl wrote:
> >
> >>Ken Tilton <·········@gmail.com> writes:
> >>
> >>>Well, yes. You never tried CLisp and ascertained it was too slow to
> >>>beat Deep Blue or anything. We build our own prisons.
> >>
> >>Actually, clisp was the first CL implementation I used. At the time I
> >
> >
> > We can conclude that Kenny finds something seriously wrong with CLisp
> > for him to be pimping it so much, and at the same time getting his
> > panties in a bunch over SBCL.
> >
>
> Holy sh*t! "Create filter from message..."! Hellasweet.
>
Kenny, over there, a flying monkey!
Robert Uhl wrote:
> My problem is that it's not compiled to machine code--that's the first
> thing I look for in a new language; while I use several
> languages/implementations which don't do it (e.g. Python--and yes, there
> are workarounds in that case). I much prefer an implementation.
> Honestly, nowadays it's really more superstition than anything else, but
> it is what it is.
Do you use x86 systems? You realise that the whole x86 instruction set
is basically emulated by the hardware, right? You might as well refuse
to use implementations that don't have compilers which generate
silicon.
--tim
On Tue, 05 Dec 2006 13:25:47 +0100, Tim Bradshaw <··········@tfeb.org>
wrote:
> Robert Uhl wrote:
>
>> My problem is that it's not compiled to machine code--that's the first
>> thing I look for in a new language; while I use several
>> languages/implementations which don't do it (e.g. Python--and yes, there
>> are workarounds in that case). I much prefer an implementation.
>> Honestly, nowadays it's really more superstition than anything else, but
>> it is what it is.
>
> Do you use x86 systems? You realise that the whole x86 instruction set
> is basically emulated by the hardware, right? You might as well refuse
> to use implementations that don't have compilers which generate
> silicon.
>
> --tim
>
That is a gross over-simplification and you know it.
Compilers themselves use a subset of the x86 instruction
that are optimized by the processor. Much of the emulated
instructions (rep scansb, say) are there for backward
compatabillity. Performance is more a function of
filling the pipelines, utilizing all ALU's and
optimizing cashe use.
Let's look at the stats for testing ACL2 in Unix
(from http://www.cs.utexas.edu/users/moore/acl2/v3-1/new.html)
GCL 11728 s user time
SBCL 19754 s user time
ACL 22868 s user time
CLisp 83010 s user time
Which system would you run the theorem prover on?
I use Lisp primarly to find and test algorithms.
Obviously speed matters (some times)
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
John Thingstad schrieb:
> On Tue, 05 Dec 2006 13:25:47 +0100, Tim Bradshaw <··········@tfeb.org>
> wrote:
>
> > Robert Uhl wrote:
> >
> >> My problem is that it's not compiled to machine code--that's the first
> >> thing I look for in a new language; while I use several
> >> languages/implementations which don't do it (e.g. Python--and yes, there
> >> are workarounds in that case). I much prefer an implementation.
> >> Honestly, nowadays it's really more superstition than anything else, but
> >> it is what it is.
> >
> > Do you use x86 systems? You realise that the whole x86 instruction set
> > is basically emulated by the hardware, right? You might as well refuse
> > to use implementations that don't have compilers which generate
> > silicon.
> >
> > --tim
> >
>
> That is a gross over-simplification and you know it.
> Compilers themselves use a subset of the x86 instruction
> that are optimized by the processor. Much of the emulated
> instructions (rep scansb, say) are there for backward
> compatabillity. Performance is more a function of
> filling the pipelines, utilizing all ALU's and
> optimizing cashe use.
>
> Let's look at the stats for testing ACL2 in Unix
> (from http://www.cs.utexas.edu/users/moore/acl2/v3-1/new.html)
> GCL 11728 s user time
> SBCL 19754 s user time
> ACL 22868 s user time
> CLisp 83010 s user time
> Which system would you run the theorem prover on?
Let's guess, the code has been optimized for GCL mostly.
Put a bit effort into some optimizations for ACL/SBCL/LW and
GCL should have no chance...
>
> I use Lisp primarly to find and test algorithms.
> Obviously speed matters (some times)
>
> --
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
On 2006-12-05 19:28:04 +0000, "John Thingstad" <··············@chello.no> said:
> That is a gross over-simplification and you know it.
It is an oversimplification, but not as much of one as you might think.
> Performance is more a function of
> filling the pipelines, utilizing all ALU's and
> optimizing cashe use.
Why yes, it is (though I'd say `optimizing memory use' which may be
different than optimizing the cache in many cases). In particular it's
*not* a function of having some nebulous `native code compiler'.
>
> Let's look at the stats for testing ACL2 in Unix
> (from http://www.cs.utexas.edu/users/moore/acl2/v3-1/new.html)
> GCL 11728 s user time
> SBCL 19754 s user time
> ACL 22868 s user time
> CLisp 83010 s user time
> Which system would you run the theorem prover on?
Well, all things being equal, the fastest one. Which in this case has
a notoriously awful compiler (and not really a native-code one, since
it uses gcc as the back end, or did).
But note: the fastest one, not `the one with the native code compiler'.
--tim
On Wed, 06 Dec 2006 01:09:25 +0100, Tim Bradshaw <···@tfeb.org> wrote:
>
> Well, all things being equal, the fastest one. Which in this case has a
> notoriously awful compiler (and not really a native-code one, since it
> uses gcc as the back end, or did).
Agreed it is pretty bad. The ACL2 code only uses CLTL1 (when compileing
for GCL)
and needs a older compiler that dosn't try to reach ANSI compliance to run.
Overall SBCL is probaly a better overall choice.
>
> But note: the fastest one, not `the one with the native code compiler'.
>
> --tim
>
And what do you think gcc compiles the code to? :)
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
John Thingstad wrote:
> And what do you think gcc compiles the code to? :)
You know, the point I was trying to make was that *I don't care*. I use
the tool that is appropriate to the job. If the job is some kind of HPC
thing that may mean the fastest one, and that may *but may not* mean
the one with the native-code compiler - it might, for instance mean the
one that can efficiently support enough threads to keep the HW busy, or
which has I/O APIs which map well onto the I/O system of the host (you
can tell I'm hinting at Java on Niagara-style boxes here, or may be
Azul-type systems). But a large majority of jobs are not, actually,
CPU bound, and quite a lot are not even I/O bound. For those, I'd use
some other tool which had features more suitable to the job at hand.
For my main job of making programmers into soap, I use a soap-making
machine.
Ken Tilton wrote:
[...]
> > Esp. that 'larger customer base' as a result is
> > suspicious (without SBCL development).
> What is wrong with CLisp? Runs everywhere, unlike SBCL, and has done for
> years.
Slow floating point, as mentioned in the FAQ on its website. For me,
Win32 compatibility is a non-issue (everyone I work with uses Linux or
a Mac), but fast floating point math is a major requirement.
Cheers,
Pillsy
·······@mail.wplus.net wrote:
> """Ken Tilton �����(�):
> """
>
>>If they were working on cffi-grovel or a truly excellent cl-sockets or
>>even Ltk or Cells-Gtk, Lisp would have a larger customer base and Franz
>>and LW could try different prices. And every Lispnik would be more
>>productive (that has to do with the cost of doing business, you know).
>
>
> Everybody thinks their front is most important.
Is that wishy-washy, feel-good, shiny happy moral relativism I see
rearing its non-committal, all-embracing, no-wrong-answers head? :)
Sure, I once knew a mainframe systems programmer who thought installing
the operating system and getting it to work was the only thing that
mattered. Had complete disdain for application programmers. I am sure he
secretly resented having actually to run applications.
I doubt this is what afflicts the SBCL developers. I imagine what
afflicts them is the same thing that has people slaving over Linux, a
sorry product compared with OS X. It's free! I don't pay for software!
Yes, with the mainframe guy they never think about doing interesting
things with their computers or with Common Lisp, but he started in
systems and knew nothing else. I think they just got sucked into a black
hole of maintenance and forgot why they got computers or adopted Lisp in
the first place.
My front must be the most important: I really am just a simple
application programmer. An application programmer hoping to develop a
popular application wants to cover windows, os x, and probably someday
linux, should that market ever move outside the masochism SIG. That
means portable GUIs and portable libraries, most likely via portable FFI
to C/C++ libraries.
CL has CFFI because this poster proposed such a thing for Google SoC
2005, and Luis Oliveira did a great job extending James Bielman's great
CFFI. What took so long? Apparently Kenny is the first real application
programmer Lisp has seen in a while. Why does CL now have two portable
GUIs driven by a constraints engine? An application programmer needed
portable GUIs with terrific dynamism and complexity. Why does CL (and
now Python) have a real-world constraints engine after forty years of
on-again off-again discoveries of the paradigm? Because instead of some
super-smart MIT Guy just satisfying a PhD requirement, a
not-all-that-bright applications guy needed dataflow for an actual
application he was writing.
The one thng we know for sure about Pythonistas is that they are not
very good programmers. They are just trying to write applications.
Lispniks think they should see a gold mine when they look at CL, but
they are not looking for a great language, they are looking for a great
way to build applications.
Great news! Pythos, we just got to 1.0 on the compiler! Big party
tonight! Woo-hoo!... wtf?
kzo
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
>
> I doubt this is what afflicts the SBCL developers. I imagine what
> afflicts them is the same thing that has people slaving over Linux, a
> sorry product compared with OS X. It's free! I don't pay for software!
You've already done a good job misrepresenting Stallman, so I suppose
it's the Linux developers' turn. Had Linus Torvalds been given a copy
of SCO Unix, would there be a Linux? Perhaps Linus would have been
happy not bothering (although I doubt it, given the likely hardware
restrictions of the average proprietary Unix of the day), but there'd
be others out there working on something similar, not to mention the
very products that provide OS X with its foundation.
And why does IBM, who has plenty of Unix offerings, develop and thus
pay for Linux? Fortunately, there seem to be people in the Lisp
community since Stallman's "epiphany" who can figure that answer out
for themselves.
[...]
> The one thng we know for sure about Pythonistas is that they are not
> very good programmers. They are just trying to write applications.
And doing pretty well at it, too, as it happens. Perhaps that Python
thing really gives the Midas treatment to those mediocre hordes, eh?
But why aren't all these people writing programs in Lisp? There are a
few places in this thread, mostly where you've been the author, where
three lines are quite enough to explain the mindshare deficit to the
alert reader - quite an achievement given that Paul Graham struggles to
articulate the very same thing in each 200-line essay of his on the
subject.
Paul
Paul Boddie wrote:
> Ken Tilton wrote:
>
>>I doubt this is what afflicts the SBCL developers. I imagine what
>>afflicts them is the same thing that has people slaving over Linux, a
>>sorry product compared with OS X. It's free! I don't pay for software!
>
>
> You've already done a good job misrepresenting Stallman,
Hey, I read the manifesto and understood it, forgive me. Did you find it
hard to understand? I see from the rest you find it hard to think.
>... so I suppose
> it's the Linux developers' turn. Had Linus Torvalds been given a copy
> of SCO Unix, would there be a Linux? Perhaps Linus would have been
> happy not bothering (although I doubt it, given the likely hardware
> restrictions of the average proprietary Unix of the day), but there'd
> be others out there working on something similar, not to mention the
> very products that provide OS X with its foundation.
Rather misses the point (pay $$$, get OS X, stop fussing over getting
your computer even to work). I see a lot of that around here. Missing
the point completely, I mean. Try to stay on topic, people, will you?
Thx. :)
>
> And why does IBM, who has plenty of Unix offerings, develop and thus
> pay for Linux?
Because they suck at software and always have? Was this supposed to be a
point?
> Fortunately, there seem to be people in the Lisp
> community since Stallman's "epiphany" who can figure that answer out
> for themselves.
>
> [...]
>
>
>>The one thng we know for sure about Pythonistas is that they are not
>>very good programmers. They are just trying to write applications.
>
>
> And doing pretty well at it, too, as it happens. Perhaps that Python
> thing really gives the Midas treatment to those mediocre hordes, eh?
Well, duhhhh, that was my point. They are writing really simple, crappy
apps that work just well enough to do their science, using libraries for
the hairy huge bits no one should be reinventing from scratch. They have
no need for the expressive power of Lisp, they open a file, print a
report or massage some numbers, exit and thanks for all the fish.
Lisp takes over when they can write the same crappy programs in Lisp,
because all the same libraries are there. Too easy?
> But why aren't all these people writing programs in Lisp? There are a
> few places in this thread, mostly where you've been the author, where
> three lines are quite enough to explain the mindshare deficit to the
> alert reader - quite an achievement given that Paul Graham struggles to
> articulate the very same thing in each 200-line essay of his on the
> subject.
What a lovely, dramatic, deep bit of prose. Seems also to contain some
intended point. Wonder what it was. I am just hoping it was not that
stupidity about me being the reason no one is using Lisp. It always
makes me feel so bad when morons say that. PWUAUAHHAHAHA. Someone start
a Roadblock to Lisp Survey*, can't wait to see my name in lights. :)
kt
* Here, I'll help:
When did you first try Lisp seriously, which Lisp family member was it,
and what asshole on comp.lang.lisp first made you cry?
What led you to try Lisp, and what did you say that pissed off the
asshole on comp.lang.lisp?
What other languages have you been using most that do not have assholes
in their newsgroups?
How far did you get in your study of Lisp, and how big of an asshole was
the asshole on comp.lang.lisp? I know this is hard to quantify.
What did you think of Lisp up until the moment the asshole made you cry?
I slay myself. :) k
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
> Paul Boddie wrote:
> > Ken Tilton wrote:
> >
> >>I doubt this is what afflicts the SBCL developers. I imagine what
> >>afflicts them is the same thing that has people slaving over Linux, a
> >>sorry product compared with OS X. It's free! I don't pay for software!
> >
> > You've already done a good job misrepresenting Stallman,
>
> Hey, I read the manifesto and understood it, forgive me. Did you find it
> hard to understand? I see from the rest you find it hard to think.
Nope, the manifesto was quite clear to me, thanks. Given that you're
continuously intent on portraying Free Software developers as people
who just want to spend zero dollars on other people's software (which
my later example convincingly demolishes), and taking you on your word
that the manifesto has sunk in, I can only conclude that you're
comfortable filling a seat in the peanut gallery.
> > Had Linus Torvalds been given a copy
> > of SCO Unix, would there be a Linux? Perhaps Linus would have been
> > happy not bothering (although I doubt it, given the likely hardware
> > restrictions of the average proprietary Unix of the day), but there'd
> > be others out there working on something similar, not to mention the
> > very products that provide OS X with its foundation.
>
> Rather misses the point (pay $$$, get OS X, stop fussing over getting
> your computer even to work).
The point (why SBCL developers bothered) is not confined to money, or
is everything about money with you? Besides, I had no problems getting
my computer to work, thank you. Just as Apple cherry-pick their
hardware, thus avoiding all those driver issues people complain about
(yet more lessons about open systems and interoperability there if
you're interested, but I guess you aren't), I selected a system which
works very well with my operating system. It was quite a bit cheaper
than Apple hardware, too, I might add.
> I see a lot of that around here. Missing the point completely, I mean.
There's certainly a disconnect, but you should know what that means
when you're the one seeing it all the time.
> Try to stay on topic, people, will you?
> Thx. :)
The point was that even if Torvalds had the right hardware and had a
licence for SCO Unix, he may have wanted to experiment for himself,
write his own software, or whatever - a number of things completely
unrelated to money, unless your recommendation is to always hire a
bunch of people in when wanting to customise or create software, even
though you may want to learn more about software yourself. So, what
should Linus have done? After doing Lisp consulting while in high
school, becoming filthy rich (naturally), Linus puts out a tender to
major operating systems vendors: "please develop or customise your
operating systems offerings allowing me to read and fetch news in
multiple threads".
> > And why does IBM, who has plenty of Unix offerings, develop and thus
> > pay for Linux?
>
> Because they suck at software and always have? Was this supposed to be a
> point?
Yes, it was about paying for Free Software and the motives businesses
have. They've certainly done alright as a business given that they
"suck at software", though. (Obligatory "worse is better" reference
might be appropriate here.)
[Python programmers writing applications]
> > And doing pretty well at it, too, as it happens. Perhaps that Python
> > thing really gives the Midas treatment to those mediocre hordes, eh?
>
> Well, duhhhh, that was my point. They are writing really simple, crappy
> apps that work just well enough to do their science, using libraries for
> the hairy huge bits no one should be reinventing from scratch. They have
> no need for the expressive power of Lisp, they open a file, print a
> report or massage some numbers, exit and thanks for all the fish.
And if programmers wrote the easy stuff in Lisp, we'd all be using Lisp
applications, right? Why isn't that happening?
> Lisp takes over when they can write the same crappy programs in Lisp,
> because all the same libraries are there. Too easy?
And has it taken over? Does the lovely Mac OS X employ Lisp
extensively? Are all the Mac OS X developers using Lisp to write their
applications?
> > But why aren't all these people writing programs in Lisp? There are a
> > few places in this thread, mostly where you've been the author, where
> > three lines are quite enough to explain the mindshare deficit to the
> > alert reader - quite an achievement given that Paul Graham struggles to
> > articulate the very same thing in each 200-line essay of his on the
> > subject.
>
> What a lovely, dramatic, deep bit of prose. Seems also to contain some
> intended point. Wonder what it was.
I thought you might.
> I am just hoping it was not that stupidity about me being the reason no one is using Lisp. It
> always makes me feel so bad when morons say that. PWUAUAHHAHAHA. Someone start
> a Roadblock to Lisp Survey*, can't wait to see my name in lights. :)
Well, if you want to take it personally, be my guest, although I notice
that despite antipathy towards individuals in various communities (and
I honestly don't know whether you have that kind of reputation) most
communities just route around them and get on with it. However, whether
you explicitly intend to articulate the roadblocks to Lisp or whether
the message just slips out, you've provided some pretty useful insights
whether you wanted to or not.
Since you've taken this as some kind of personal criticism when it
wasn't actually meant as such, I'll skip your absurd questionnaire and
provide some material:
"What a charming way to expend the intellectual horsepower of all
those young turks, destroying markets for Lisp developers. Franz and
LW /are/ our brothers/sisters, right?" [1]
Now, given that the SBCL developers clearly don't share your
perspectives (according to you), try and put yourself in their position
and attempt to answer your concluding question. Consider also
perceptions of market destruction or growth from their position and,
crucially, from people shopping around for a programming language. If
you find it hard to put yourself in the position of the SBCL people,
consider taking Stallman's position - his actual position that is, not
your deliberately erroneous trivialisation of his position.
Paul
[1] http://groups.google.com/group/comp.lang.lisp/msg/ab0667dd5df99bfb
Paul Boddie wrote:
> And why does IBM, who has plenty of Unix offerings, develop and thus
> pay for Linux? Fortunately, there seem to be people in the Lisp
> community since Stallman's "epiphany" who can figure that answer out
> for themselves.
Because all their Unix offerings suck, really badly. At the time their
options were to make them suck less (probably a huge amount of work,
would also break them for existing customers), to license Solaris
(politically very bad then and now, probably expensive then), or to use
a free Unix(-clone) not attached to any vendor. Which is actually
really only one option, really.
Tim Bradshaw wrote:
> Paul Boddie wrote:
>
> > And why does IBM, who has plenty of Unix offerings, develop and thus
> > pay for Linux? Fortunately, there seem to be people in the Lisp
> > community since Stallman's "epiphany" who can figure that answer out
> > for themselves.
>
> Because all their Unix offerings suck, really badly.
All of them?! I know everyone lays into AIX usually on the grounds of
usability, but haven't they also picked up some moderately decent Unix
systems through acquisitions over the years. I'm not necessarily
disagreeing with you, though.
> At the time their options were to make them suck less (probably a huge amount of work,
> would also break them for existing customers), to license Solaris
> (politically very bad then and now, probably expensive then), or to use
> a free Unix(-clone) not attached to any vendor. Which is actually
> really only one option, really.
And the big question (rhetorically posed) is, despite a history of free
Unix-like systems, why is only one of them an option? Why didn't IBM
and others take one of the BSDs on board?
Paul
Paul Boddie wrote:
> All of them?! I know everyone lays into AIX usually on the grounds of
> usability, but haven't they also picked up some moderately decent Unix
> systems through acquisitions over the years. I'm not necessarily
> disagreeing with you, though.
I'm not aware of any IBM-native Unix offerings which don't suck,
anyway. (maybe there were some, but they probably had maintenance
issues etc).
> And the big question (rhetorically posed) is, despite a history of free
> Unix-like systems, why is only one of them an option? Why didn't IBM
> and others take one of the BSDs on board?
Well, they did! OSX for instance: I don't know the detailed history of
what came from where, but it's a BSD not a Linux, clearly.
Various other people took BSDs, I think typically for licensing reasons
(easier to embed seriously proprietary stuff in the kernel): there are
a number of appliance-type systems which I've seen (load balancers etc)
which have been BSD based. Are Netapps BSD? I forget, if I ever knew.
There are lots of reasons for a big-name vendor to pick Linux though:
the kernel may be in a better state as regards scalability and device
support; and, critically, it has name recognition: `IBM use Linux,
cool, let's buy IBM kit because we'll be supporting Linux'.
What you can be reasonably sure of is that they did not pick Linux out
of the goodness of their hearts. This is the company that `Big Blue'
was written about, remember?
--tim
Tim Bradshaw wrote:
> Paul Boddie wrote:
> > And the big question (rhetorically posed) is, despite a history of free
> > Unix-like systems, why is only one of them an option? Why didn't IBM
> > and others take one of the BSDs on board?
>
> Well, they did! OSX for instance: I don't know the detailed history of
> what came from where, but it's a BSD not a Linux, clearly.
I was avoiding mentioning OS X because the reasons for adopting BSD
technologies are quite different from those of companies who have
adopted Linux. IBM could have chosen one of the BSDs, but they didn't,
yet any serious possibility of them having done so would have given
them more than the one option you mentioned. So I suppose we're in some
kind of agreement.
[...]
> There are lots of reasons for a big-name vendor to pick Linux though:
> the kernel may be in a better state as regards scalability and device
> support; and, critically, it has name recognition: `IBM use Linux,
> cool, let's buy IBM kit because we'll be supporting Linux'.
Yes, but was that all really true when IBM made the decision to use
Linux? One can argue that the reason why things like scalability and
device support exist for Linux where the BSDs (for example) are lacking
is because other big-name vendors have contributed much of the work.
The enabling underlying feature of Linux isn't the technology or the
cost: it's the licensing.
> What you can be reasonably sure of is that they did not pick Linux out
> of the goodness of their hearts. This is the company that `Big Blue'
> was written about, remember?
Yes, it's just business, but where the decision makers aren't saying
"we're not touching this free stuff, let's just buy SCO outright
instead" - a critical point when discussing why anyone would spend
their time and/or money on certain other Free Software endeavours.
Paul
On 2006-12-05 13:46:11 +0000, "Paul Boddie" <····@boddie.org.uk> said:
> Yes, but was that all really true when IBM made the decision to use
> Linux?
Yes, I think it probably was. One of the reasons for Sun to move to a
new system in <whenever they made the decision, 1990?> was that the BSD
kernel That they used then was an unsupportable mess (largely due to
the stuff they'd rammed into it, probably) and they could see that it
would be a serious pain to make it scale etc. It's a lot better now,
obviously.
As for name recognition, well people were looking at me funnily when I
suggested we use a free BSD instead of Linux in 1992. The reason we
*did* use Linux is because of better device support, also in 1992 of
course.
So, well, may be their decision predated 1992.
--tim
>>>>> "PB" == Paul Boddie <····@boddie.org.uk> writes:
PB> And the big question (rhetorically posed) is, despite a
PB> history of free Unix-like systems, why is only one of them an
PB> option? Why didn't IBM and others take one of the BSDs on
PB> board?
Because IBM was not interested in selling software; they were
interested in selling consulting services to people with big budgets,
lots of glossy magazines, and no idea what to do next. Among that
crowd, Linux has a certain amount of name recognition; it's the thing
the young turks are using to earn all those ridiculous new social web
economy 2.0 XML profits[1], and it has something to do with Google, which
has the sort of stock price and P/E ratio that makes MBAs drool. BSD
is either a drug or an odd sex practice if you're lucky -- if you're
unlucky the vice president will have heard of BSD in the context of
the intellectual property dispute with AT&T.
There might be something tangled up with the license, too -- it's damn
near impossible to re-sell something that has been released under the
GPL, but it's very easy to do that with the BSD license. I can see
that being a major attraction for IBM, in that any improvements they
make to Linux are fair game for the Linux world at large, but their
competitors can't effectively patch, repackage, and re-sell the code.
Charlton
[1] This may sound like satire. It isn't. I have been told by a vice
president before that Ruby on Rails -- the best technology for the
project that needed to be done, since it was mostly a web front-end to
a database, the sort of thing Kenny makes fun of Python for being good
at -- could not be considered for a web project because the name was
too silly and not businesslike enough. And I've also, at another very
corporate workplace, submitted a project proposal that was rejected; I
changed it to specify that it used XML as a data transfer format,
changing nothing else about the proposal, and I had vice presidents
enthusiastically recommending it.
--
Charlton Wilbur
·······@chromatico.net
> My front must be the most important: I really am just a simple
> application programmer.
OK, maybe you have a point. Customer-driven, eh? I use lisp because
(among other things) I think that customer-driven is not necessarily
always correct paradigm.
> CFFI. What took so long? Apparently Kenny is the first real application
> programmer Lisp has seen in a while.
Kenny, it is not *that* sad IMHO. BTW in application we develop (and
use, and market) GUI is done with Delphi - no problem with that at all.
It is still an application.
as for opposing Linux, I for one use it at my day job, and run LW
inside Windows inside VMWare, which speaks for itself: my company paid
for Windows, I paid for VMWare, but I still run Linux - may be
something other than money matters too, isn't it (haven't used OS X
though, have plans to try)?
On 2006-12-01 21:15:28 +0000, Charlton Wilbur <·······@chromatico.net> said:
> where does he get off telling me that I *can't*
> go with vendor C because vendor C charges less than vendor A or B for
> the feature set that *I* want or need, simply because vendor C isn't
> charging at all?
Did he do this? What I saw was:
Kenny: You free-free-free people simply never imagine the vendor's
postion in a world where Lisp is still a niche market. This language is
a commercial, competitive, productivity grand slam and two vendors are
providing extraordinary implementations and add-ons and you are
bleating about the cost?!
Telling people to stop bleating is not telling them anything other than
to, well, stop bleating. Get on and make the damn decision already,
whatever it is, and don't whine on usenet in other words.
--tim
On 2006-11-30 20:49:35 -0500, Ken Tilton <·········@gmail.com> said:
> you wanted to roll around kicking and a-gouging in the mud and the
> blood and the beer.
Somehow "A Boy Named Kenzo" doesn't have quite the same ring. ;^)
Ken Tilton wrote:
>
>
> David Steuber wrote:
>> Ken Tilton <·········@gmail.com> writes:
>>
>>
>>> Sad day, and sadder still when it does run on win32.
>>
>>
>> Are you made out of wet blankets and bile?
>>
>
> Apparently not:
>
> http://www.tilton-technology.com/rogercormannyc3.html
>
> Are you made of adhominium?
>
> I made a remark about how the community choses to allocate scarce
> resources. It is pretty abstract cuz of course we are all free to do as
> we please, and of course there is no community. In fact, I was just
> counterbalancing a rather bizarre dancing-in-the-streets phenomenon over
> I-am-not-sure-what accomplishment with an admittedly dubious point:
> exactly what drives the development of CMUCL/SBCL when we have not-all
> that-expensive pro licenses for LW and ACL, as well as utterly free
> CLisp with aewsome FFI, MOP, and more?
Your remark was not really about Common Lisp per se, and the topic is
known to cause heated discussions / flames, with no realistic chance of
achieving an agreement in the end.
Could your remark be classified as trolling?
Just asking...
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On Fri, 01 Dec 2006 07:56:14 +0100, Pascal Costanza <··@p-cos.net> wrote:
> Ken Tilton wrote:
>> David Steuber wrote:
>>> Ken Tilton <·········@gmail.com> writes:
>>>
>>>
>>>> Sad day, and sadder still when it does run on win32.
>>>
>>>
>>> Are you made out of wet blankets and bile?
>>>
>> Apparently not:
>> http://www.tilton-technology.com/rogercormannyc3.html
>> Are you made of adhominium?
>> I made a remark about how the community choses to allocate scarce
>> resources. It is pretty abstract cuz of course we are all free to do as
>> we please, and of course there is no community. In fact, I was just
>> counterbalancing a rather bizarre dancing-in-the-streets phenomenon
>> over I-am-not-sure-what accomplishment with an admittedly dubious
>> point: exactly what drives the development of CMUCL/SBCL when we have
>> not-all that-expensive pro licenses for LW and ACL, as well as utterly
>> free CLisp with aewsome FFI, MOP, and more?
>
> Your remark was not really about Common Lisp per se, and the topic is
> known to cause heated discussions / flames, with no realistic chance of
> achieving an agreement in the end.
>
> Could your remark be classified as trolling?
>
> Just asking...
>
>
> Pascal
>
Ken has gone trolling recenty despite his dedication to fighting trolls.
He has become what he fears.. lol
Perhaps we should just stick to programming.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
News flash: Every other LispNYC member probably thinks you're an
immature, over sensitive little punk. Do you have Aspergers or
something? We understand that you cannot grasp the concept of a free
market economy, but are you also physically incapable of understanding
that your opinions are not the words of God, that the world does not
revolve around you? The lisp user 'community' is so weak and younger
coders are scared away specifically b/c people like you, which is part
of the reason why your beloved AllegroCL costs so much. And no, you
weren't simply 'counterbalancing' the bizzare dancing in the street
phenomena. You were actively trying to belittle and bully others.
Ken Tilton wrote:
> David Steuber wrote:
> > Ken Tilton <·········@gmail.com> writes:
> >
> >
> >>Sad day, and sadder still when it does run on win32.
> >
> >
> > Are you made out of wet blankets and bile?
> >
>
> Apparently not:
>
> http://www.tilton-technology.com/rogercormannyc3.html
>
> Are you made of adhominium?
>
> I made a remark about how the community choses to allocate scarce
> resources. It is pretty abstract cuz of course we are all free to do as
> we please, and of course there is no community. In fact, I was just
> counterbalancing a rather bizarre dancing-in-the-streets phenomenon over
> I-am-not-sure-what accomplishment with an admittedly dubious point:
> exactly what drives the development of CMUCL/SBCL when we have not-all
> that-expensive pro licenses for LW and ACL, as well as utterly free
> CLisp with aewsome FFI, MOP, and more?
>
> Is it the "I am looking for a free XXX" disease RMS unleashed on the
> software industry?
>
> Oh, sorry, I am back on topic, you wanted to roll around kicking and
> a-gouging in the mud and the blood and the beer. Nah, you gotta come to
> LispNYC meetings and get to me before the bouncers do.
>
> :)
>
> kzo
>
>
>
> --
> Cells: http://common-lisp.net/project/cells/
>
> "I'll say I'm losing my grip, and it feels terrific."
> -- Smiling husband to scowling wife, New Yorker cartoon
David Steuber wrote:
> Ken Tilton <·········@gmail.com> writes:
>
>> Sad day, and sadder still when it does run on win32.
>
> Are you made out of wet blankets and bile?
He's probably just still sore about what (expt -3 2) returns.
Damien Kick wrote:
> David Steuber wrote:
>
>> Ken Tilton <·········@gmail.com> writes:
>>
>>> Sad day, and sadder still when it does run on win32.
>>
>>
>> Are you made out of wet blankets and bile?
>
>
> He's probably just still sore about what (expt -3 2) returns.
No, I am just goading them into finishing the win32 version. Then I stop
sharing Cells and Cello and Celtk and build a proprietary cash machine
atop their sweat. Giving them nothing. PWUAUAAAHAHAHAHAHAHAHAAA!!!!!
kzo
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Cells? You mean that thing that makes you look like a closet Eiffel
programmer?
> No, I am just goading them into finishing the win32 version. Then I stop
> sharing Cells and Cello and Celtk and build a proprietary cash machine
> atop their sweat. Giving them nothing. PWUAUAAAHAHAHAHAHAHAHAAA!!!!!
>
> kzo
>
> --
> Cells: http://common-lisp.net/project/cells/
>
> "I'll say I'm losing my grip, and it feels terrific."
> -- Smiling husband to scowling wife, New Yorker cartoon
thetza wrote:
> Cells? You mean that thing that makes you look like a closet Eiffel
> programmer?
You think Eiffel invented dataflow? You might want to avoid technical
debate going forward and just stick to the name-calling, we haven't had
your level of discourse in a while around here and I for one am enjoying
it greatly.
kt
ps. LispNYC were great at hiding their animosity during my packed,
raucous, hours-long presentation. There is a video of the second half
but it takes longer to download than watch.
ftp://lispnyc.org/meeting-assets/2006-11-15_algebra1/
You will note the talk is interrupted repeatedly by bursts of applause.
Yes, I had an "Applause" sign, but still...
Here's the review:
"Review: Kenny, having been a teacher in the trenches of low-income
school district, was in rare form. His presentation was delivered in
style and the crowd of geeks pushed the limits of his very impressive
algerbra tutoring software."
You know I did not write that because the program is not called
"Tilton's Algerbra". :)
k
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
I never said it was invented in Eiffel. But you pimp it like YOU did.
Seriously, what is your problem? Are you such a god because you wrote
some algebra tutoring program (what else have you done?)? I started
learning Lisp b/c I thought Norvig and Graham's books were marvelous
examples of technical writing and was intrigued, but I come here to ask
a few questions (not under this name) and get harassed and ridiculed.
I'm close to quitting Lisp thanks to you.
Ken Tilton wrote:
> You think Eiffel invented dataflow? You might want to avoid technical
> debate going forward and just stick to the name-calling, we haven't had
> your level of discourse in a while around here and I for one am enjoying
> it greatly.
>
"thetza" <······@mm.st> writes:
> I never said it was invented in Eiffel. But you pimp it like YOU did.
> Seriously, what is your problem? Are you such a god because you wrote
> some algebra tutoring program (what else have you done?)? I started
> learning Lisp b/c I thought Norvig and Graham's books were marvelous
> examples of technical writing and was intrigued, but I come here to ask
> a few questions (not under this name) and get harassed and ridiculed.
> I'm close to quitting Lisp thanks to you.
This is funny. You're going to "quit" a language because someone on a
newsgroup runs you the wrong way? How can you not find that
completely ridiculous?
(Please stop top-posting!)
thetza wrote:
> I never said it was invented in Eiffel.
Well, you could have said Steele's PhD or Garnet or COSI -- all Lisp or
lispish (actually i do not remember Steele's syntax) -- what led you to
choose Eiffel? (I looked but did not see much indication that it did
serious dataflow (but I did not look very hard)).
> But you pimp it like YOU did.
If you were reading what I wrote instead of the Sailor's Guide to
Insults, you might have found one of my many recitations of the
extensive prior art:
http://www.lispnyc.org/wiki.clp?page=PyCells
btw, if you now belatedly check the prior art you will discover Adobe is
pretty pimped up over Adam, and if you read Steele's thesis you will
find him marvelling at how such a great approach to programming could
have been passed over for ten years, and if you had heard the COSI talk
at LUGM '99 you would have enjoyed Mark G's unbridled excitement, and...
oh, never mind.
The problem is not me (and many others) telling you about a great
paradigm, the problem is you (and many others) not listening.
> Seriously, what is your problem?
Same as yours, the illusion of self. We covered this last semester.
> Are you such a god because you wrote
> some algebra tutoring program (what else have you done?)?
No, I ascended to heaven in my fifth month as junior programmer after
achieving from scratch in eight weeks (in COBOL!) what had stymied a
series of three analysts for two years -- an insurance application
system front-end -- by using a table-driven design and structured
programming techniques I had been reading about.
> I started
> learning Lisp b/c I thought Norvig and Graham's books were marvelous
> examples of technical writing and was intrigued, but I come here to ask
> a few questions (not under this name) and get harassed and ridiculed.
By me? I just remember returning your fire. Can you point to where I
drew first blood?
kt
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
thetza wrote:
> I never said it was invented in Eiffel. But you pimp it like YOU did.
> Seriously, what is your problem? Are you such a god because you wrote
> some algebra tutoring program (what else have you done?)? I started
> learning Lisp b/c I thought Norvig and Graham's books were marvelous
> examples of technical writing and was intrigued, but I come here to ask
> a few questions (not under this name) and get harassed and ridiculed.
Oh, I get it, no, I did not harass or ridicule "you", I harassed and
ridiculed you, who must remain anonymous lest we gain access to evidence
as to how big a jerk you are. So you sneak back in as a pseudonym to
settle the score, but are so dumb "you" admit to being you.
Well, let's see if we can take a rough measure of you from what we know
of "you":
"...tends to make Windows fanboys wet their pants b/c it marginalizes
them." Charming.
"Thats a rhetorical question. Everyone knows your answer will be
condescending." Combative.
"Jealous? .. Oh wait, your idea of a cross-platform GUI toolkit is
celtk,n/m." Hostile.
"Every other LispNYC member probably thinks you're an immature, over
sensitive little punk." I loved that one, possibly a first, Projection
By Probability. The Dallas Cowboy Cheerleaders probably think you have a
small...n/m.
"Do you have Aspergers or something?" Aw, just when you had piled up all
those points for originality.
"you also physically incapable of understanding that your opinions are
not the words of God". Nice comeback on originality! Physical
understanding? What part of the mind-body problem do you not understand?
> I'm close to quitting Lisp thanks to you.
Could "you" take you with "you"?
thx,kt
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Kenny, man, you are funny. This whole flamewar was worth it just to
read your responses. Your sense of humor is priceless and rare.
Sometimes you're full of crap but always damn entertaining.
Yes this post is all about Kenny. Sorry, I couldn't help it. People
at work started wondering what I was doing since I was laughing so
hard. You've made my day.
Thx, -D.
······@riverglassinc.com wrote:
> Kenny, man, you are funny. This whole flamewar was worth it just to
> read your responses. Your sense of humor is priceless and rare.
> Sometimes you're full of crap but always damn entertaining.
I try to keep a balance.
>
> Yes this post is all about Kenny. Sorry, I couldn't help it.
Oh great, now The Cult of the Indiviudal. <sigh>
Someone should Slashdot me, I can be the Poster Boy for Dysfunctional
Smug Lisp Weenies, the Anti-Champion. People will start saying bad
things about Lisp just to get savaged by me, the way drunks in bars
challenge prize fighters. Our reputation will get worse and worse, but
every hundredth loser will turn out to be someone who Actually Writes
Code and maybe Verrazano will get finished.
> People
> at work started wondering what I was doing since I was laughing so
> hard. You've made my day.
Don't encourage him.
:)
kenneth
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
(message (Hello 'Ken)
(you :wrote :on '(Thu, 30 Nov 2006 12:57:35 -0500))
(
KT> and the brightest young Lisp turks are just trying to drive Franz and
KT> Lispworks out of business when there is so much other amazing code to
KT> be written.
maybe that'll cause Franz and Lispworks to improve their implementations --
for example, support hw multithreading of lisp code?
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
"Alex Mizrahi" <········@users.sourceforge.net> writes:
> maybe that'll cause Franz and Lispworks to improve their implementations --
> for example, support hw multithreading of lisp code?
Which free Lisps do this?
Bill Atkins wrote:
> "Alex Mizrahi" <········@users.sourceforge.net> writes:
> > maybe that'll cause Franz and Lispworks to improve their implementations --
> > for example, support hw multithreading of lisp code?
> Which free Lisps do this?
I was under the impression that SBCL had "experimental"[1] support for
this, but I could be wrong.
Cheers,
Pillsy
[1] Which may or may not count for the purposes of this discussion.
Bill Atkins <······@rpi.edu> writes:
> "Alex Mizrahi" <········@users.sourceforge.net> writes:
>
>> maybe that'll cause Franz and Lispworks to improve their implementations --
>> for example, support hw multithreading of lisp code?
>
> Which free Lisps do this?
None. That's the point.
--
__Pascal Bourguignon__ http://www.informatimago.com/
I need a new toy.
Tail of black dog keeps good time.
Pounce! Good dog! Good dog!
Pascal Bourguignon wrote:
> Bill Atkins <······@rpi.edu> writes:
>
>
>>"Alex Mizrahi" <········@users.sourceforge.net> writes:
>>
>>
>>>maybe that'll cause Franz and Lispworks to improve their implementations --
>>>for example, support hw multithreading of lisp code?
>>
>>Which free Lisps do this?
>
>
> None. That's the point.
>
And about as moronic as one could hope for. Sure, let's have RMS start a
free automobile factory so detroit will be forced to achieve levitation
in order to make a frickin dime. buh-rillyant.
kt
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
(message (Hello 'Bill)
(you :wrote :on '(Thu, 30 Nov 2006 22:54:27 -0500))
(
??>> maybe that'll cause Franz and Lispworks to improve their
??>> implementations -- for example, support hw multithreading of lisp
??>> code?
BA> Which free Lisps do this?
SBCL, OpenMCL, ABCL.
well, OpenMCL currently normally runs only on PPC, SBCL's support is
experimental and not all platforms are supported, ABCL runs ontop of JVM.
but here commercial vendos can, at least, give something that is not
present in free implementations -- consistent and stable support.
well, there is Scieneer Common Lisp that is designed to be runned on
multiprocessor systems, a rewrite of CMUCL -- but it costs hell a lot,
something like 3000 for one installation.
hw multithreading is not a rocket science -- free .net implementation Mono
(by the way, i think Microsoft encourages it) has this, as well as most free
JVMs, so absense of this in Common Lisp implementation means either lazyness
or technical incompetence of the implementors.
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
"Alex Mizrahi" <········@users.sourceforge.net> writes:
> hw multithreading is not a rocket science -- free .net implementation Mono
> (by the way, i think Microsoft encourages it) has this,
Mono currently just uses Boehm GC, although there are plans to replace
it with some accurate copying collector.
In my measurements Boehm GC is approximately as fast as malloc,
i.e. quite slow for Lisp which tends to allocate many small objects.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
(message (Hello 'Marcin)
(you :wrote :on '(Tue, 05 Dec 2006 01:16:07 +0100))
(
??>> hw multithreading is not a rocket science -- free .net implementation
??>> Mono (by the way, i think Microsoft encourages it) has this,
MQK> Mono currently just uses Boehm GC, although there are plans to replace
MQK> it with some accurate copying collector.
MQK> In my measurements Boehm GC is approximately as fast as malloc,
MQK> i.e. quite slow for Lisp which tends to allocate many small objects.
it terribly depends on the usage pattern. afair several lisp
implementations -- ECL and CLISP -- can be configured to use Boehm GC, can
you say they are terribly slower than other?
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
> hw multithreading is not a rocket science -- free .net
> implementation Mono (by the way, i think Microsoft encourages it)
> has this, as well as most free JVMs, so absense of this in Common
> Lisp implementation means either lazyness or technical incompetence
> of the implementors.
It's hard. It interacts in nasty ways with garbage collection and
special variables. In my experiments with CMUCL I could easily get
multiple processes that shared their address spaces (basically kernel
threads) but of course they'd go south the first time the garbage
collector ran.
If someone just wants to run independent processes with the same
starting state, which gives you everything threads give you except
IPC, then you can use some variant of the following code (which I may
have posted before, I don't know).
What this code does is allow you to do a complete fork of the lisp
image so that you have all the state you had before, but in a new
process image. For those who are wondering, this is not the memory
hog you might think, because all the pages of the images are shared
except the ones that get modified.
It runs under CMUCL and FreeBSD, but can be easily changed to run
under other lisps and operating systems.
Caveat: all the file descriptors are shared. I had some fun with
these processes talking to MySQL and MySQL getting awfully confused,
or rather me getting awfully confused as to why stuff was not working
sensibly. Basically you have to close all the file descriptors that
you don't want to share. Code like this:
;;;
;;; This is pretty CMUCL specific, but there are ways to do this in
;;; other lisps.
(defun close-descriptors ()
(dotimes (descriptor 1024) ; Probably excessive....
(multiple-value-bind (host port)
(ignore-errors (ext:get-peer-host-and-port descriptor))
;; Close any file descriptors connected to the database port so
;; we don't confuse MYSQL.
(when (and host (= port *port*))
(format *debug-io* "Closing descriptor ~D, peer port ~D~%" descriptor port)
(unix:unix-close descriptor)))))
;;; -*- Mode: Common-Lisp; Package: UNIX-PROCESS -*-
;;;
(ext:file-comment "$Id: unix-process.lisp,v 1.3 2006/10/25 19:24:12 gilham Exp $")
(defpackage "UNIX-PROCESS"
(:nicknames :uxpx)
(:use :common-lisp :unix)
(:export wait4 with-timed-unix-process))
(in-package :uxpx)
;;;
;;; Code to reap terminated processes.
;;;
(declaim (inline c-wait4))
(alien:def-alien-routine ("wait4" c-wait4) c-call:int
(wpid c-call:int)
(status c-call:int :out)
(options c-call:int)
(rusage c-call:int))
(defun wait4 (pid &optional do-not-hang check-for-stopped)
"Return any available status information on child processed. "
(multiple-value-bind (pid status)
(c-wait4 pid
(logior (if do-not-hang
ext::wait-wnohang
0)
(if check-for-stopped
ext::wait-wuntraced
0))
0)
(cond ((or (minusp pid) (zerop pid))
nil)
((eql (ldb (byte 8 0) status) ext::wait-wstopped)
(values pid :stopped (ldb (byte 8 8) status)))
((zerop (ldb (byte 7 0) status))
(values pid :exited (ldb (byte 8 8) status)))
(t (let ((signal (ldb (byte 7 0) status)))
(values pid
(if (or (eql signal sigstop)
(eql signal sigtstp)
(eql signal sigttin)
(eql signal sigttou))
:stopped
:signaled)
signal
(not (zerop (ldb (byte 1 7) status)))))))))
;;;
;;; Stuff to run a lisp function as a unix process with a timeout.
;;;
(defun timed-unix-process-internal (timeout function timeout-function termination-function)
(let ((the-signal nil)
pid)
(flet ((handle-process-terminate (signal code scp)
"This handles the child process terminating spontaneously."
(declare (ignore code scp))
(print "terminate")
(force-output)
(setf the-signal signal)
;; Disable alarm.
(unix-setitimer :real 0 0 0 0))
(handle-process-kill (signal code scp)
"This handles an external kill."
(declare (ignore code scp))
(print "kill")
(force-output)
(setf the-signal signal)
;; Disable alarm.
(unix-setitimer :real 0 0 0 0)
;; Kill the child.
(unix-kill pid :sigterm))
(handle-process-timeout (signal code scp)
"This handles the alarm going off."
(declare (ignore code scp))
(print "alarm")
(force-output)
(setf the-signal signal)
;; Kill the child.
(unix-kill pid :sigterm)))
(setf pid (unix-fork))
(when (zerop pid)
;; The child.
(funcall function)
;; This seems to work the cleanest.
(unix-exit))
;; The parent.
(format *debug-io* "Parent PID is ~D~%" (unix-getpid))
(sys:with-enabled-interrupts
((:sigalrm #'handle-process-timeout)
(:sigchld #'handle-process-terminate)
(:sigterm #'handle-process-kill))
;; Start the one shot timer.
(unix-setitimer :real 0 0 timeout 0)
;; Wait for interrupt.
(unix-sigpause (not (sigmask :sigalrm :sigchld :sigterm)))))
(format *debug-io* "The signal: ~D~%" the-signal)
(force-output)
(cond ((= the-signal (unix-signal-number :sigalrm))
;; Terminate the child process.
;;(kill-process pid)
(funcall timeout-function))
((= the-signal (unix-signal-number :sigterm))
;; We're being killed by the GUI.
;; Terminate the child process.
;;(kill-process pid)
)
((= the-signal (unix-signal-number :sigchld))
;; Child terminated by itself.
(funcall termination-function))
(t (error "Unknown signal")))
;; Sleep 1 second (just in case) then reap the child.
(sleep 1)
(wait4 pid)
the-signal))
;;; With-timed-unix-process -- Public
;;;
(defmacro with-timed-unix-process (timeout
(&body timeout-forms)
(&body termination-forms)
&body body)
"Executes body and returns the values of the termination-forms, or
the timeout forms if the process runs longer than the timeout."
`(flet ((fn () . ,body)
(ti () . ,timeout-forms)
(tt () . ,termination-forms))
(timed-unix-process-internal ,timeout #'fn #'ti #'tt)))
(defun test-timed-process ()
(with-timed-unix-process 8
((format t "Timed out!~%"))
((format t "Terminate form.~%"))
(let ((string
(format nil "Running the body form. PID is ~D. Sleeping for 5 seconds.~%"
(unix-getpid))))
(format t "~A~%" string)
(force-output)
(sleep 5))))
--
Fred Gilham ······@csl.sri.com
The amazing thing is, back when I was a C++ programmer, I thought that
[Design Patterns] was SUCH a great book. And I guess it was, in a
way: it made it possible to use C++ and get something done. In the
long run, of course, that may have been a disservice... - Alain Picard
On 2006-11-30 17:57:35 +0000, Ken Tilton <·········@gmail.com> said:
> ········@gmail.com wrote:
>> Lars Rune Nøstdal wrote:
>>> SBCL has just turned 1.0!
>> A big congrats goes out to the dev team. SBCL is an awesome
>> implementation =)
>
> Rubbish. No IDE and runs on like 5% of the world's computers. After a
> quarter frickin century. Typical academic self-absorbed
> non-accomplishment. Say what you will about commercial software, the
> need to eat has no substitute when it comes to productivity.
>
> Python wins because GvR was man enough to realize the wasted brainpower
> going into replacing lambda and back down. Lisp loses because the best
> and the brightest young Lisp turks are just trying to drive Franz and
> Lispworks out of business when there is so much other amazing code to
> be written.
>
> Sad day, and sadder still when it does run on win32.
On the contrary, great day: The first time, in months, that
I can agree with KT :)
Though, on the quality front, if this SBCL release could push
Franz & LispWorks towards integration with cusp
(http://www.paragent.com/lisp/cusp/cusp.htm) in the same way
cusp does for SBCL, some of us, Emacs haters/Eclipse lovers
would certainly rejoice :-)
--
JFB
Runs on 5% of the world's computer? Every time I run a google search on
Windows I'm using Linux from a web interface. The thought of web apps
slowly but steadily replacing desktop apps tends to make Windows
fanboys wet their pants b/c it marginalizes them. And if I were someone
who paid untold thousands for a Lisp implementation which doesn't even
support true SMP multithreading, I wouldn't be criticizing other
implementations. And Lispworks and Franz aren't charities. If they
can't keep up with free alternatives they deserve to go out of
business.
Ken Tilton wrote:
> ········@gmail.com wrote:
> > Lars Rune Nøstdal wrote:
> >
> >>SBCL has just turned 1.0!
> >
> >
> > A big congrats goes out to the dev team. SBCL is an awesome
> > implementation =)
>
> Rubbish. No IDE and runs on like 5% of the world's computers. After a
> quarter frickin century. Typical academic self-absorbed
> non-accomplishment. Say what you will about commercial software, the
> need to eat has no substitute when it comes to productivity.
>
> Python wins because GvR was man enough to realize the wasted brainpower
> going into replacing lambda and back down. Lisp loses because the best
> and the brightest young Lisp turks are just trying to drive Franz and
> Lispworks out of business when there is so much other amazing code to be
> written.
>
> Sad day, and sadder still when it does run on win32.
>
> kzo
>
> --
> Cells: http://common-lisp.net/project/cells/
>
> "I'll say I'm losing my grip, and it feels terrific."
> -- Smiling husband to scowling wife, New Yorker cartoon
"thetza" <······@mm.st> writes:
> Runs on 5% of the world's computer? Every time I run a google search on
> Windows I'm using Linux from a web interface. The thought of web apps
> slowly but steadily replacing desktop apps tends to make Windows
> fanboys wet their pants b/c it marginalizes them. And if I were someone
Or because web interfaces are so hideous compared to native
interfaces. Or because web programming is harder than it has to be
because of HTTP, HTML, differences between browsers, etc.
> implementations. And Lispworks and Franz aren't charities. If they
> can't keep up with free alternatives they deserve to go out of
> business.
Hehehe.
thetza wrote:
> Runs on 5% of the world's computer? Every time I run a google search on
> Windows I'm using Linux from a web interface.
Does this explain why it is so frickin impossible to work with GMail?
Start-stop typing, sooooo much fun.
Sorry, Charlie, Web apps ain't there yet. It'll be fun when they are...
of course maybe the problem is that Google uses Python?
:)
kzo
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
When someone writes a decent word processor and spreadsheet web
application, most of those 95% of users would have no reason to choose
a full blown desktop machine (full of bugs, blue screens, crashes,
malware, viruses, lost data) over a simple internet appliance with a
web browser. Why do you think so many people put up with uglier
interface over desktop GUI's? (Thats a rhetorical question. Everyone
knows your answer will be condescending.) Jealous? Write a GUI toolkit
which makes an application as easy to install/upgrade and as portable
as a web application. Oh wait, your idea of a cross-platform GUI
toolkit is celtk,n/m.
Ken Tilton wrote:
> thetza wrote:
> > Runs on 5% of the world's computer? Every time I run a google search on
> > Windows I'm using Linux from a web interface.
>
> Does this explain why it is so frickin impossible to work with GMail?
> Start-stop typing, sooooo much fun.
>
> Sorry, Charlie, Web apps ain't there yet. It'll be fun when they are...
> of course maybe the problem is that Google uses Python?
>
> :)
>
> kzo
>
> --
> Cells: http://common-lisp.net/project/cells/
>
> "I'll say I'm losing my grip, and it feels terrific."
> -- Smiling husband to scowling wife, New Yorker cartoon
thetza wrote:
> When someone writes a decent word processor and spreadsheet web
> application, most of those 95% of users would have no reason to choose
> a full blown desktop machine (full of bugs, blue screens, crashes,
> malware, viruses, lost data) over a simple internet appliance with a
> web browser.
And then it is OK for SBCL to run only 5% of the world's computers?
I am sorry, you have made on of the classic blunders of Usenet
discussion (the first is getting engaged in a land war in Iraq), and I
have encouraged you.
Your premise is that SBCL /effectively/ runs on win32, given Web apps.
This is like making an analogy. Now we have to argue over whether these
astonishing machines me have in front of us need only serve as thin
clients. Fortunately, this Rosemary-Woodian stretch* means you concede
my point, that SBCL does not run on 95% of the machines, so we agree.
Great!
kt
*
http://www.fordlibrarymuseum.gov/museum/exhibits/watergate_files/content.php?section=3&page=a&zoom=2
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
And your beloved Allegro CL will run on exactly 0% of machines b/c evil
communists will write free software which will illegally steal market
share from Franz and you will be forced to go back to VB.
Ken Tilton wrote:
> thetza wrote:
> > When someone writes a decent word processor and spreadsheet web
> > application, most of those 95% of users would have no reason to choose
> > a full blown desktop machine (full of bugs, blue screens, crashes,
> > malware, viruses, lost data) over a simple internet appliance with a
> > web browser.
>
> And then it is OK for SBCL to run only 5% of the world's computers?
>
> I am sorry, you have made on of the classic blunders of Usenet
> discussion (the first is getting engaged in a land war in Iraq), and I
> have encouraged you.
>
> Your premise is that SBCL /effectively/ runs on win32, given Web apps.
> This is like making an analogy. Now we have to argue over whether these
> astonishing machines me have in front of us need only serve as thin
> clients. Fortunately, this Rosemary-Woodian stretch* means you concede
> my point, that SBCL does not run on 95% of the machines, so we agree.
>
> Great!
>
> kt
>
> *
> http://www.fordlibrarymuseum.gov/museum/exhibits/watergate_files/content.php?section=3&page=a&zoom=2
>
> --
> Cells: http://common-lisp.net/project/cells/
>
> "I'll say I'm losing my grip, and it feels terrific."
> -- Smiling husband to scowling wife, New Yorker cartoon
On 2006-12-01 20:51:51 +0000, "thetza" <······@mm.st> said:
> When someone writes a decent word processor and spreadsheet web
> application, most of those 95% of users would have no reason to choose
> a full blown desktop machine (full of bugs, blue screens, crashes,
> malware, viruses, lost data) over a simple internet appliance with a
> web browser.
This explains nicely why people moved in such large numbers from
stateless desktops to PCs 10-15 years ago. or .. maybe not.
thetza wrote:
> When someone writes a decent word processor and spreadsheet web
> application, most of those 95% of users would have no reason to choose
> a full blown desktop machine (full of bugs, blue screens, crashes,
> malware, viruses, lost data) over a simple internet appliance with a
> web browser. Why do you think so many people put up with uglier
> interface over desktop GUI's? (Thats a rhetorical question. Everyone
> knows your answer will be condescending.) Jealous? Write a GUI toolkit
> which makes an application as easy to install/upgrade and as portable
> as a web application. Oh wait, your idea of a cross-platform GUI
> toolkit is celtk,n/m.
>
I'll translate that. Since fanboys are frustrated that desktop linux
never took off, the only hope now is that everybody embraces the Larry
Ellison dream of the thin client (running linux of course), and endures
the utterly piece of shit interface for applications that is a stock
browser.
WPF/E will just drive the point home harder that stock browsers are
absolutely craptastic, no matter how much AJAX you spooge on it.
Oh, and congratulations to the SBCL team.
Ken Tilton wrote:
> ········@gmail.com wrote:
> > Lars Rune Nøstdal wrote:
> >
> >>SBCL has just turned 1.0!
>
> Sad day, and sadder still when it does run on win32.
Get over it. Open Source lisps are here and they are getting only
better.
Oh and get over yourself too.
People like the variety and the low barrier of entry offered by the
free lisps. (Do you think projects like GCC, Apache and Linux have made
the world a worse place?)
Shilling for Franz and LW aside, what is it you got against SBCL
developers anyway ?
Atleast Naggum had substance. Your constant sarcasm is a poor
substitute.
pjd wrote:
> Ken Tilton wrote:
> Oh and get over yourself too.
>
> Shilling for Franz and LW aside,..
>
> Atleast Naggum had substance. Your constant sarcasm is a poor
> substitute.
>
thetza wrote:
> And your beloved Allegro CL will run on exactly 0% of machines b/c evil
> communists will write free software which will illegally steal market
> share from Franz and you will be forced to go back to VB.
I have always said it would be a good sign for Lisp when the
sophistication of the average bear posting here dropped -- the great
unwashed have arrived!
These two make up for yesterday's sad news. :)
kt
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
> pjd wrote:
> > Ken Tilton wrote:
>
> > Oh and get over yourself too.
> >
> > Shilling for Franz and LW aside,..
> >
> > Atleast Naggum had substance. Your constant sarcasm is a poor
> > substitute.
> >
>
> thetza wrote:
> > And your beloved Allegro CL will run on exactly 0% of machines b/c evil
> > communists will write free software which will illegally steal market
> > share from Franz and you will be forced to go back to VB.
>
> I have always said it would be a good sign for Lisp when the
> sophistication of the average bear posting here dropped -- the great
> unwashed have arrived!
>
> These two make up for yesterday's sad news. :)
Always having the last word is not same as being right.
Implementing a usable common lisp system is no mean task. If you cant
bring yourself to appreciate their efforts, at least you could have
kept your mouth shut and not turn the thread of their announcement into
this low grade flamefest.
Oh well, you are the master of insults and zingers. What chance any of
us have winning any argument?
Waiting for the inevitable last word ...
·······@gmail.com wrote:
> Ken Tilton wrote:
>
>>pjd wrote:
>>
>>>Ken Tilton wrote:
>>
>>>Oh and get over yourself too.
>>>
>>>Shilling for Franz and LW aside,..
>>>
>>>Atleast Naggum had substance. Your constant sarcasm is a poor
>>>substitute.
>>>
>>
>>thetza wrote:
>> > And your beloved Allegro CL will run on exactly 0% of machines b/c evil
>> > communists will write free software which will illegally steal market
>> > share from Franz and you will be forced to go back to VB.
>>
>>I have always said it would be a good sign for Lisp when the
>>sophistication of the average bear posting here dropped -- the great
>>unwashed have arrived!
>>
>>These two make up for yesterday's sad news. :)
>
>
> Always having the last word is not same as being right.
>
> Implementing a usable common lisp system is no mean task.
Yes! Thank you! Finally someone who understands what I am trying to say!!
> If you cant
> bring yourself to appreciate their efforts,
..uh-oh...
> at least you could have
> kept your mouth shut
..oh my...
> and not turn the thread of their announcement into
> this low grade flamefest.
Didn't you want to point out that SBCL has this insane advantage over
other lisps, or anything else /relevant/? Lesseee:
>
> Oh well, you are the master of insults and zingers.
I suppose I /could/ construe that as a compliment. :)
> What chance any of
> us have winning any argument?
The chance that comes from sticking to the issue of the impact of free
software on the viability of commercial tools? Instead you are attacking
me and my motivation. That usually works, unless you get called on it.
>
> Waiting for the inevitable last word ...
>
Admit it, you thought that might work. :)
kt
ps. Damn, random problem generation is coming along beautifully. Just
turned the algorithm inside out, through out half the code, and it Just
Worked on like the third run. This is classic PG (from rough memory)
"when you do not know what program you are going to write". k
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
On Thu, 30 Nov 2006 12:57:35 -0500, Ken Tilton wrote:
>
>
> ········@gmail.com wrote:
>> Lars Rune Nøstdal wrote:
>>
>>>SBCL has just turned 1.0!
>>
>>
>> A big congrats goes out to the dev team. SBCL is an awesome
>> implementation =)
>
> Rubbish. No IDE and runs on like 5% of the world's computers. After a
> quarter frickin century. Typical academic self-absorbed
> non-accomplishment. Say what you will about commercial software, the
> need to eat has no substitute when it comes to productivity.
> Python wins because GvR was man enough to realize the wasted brainpower
> going into replacing lambda and back down. Lisp loses because the best
> and the brightest young Lisp turks are just trying to drive Franz and
> Lispworks out of business when there is so much other amazing code to be
> written.
>
> Sad day, and sadder still when it does run on win32.
"Look Dave, I can see you're really upset about this." .. heh
I'm wondering; are you serious, bitter about something, just bored - or
what? Why do you use, contribute and support Free Software yourself if
you're against it?
..what's happening in this thread seems unnecessary, pointless and noisy..
It's an announcement of a piece of software that I and others very much
enjoy using and contributing to. I do not understand why this is a problem
for anybody. I would never have used the compilers that Franz and
Lispworks provides in the first place because something like `ANSI Common
Lisp' should be implemented as Free Software to reach the masses, ensure
existence and flexibility. I bet you feel the same way about your
`cells'-project.
There will always be ways to create and customize software or content to
sell to end users no matter how much Free Software is available. If
everything was Free Software, the way one make money is by:
* Creating new software based on - or customizing existing Free
Software. One charge for the job done; not the non-job of copying or
distributing the software.
* Utilize or "exploit" Free Software so it creates or "shapes" content
or data into a more valuable form. Content or data created by Free
software does not itself have to be Free.
Everything competes in some sense; Python competes with commercial
software - so I do not understand your argument.
--
Lars Rune Nøstdal
http://nostdal.org/
Lars Rune Nøstdal wrote:
> On Thu, 30 Nov 2006 12:57:35 -0500, Ken Tilton wrote:
>
>
>>
>>········@gmail.com wrote:
>>
>>>Lars Rune Nøstdal wrote:
>>>
>>>
>>>>SBCL has just turned 1.0!
>>>
>>>
>>>A big congrats goes out to the dev team. SBCL is an awesome
>>>implementation =)
>>
>>Rubbish. No IDE and runs on like 5% of the world's computers. After a
>>quarter frickin century. Typical academic self-absorbed
>>non-accomplishment. Say what you will about commercial software, the
>>need to eat has no substitute when it comes to productivity.
>>Python wins because GvR was man enough to realize the wasted brainpower
>>going into replacing lambda and back down. Lisp loses because the best
>>and the brightest young Lisp turks are just trying to drive Franz and
>>Lispworks out of business when there is so much other amazing code to be
>>written.
>>
>>Sad day, and sadder still when it does run on win32.
>
>
> "Look Dave, I can see you're really upset about this." .. heh
>
> I'm wondering; are you serious, bitter about something, just bored - or
> what?
I made a simple observation which could have been simply ignored. Why do
I get credit for the ad homineum crap that followed. (But thanks. <g>)
> Why do you use, contribute and support Free Software yourself if
> you're against it?
Just being rational, guessing I would do better to share it and grow it
and make money off the Cells t-shirts then to sell it and have no one
buy it, which is exactly what would have happened. Hell, even giving it
away there are about ten users. Now what do I do with all these t-shirts?
>
> ..what's happening in this thread seems unnecessary, pointless and noisy..
..and irresistible, apparently. :) Well, I have random problem
generation under control now so I may be able to code longer without
dashing back here for comic relief, you bolsheviks might want to grab
this window to rejoice over SBCL. But looking at the "new in version
1.0" list, it is hard to see the 1.0ness.
>
> It's an announcement of a piece of software that I and others very much
> enjoy using and contributing to. I do not understand why this is a problem
> for anybody. I would never have used the compilers that Franz and
> Lispworks provides in the first place because something like `ANSI Common
> Lisp' should be implemented as Free Software to reach the masses, ensure
> existence and flexibility.
CL "should be...free to reach the masses"? CLisp is splendid and runs
everywhere, OpenMCL is great, SBCL run on Linux and OS X... you see any
masses? I don't see any masses. The masses want ACL's IDE, btw, I
guarantee you.
> I bet you feel the same way about your
> `cells'-project.
I am not aware of commercial Cells or Cello products I could have
purchased. Perhaps I did not follow you.
>
> There will always be ways to create and customize software or content to
> sell to end users no matter how much Free Software is available. If
> everything was Free Software, the way one make money is by:
>
> * Creating new software based on - or customizing existing Free
> Software. One charge for the job done; not the non-job of copying or
> distributing the software.
Right, I've read the manifesto: I am now enslaved in an hourly
carrot-chase, no right to property in this pure communist environment..
kt
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
On Sat, 02 Dec 2006 04:40:56 -0500, Ken Tilton wrote:
>> Why do you use, contribute and support Free Software yourself if
>> you're against it?
>
> Just being rational, guessing I would do better to share it and grow it
> and make money off the Cells t-shirts then to sell it and have no one
> buy it, which is exactly what would have happened. Hell, even giving it
> away there are about ten users.
Yes, I think it is to be expected that it is hard to sell a compiler too.
It's like those new laptops. They expect _you_ to spend hours creating
"Recovery Discs" or you're fucked when Windows dies - even after spending
a ton of $ on the thing! I'd rather spend my $ on the stock market or
something.
No matter how much stuff they bundle with a compiler you need to invest
something extra "from yourself" as a developer and/or entrepreneur to get
something in return. That extra has to be something the end-user needs.
Duplication of software is too easy to do; both us developers
(cvs/svn/darcs) and end-users (gnutella/bittorrent) can do this. It has no
real costs, and actually doing it would benefit everyone.
So it has got to be either changes in software; our unique skill. Or
somehow enabling continuous content/data; what we as developeneurs can
automate by connecting data/content-providers, users or customers. For
instance paid access to a simulated MMORPG-world - or whatever.
Content-providers can be humans like on Youtube, they can be simulated
entities or other real human players in a game or other social thing. They
can be programs doing simple tasks like receiving data and transforming
and combining them into different forms that the end-users needs; like
trend-charts or something.
>> ..what's happening in this thread seems unnecessary, pointless and noisy..
>
> ..and irresistible, apparently. :) Well, I have random problem
> generation under control now so I may be able to code longer without
> dashing back here for comic relief, you bolsheviks might want to grab
> this window to rejoice over SBCL. But looking at the "new in version
> 1.0" list, it is hard to see the 1.0ness.
..lol.. bolsheviks.. ok .. It's not the mini-step from 0.99 (or whatever)
to 1.0 that's interesting or newsworthy; it's the "completeness" of having
something that has gone from "0.0" and is now "1.0".
>> It's an announcement of a piece of software that I and others very much
>> enjoy using and contributing to. I do not understand why this is a problem
>> for anybody. I would never have used the compilers that Franz and
>> Lispworks provides in the first place because something like `ANSI Common
>> Lisp' should be implemented as Free Software to reach the masses, ensure
>> existence and flexibility.
>
> CL "should be...free to reach the masses"? CLisp is splendid and runs
> everywhere, OpenMCL is great, SBCL run on Linux and OS X... you see any
> masses? I don't see any masses. The masses want ACL's IDE, btw, I
> guarantee you.
SBCL has different goals than CLISP. It has native compilation and
threads; I think some of the duplicate effort is justified.
There isn't much point in an IDE without a compiler underneath it, and I
think some actually prefer Slime/Emacs even with ACL's IDE available.
Others are developing things like Climacs and Cusp, but I think most are
happy with Slime/Emacs.
There seems to be "enough" users of SBCL. What I mean is that I never have
trouble finding other users. Maybe not "masses" - but then again, this is
not so with ACL or Lispworks either I think.
Maybe Lispers feel that flashy IDEs and code-generators like those in
Visual Studio isn't always good and mostly get in their way - but I might
be talking about something I know nothing of since I've never tried
Lispworks/ACL.
>> I bet you feel the same way about your
>> `cells'-project.
>
> I am not aware of commercial Cells or Cello products I could have
> purchased. Perhaps I did not follow you.
I would not want to depend on a closed compiler nor a closed Cells. Maybe
you would take that chance - but I will not. :)
>> There will always be ways to create and customize software or content to
>> sell to end users no matter how much Free Software is available. If
>> everything was Free Software, the way one make money is by:
>>
>> * Creating new software based on - or customizing existing Free
>> Software. One charge for the job done; not the non-job of copying or
>> distributing the software.
>
> Right, I've read the manifesto: I am now enslaved in an hourly
> carrot-chase, no right to property in this pure communist environment..
Hehe .. yeah, well - everything in moderation I guess. As I mentioned in
my second point (not included in your quote but re-mentioned above); one
can freely generate carrots while sleeping using Free Software. :)
--
Lars Rune Nøstdal
http://nostdal.org/
Lars Rune Nøstdal wrote:
> Maybe Lispers feel that flashy IDEs and code-generators like those in
> Visual Studio isn't always good and mostly get in their way -
<ahem> Oh, wait...
>... but I might
> be talking about something I know nothing of since I've never tried
> Lispworks/ACL.
Right. The "flashiness" of the ACL IDE is its transparency. three or
four keychords and tight integration and consistency and <poof!> the
thing disappears and I am navigating a huge, hairy wadge of code just by
thinking about it. This is probably not what you meant by "getting in
the way". :)
> I would not want to depend on a closed compiler nor a closed Cells. Maybe
> you would take that chance - but I will not. :)
You forget, I am the one who knows how to assess vendors. :)
When I listened (back in '99) to the Franz sales rep raving about how
solid AllegroStore was having just been stretched to the limits by
customer XXX and a lot of issues resolved, I knew two things: AStore was
still in beta, I would break it, and (OK, three) Franz would fix it
fast. I had actually been thru this with a mainframe RDB for VAX/VMS:
find a bug, make a reproducible (usually the hard part since they do not
want your whole project) get a patch the same day. Franz was as good,
amazing really, and just interfacing with their people over bugs gave me
a rare warm fuzzy from associating with engineers as good and committed
as they.
Your black-and-white "I will not" is too lossy. Indeed, we are back to
my premise: the FSF rules disconnect adherents from reality. They take a
gray area - vendor reliability - and paint it black. Lost is the chance
to use great software like AStore (well, from my end, anyway, Franz
obviously had different mileage with the internals, understandable since
it was built atop a devilish C++ ODB) and now ACache and work with great
engineers like Franz tech support.
Same with the IDE, all day long when I am not playing Chase the Noob on
c.l.l I dice and slice and navigate this undocumented, uncommented,
disorganized mess of a system over here without missing a beat because
of the ACL IDE and you imagine it to be something flashy that gets in
the way.
The good thing about fanaticism is the relief one gets from thinking.
Stallman should have read Sartre. "We are not free to be not free."
kzo
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
>
> Same with the IDE, all day long when I am not playing Chase the Noob on
> c.l.l I dice and slice and navigate this undocumented, uncommented,
> disorganized mess of a system over here without missing a beat because
> of the ACL IDE and you imagine it to be something flashy that gets in
> the way.
One would hope the "undocumented, uncommented, disorganized mess of a
system" isn't something you've /created/ using the wonderful ACL IDE.
On Sat, 02 Dec 2006 13:11:05 -0500, Ken Tilton wrote:
>> I would not want to depend on a closed compiler nor a closed Cells.
>> Maybe you would take that chance - but I will not. :)
>
> You forget, I am the one who knows how to assess vendors. :)
>
> When I listened (back in '99) to the Franz sales rep raving about how
> solid AllegroStore was having just been stretched to the limits by
> customer XXX and a lot of issues resolved, I knew two things: AStore was
> still in beta, I would break it, and (OK, three) Franz would fix it
> fast. I had actually been thru this with a mainframe RDB for VAX/VMS:
> find a bug, make a reproducible (usually the hard part since they do not
> want your whole project) get a patch the same day. Franz was as good,
> amazing really, and just interfacing with their people over bugs gave me
> a rare warm fuzzy from associating with engineers as good and committed
> as they.
What makes you think an Open Source company cannot have this?
* Canonical
* MySQL
* Sun (Java recently, OpenOffice and OpenSolaris)
* IBM
* RedHat
* a company in my little hometown: http://ez.no/
* ..and many more
These aren't small hobby-based projects with poor support. This has only
benefits because there can be many supporters of one piece of software.
--
Lars Rune Nøstdal
http://nostdal.org/
Lars Rune Nøstdal wrote:
> On Sat, 02 Dec 2006 13:11:05 -0500, Ken Tilton wrote:
[...]
> > Franz was as good, amazing really, and just interfacing with their people
> > over bugs gave me a rare warm fuzzy from associating with engineers as
> > good and committed as they.
> What makes you think an Open Source company cannot have this?
Nothing in particular, but I haven't seen any companies offering that
sort of support for Open Source Common Lisp implementations. Thus, if
you want what Kenny's looking for, buying a non-free implementation is
the way to go.
OTOH, given the huge differences in what you get from Franz/Lispworks
and what you get from SBCL, I can't really see the latter hurting the
former much (let alone putting them out of business). Certainly not
enough that I'm confident that harm outweighs the benefits to Franz and
Lispworks of having robust Open Source implementations.
Cheers,
Pillsy
Pillsy wrote:
> Certainly not enough that I'm confident that harm outweighs the benefits
> to Franz and Lispworks of having robust Open Source implementations.
Er, I mean that Franz and Lispworks benefit when there are robust OSS
CL implementations out there.
Cheers,
Pillsy
On Sun, 03 Dec 2006 13:17:08 -0800, Pillsy wrote:
> Lars Rune Nøstdal wrote:
>> On Sat, 02 Dec 2006 13:11:05 -0500, Ken Tilton wrote:
> [...]
>> > Franz was as good, amazing really, and just interfacing with their people
>> > over bugs gave me a rare warm fuzzy from associating with engineers as
>> > good and committed as they.
>
>> What makes you think an Open Source company cannot have this?
>
> Nothing in particular, but I haven't seen any companies offering that
> sort of support for Open Source Common Lisp implementations. Thus, if
> you want what Kenny's looking for, buying a non-free implementation is
> the way to go.
I understand this; there is currently limited "large scale" support out
there for Open Source Common Lisps. But this can change, and there are
_some_ examples of companies using and/or supporting SBCL already:
* http://tech.coop/index
* http://sb-studio.net/ (yes, I know; not quite there yet)
* http://www.hyperstring.net/
..and I'm trying to create an income using/supporting SBCL myself also. :)
So what I mean is that there are no reasons why an Open Source company
cannot supply what Kenny talked about. Maybe there will be more
"big" commercial support for SBCL now that it is 1.0. :)
Again; I have no problem understanding this or relating to "current
reality".
--
Lars Rune Nøstdal
http://nostdal.org/
On Sun, 03 Dec 2006 21:04:58 +0100, Lars Rune Nøstdal wrote:
> On Sat, 02 Dec 2006 13:11:05 -0500, Ken Tilton wrote:
>
>>> I would not want to depend on a closed compiler nor a closed Cells.
>>> Maybe you would take that chance - but I will not. :)
>>
>> You forget, I am the one who knows how to assess vendors. :)
>>
>> When I listened (back in '99) to the Franz sales rep raving about how
>> solid AllegroStore was having just been stretched to the limits by
>> customer XXX and a lot of issues resolved, I knew two things: AStore was
>> still in beta, I would break it, and (OK, three) Franz would fix it
>> fast. I had actually been thru this with a mainframe RDB for VAX/VMS:
>> find a bug, make a reproducible (usually the hard part since they do not
>> want your whole project) get a patch the same day. Franz was as good,
>> amazing really, and just interfacing with their people over bugs gave me
>> a rare warm fuzzy from associating with engineers as good and committed
>> as they.
>
> What makes you think an Open Source company cannot have this?
>
> * Canonical
> * MySQL
> * Sun (Java recently, OpenOffice and OpenSolaris)
> * IBM
> * RedHat
> * a company in my little hometown: http://ez.no/
I forgot another Norwegian company: http://www.trolltech.com/ :)
--
Lars Rune Nøstdal
http://nostdal.org/
Lars Rune Nøstdal wrote:
> On Sun, 03 Dec 2006 21:04:58 +0100, Lars Rune Nøstdal wrote:
>
>
>>On Sat, 02 Dec 2006 13:11:05 -0500, Ken Tilton wrote:
>>
>>
>>>>I would not want to depend on a closed compiler nor a closed Cells.
>>>>Maybe you would take that chance - but I will not. :)
>>>
>>>You forget, I am the one who knows how to assess vendors. :)
>>>
>>>When I listened (back in '99) to the Franz sales rep raving about how
>>>solid AllegroStore was having just been stretched to the limits by
>>>customer XXX and a lot of issues resolved, I knew two things: AStore was
>>>still in beta, I would break it, and (OK, three) Franz would fix it
>>>fast. I had actually been thru this with a mainframe RDB for VAX/VMS:
>>>find a bug, make a reproducible (usually the hard part since they do not
>>>want your whole project) get a patch the same day. Franz was as good,
>>>amazing really, and just interfacing with their people over bugs gave me
>>>a rare warm fuzzy from associating with engineers as good and committed
>>>as they.
>>
>>What makes you think an Open Source company cannot have this?
Man, some of you people are really weak on logic.
kt
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Lars Rune Nøstdal wrote:
> On Sun, 03 Dec 2006 21:04:58 +0100, Lars Rune Nøstdal wrote:
>
>
>>On Sat, 02 Dec 2006 13:11:05 -0500, Ken Tilton wrote:
>>
>>
>>>>I would not want to depend on a closed compiler nor a closed Cells.
>>>>Maybe you would take that chance - but I will not. :)
>>>
>>>You forget, I am the one who knows how to assess vendors. :)
>>>
>>>When I listened (back in '99) to the Franz sales rep raving about how
>>>solid AllegroStore was having just been stretched to the limits by
>>>customer XXX and a lot of issues resolved, I knew two things: AStore was
>>>still in beta, I would break it, and (OK, three) Franz would fix it
>>>fast. I had actually been thru this with a mainframe RDB for VAX/VMS:
>>>find a bug, make a reproducible (usually the hard part since they do not
>>>want your whole project) get a patch the same day. Franz was as good,
>>>amazing really, and just interfacing with their people over bugs gave me
>>>a rare warm fuzzy from associating with engineers as good and committed
>>>as they.
>>
>>What makes you think an Open Source company cannot have this?
Lars: "I will never travel to the United States! George Bush is evil! I
am only traveling in Europe!"
Kenzo: "Come on, over. Some USians are great."
Lars: What makes you think no Europeans are great, dammit!!!?"
<sigh>
kzo
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
On Sun, 03 Dec 2006 17:29:07 -0500, Ken Tilton wrote:
>
>
> Lars Rune Nøstdal wrote:
>> On Sun, 03 Dec 2006 21:04:58 +0100, Lars Rune Nøstdal wrote:
>>
>>
>>>On Sat, 02 Dec 2006 13:11:05 -0500, Ken Tilton wrote:
>>>
>>>
>>>>>I would not want to depend on a closed compiler nor a closed Cells.
>>>>>Maybe you would take that chance - but I will not. :)
>>>>
>>>>You forget, I am the one who knows how to assess vendors. :)
>>>>
>>>>When I listened (back in '99) to the Franz sales rep raving about how
>>>>solid AllegroStore was having just been stretched to the limits by
>>>>customer XXX and a lot of issues resolved, I knew two things: AStore was
>>>>still in beta, I would break it, and (OK, three) Franz would fix it
>>>>fast. I had actually been thru this with a mainframe RDB for VAX/VMS:
>>>>find a bug, make a reproducible (usually the hard part since they do not
>>>>want your whole project) get a patch the same day. Franz was as good,
>>>>amazing really, and just interfacing with their people over bugs gave me
>>>>a rare warm fuzzy from associating with engineers as good and committed
>>>>as they.
>>>
>>>What makes you think an Open Source company cannot have this?
>
> Lars: "I will never travel to the United States! George Bush is evil! I
> am only traveling in Europe!"
> Kenzo: "Come on, over. Some USians are great."
> Lars: What makes you think no Europeans are great, dammit!!!?"
..lol, yes - you are probably right about that; I'll never travel to the
United States.
Kenzo: "I will never travel to Europe! They are crazy hippies (no
support)! I am only traveling in the Unite States!"
Lars: "Come on, over. Some EUians are great."
Kenzo: "What makes you think no USians are great, dammit!!!?"
..logic is fun if you want it to be.. :)
But don't worry; if Franz and Lispworks switch to a more Open Source way
of doing business the great engineers you worked with will still be
available.
--
Lars Rune Nøstdal
http://nostdal.org/
Ken Tilton <·········@gmail.com> writes:
> I made a simple observation which could have been simply ignored. Why
> do I get credit for the ad homineum crap that followed. (But
> thanks. <g>)
I made a simple observation that you had a burr up your ass about all
of free software. Not that I used those exact words ;-). If you
think I was attacking you, that's your problem.
--
This post uses 100% post consumer electrons and 100% virgin photons.
At 2.6 miles per minute, you don't really have time to get bored.
--- Pete Roehling on rec.motorcycles
I bump into a lot of veteran riders in my travels.
--- David Hough: Proficient Motorcycling
David Steuber wrote:
> Ken Tilton <·········@gmail.com> writes:
>
>
>>I made a simple observation which could have been simply ignored. Why
>>do I get credit for the ad homineum crap that followed. (But
>>thanks. <g>)
>
>
> I made a simple observation that you had a burr up your...
Charming.
kt
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Lars Rune Nøstdal wrote:
> SBCL has just turned 1.0!
>
> ····@ibmr52:~$ sbcl
> This is SBCL 1.0, an implementation of ANSI Common Lisp.
> More information about SBCL is available at <http://www.sbcl.org/>.
>
> SBCL is free software, provided as is, with absolutely no warranty.
> It is mostly in the public domain; some portions are provided under
> BSD-style licenses. See the CREDITS and COPYING files in the
> distribution for more information.
> *
>
>
> This is great. :D
Yes. Congratualations to those involved.
Does this mean that the SBCL folks have confidence that SBCL is stable
on those platforms marked in green on their download site?
Has anyone been able to download the windows binaries?
http://sourceforge.net/project/showfiles.php?group_id=1373&package_id=1354
I've been trying for a while from here and it's not working for me.
Justin
justinhj wrote:
> Has anyone been able to download the windows binaries?
>
> http://sourceforge.net/project/showfiles.php?group_id=1373&package_id=1354
>
> I've been trying for a while from here and it's not working for me.
Heh.
It worked immediately once I'd posted that.
Justin
Congratulations and sincere thanks to the SBCL development team.
Without a free lisp of this quality I would not be able to get started
on projects where the budget is not up to lispworks or franz. Who can
blame them for charging enough to stay alive but the fact is, lisp can
now be chosen without a research grant, vc, or corporate budget behind
you.
regards,
robg
Lars Rune Nøstdal wrote:
> SBCL has just turned 1.0!
>
> ····@ibmr52:~$ sbcl
> This is SBCL 1.0, an implementation of ANSI Common Lisp.
> More information about SBCL is available at <http://www.sbcl.org/>.
>
> SBCL is free software, provided as is, with absolutely no warranty.
> It is mostly in the public domain; some portions are provided under
> BSD-style licenses. See the CREDITS and COPYING files in the
> distribution for more information.
> *
>
>
> This is great. :D
>
> http://digg.com/programming/SBCL_The_Common_Lisp_implementation_has_just_turned_1_0/
>
> --
> Lars Rune Nøstdal
> http://nostdal.org/
On Thu, 30 Nov 2006 11:20:08 -0800, Rob Giardina wrote:
> Congratulations and sincere thanks to the SBCL development team.
> Without a free lisp of this quality I would not be able to get started
> on projects where the budget is not up to lispworks or franz. Who can
> blame them for charging enough to stay alive but the fact is, lisp can
> now be chosen without a research grant, vc, or corporate budget behind
> you.
Sorry, I don't want to sound rude, or denigrate SBCL: I'm new to this lisp
game. I got interested when I found that installing maxima had pulled in
CLISP, and I started reading. (Well, I did some franz lisp under BSD as
an undergrad in an AI course, lo those many years ago, and I've forgotten
essentially all of that.)
What's so special about SBCL1.0, compared to all of the zillion other lisp
implementations that seem to be around? Are they all really so
un-useful? Isn't SBCL essentially similar to CMU-CL? The comment quoted
makes it sound as though this is an earth-shattering event.
Guess I'll just have to install it, and see what the fuss is about first
hand...
Cheers,
--
Andrew
Andrew Reilly <···············@areilly.bpc-users.org> writes:
> Guess I'll just have to install it, and see what the fuss is about first
> hand...
The secret is in the soft chocolaty center.
Considering the time that's gone into SBCL, it's kinda nice to see a
1.0 release. Were all the 1.0 milestones that were posted as a sort
of wish list a while back met?
--
This post uses 100% post consumer electrons and 100% virgin photons.
At 2.6 miles per minute, you don't really have time to get bored.
--- Pete Roehling on rec.motorcycles
I bump into a lot of veteran riders in my travels.
--- David Hough: Proficient Motorcycling
David Steuber wrote:
> Considering the time that's gone into SBCL,...
Oh, so you agree.
<sigh>
kt
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
(message (Hello 'Andrew)
(you :wrote :on '(30 Nov 2006 23:47:38 GMT))
(
AR> What's so special about SBCL1.0, compared to all of the zillion other
AR> lisp implementations that seem to be around?
hm, i think it's one of most actively developed.
as for special features, they are implementing harware multithreading (that
means actually running lisp code on multiple cores/processors at once).
AR> Isn't SBCL essentially similar to
AR> CMU-CL?
cmucl doesn't support threading well, so if you have a webserver, it won't
be very stable/performant.
if you want CMUCL + threads you need to pay some 3000$. so free SBCL is
cool, ye?
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
Alex Mizrahi <········@users.sourceforge.net> wrote:
+---------------
| AR> Isn't SBCL essentially similar to
| AR> CMU-CL?
|
| cmucl doesn't support threading well, so if you have a webserver,
| it won't be very stable/performant.
+---------------
Hmmm... My experience differs significantly. I've been running a
production web application using CMUCL, spawning a new thread per
web request, for several years now. It's a heck of a lot more
"performant" than the Perl- and PHP-based web apps on the same
system, and *much* more "stable" than the system as a whole
[which keeps being taken down briefly every week or two by the
co-lo ISP to do mandatory Linux & PHP security upgrades!!].
I can only think of one time in the past two years that I've
had to manually intervene, and that[1] had nothing to do with
threading at all.
Yes, there are supposed to be some problems when you mix CMUCL
threading with heavy use of Unix/Linux signals, but my app
doesn't do that.
+---------------
| if you want CMUCL + threads you need to pay some 3000$.
| so free SBCL is cool, ye?
+---------------
Maybe, maybe not. "It depends." If the free CMUCL ever runs out
of steam on the kind of apps I support, I would have to examine
the cost of converting them to SBCL versus the cost of buying SCL
[which you're implying is closer to the original CMUCL than SBCL is],
or even switching to some other CL entirely. Until then, though,
CMUCL is fine for me. As always, YMMV.
-Rob
[1] What had happened was that the co-lo ISP changed the version
of PostgreSQL[2] out from underneath the app without telling
anyone about it first, and the new version broke the parsing
of the PostgreSQL "timestamp" type in Eric Marsden's "pg.lisp".
A quick trip to the archive site showed that James Anderson
had already added a fix in a later version of "pg", so one
"wget" and a COMPILE-FILE & LOAD later and we were back in
business, *without* stopping/restarting the CMUCL image, note!
[2] Yes, PostgreSQL has since been taken out of the list of
"auto-updated" software. ;-}
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Lars Rune Nøstdal schrieb:
> SBCL has just turned 1.0!
Thanks to the devs! *handshaking*
André
--
From: Dmitry V. Gorbatovsky
Subject: Re: SBCL just turned 1.0!
Date:
Message-ID: <ekmiki$uch$1@aioe.org>
Lars Rune N�stdal wrote:
> SBCL has just turned 1.0!
>
> ····@ibmr52:~$ sbcl
> This is SBCL 1.0, an implementation of ANSI Common Lisp.
> More information about SBCL is available at <http://www.sbcl.org/>.
>
> SBCL is free software, provided as is, with absolutely no warranty.
> It is mostly in the public domain; some portions are provided under
> BSD-style licenses. See the CREDITS and COPYING files in the
> distribution for more information.
> *
>
>
> This is great. :D
Let me join with my humble congratulations.
Cheers,Dmitry :D
"Mark Tarver" <··········@ukonline.co.uk> writes:
> Hi,
>
> Last time I looked, SBCL was not available for Windows. Any change in
> this?
>
> Mark
http://www.sbcl.org/platform-table.html reports "port in progress" and
gives a download link for the Win32 version. It's probably worth a
shot.
Ari Johnson wrote:
> "Mark Tarver" <··········@ukonline.co.uk> writes:
>
> > Hi,
> >
> > Last time I looked, SBCL was not available for Windows. Any change in
> > this?
> >
> > Mark
>
> http://www.sbcl.org/platform-table.html reports "port in progress" and
> gives a download link for the Win32 version. It's probably worth a
> shot.
Hi,
For the benefit of any SBCL developer here.
I followed this up and loaded the source for Qi and got the message
debugger invoked on a COMMON-LISP:UNBOUND-VARIABLE:
The variable *READTABLE* is unbound.
http://www.lispworks.com/documentation/HyperSpec/Body/v_rdtabl.htm#STreadtableST
says this should be bound.
The implementation does warn it is beta
| This is SBCL 1.0, an implementation of ANSI Common Lisp.
| More information about SBCL is available at <http://www.sbcl.org/>.
|
| SBCL is free software, provided as is, with absolutely no warranty.
| It is mostly in the public domain; some portions are provided under
| BSD-style licenses. See the CREDITS and COPYING files in the
| distribution for more information.
|
| This is experimental prerelease support for the Windows platform: use
| at your own risk. "Your Kitten of Death awaits!"
I guess I got scratched.
Mark
In article <······························@gmail.com>,
Lars Rune Nøstdal <···········@gmail.com> wrote:
> SBCL has just turned 1.0!
>
> ····@ibmr52:~$ sbcl
> This is SBCL 1.0, an implementation of ANSI Common Lisp.
> More information about SBCL is available at <http://www.sbcl.org/>.
>
> SBCL is free software, provided as is, with absolutely no warranty.
> It is mostly in the public domain; some portions are provided under
> BSD-style licenses. See the CREDITS and COPYING files in the
> distribution for more information.
> *
>
>
> This is great. :D
>
> http://digg.com/programming/SBCL_The_Common_Lisp_implementation_has_just_turne
> d_1_0/
I should add my 2 cents, since I also use SBCL.
I see the SBCL project as a huge success. Many
thanks to all the persons involved.
I had SBCL 0.9.18 installed on my new MacBook Pro.
Downloaded the source for SBCL 1.0, looked for a few
seconds at the compilation instructions and in
just a few minutes (amazing how fast the Core 2 Duo
is) I had a fresh compiled SBCL 1.0 on my Mac. Wow!
Rainer Joswig wrote:
> I should add my 2 cents, since I also use SBCL.
>
> I see the SBCL project as a huge success. Many
> thanks to all the persons involved.
>
> I had SBCL 0.9.18 installed on my new MacBook Pro.
> Downloaded the source for SBCL 1.0, looked for a few
> seconds at the compilation instructions and in
> just a few minutes (amazing how fast the Core 2 Duo
> is) I had a fresh compiled SBCL 1.0 on my Mac. Wow!
Yeah, that's true. But do you have stable threads support? *sigh*
Anyway, congratulations to SBCL guys - they're doing a great job!
Regards,
Victor.
Victor Kryukov wrote:
> Rainer Joswig wrote:
>
> > I should add my 2 cents, since I also use SBCL.
> >
> > I see the SBCL project as a huge success. Many
> > thanks to all the persons involved.
> >
> > I had SBCL 0.9.18 installed on my new MacBook Pro.
> > Downloaded the source for SBCL 1.0, looked for a few
> > seconds at the compilation instructions and in
> > just a few minutes (amazing how fast the Core 2 Duo
> > is) I had a fresh compiled SBCL 1.0 on my Mac. Wow!
>
> Yeah, that's true. But do you have stable threads support? *sigh*
>
> Anyway, congratulations to SBCL guys - they're doing a great job!
I've just compiled fresh SBCL version (just out of CVS) and after
running run-tests.sh, I got the following:
Status:
Expected failure: float.pure.lisp / (SCALE-FLOAT-OVERFLOW BUG-372)
Expected failure: float.pure.lisp / (ADDITION-OVERFLOW BUG-372)
Expected failure: debug.impure.lisp / (UNDEFINED-FUNCTION BUG-353)
Expected failure: external-format.impure.lisp /
(CHARACTER-DECODE-LARGE
FORCE-END-OF-FILE)
Invalid exit status: threads.impure.lisp
test failed, expected 104 return code, got 1